Approve a CWS

From Apache OpenOffice Wiki
Revision as of 12:32, 11 October 2006 by Thorstenziehm (Talk | contribs)

Jump to: navigation, search

It looks like very simple to approve a Child Work Space (CWS). It is only to set all issues in a CWS to status 'verified' and select 'approved by QA' for the CWS in the Environment Information System EIS. Is this really enough?!

The following information should be used to make Quality Assurance at a CWS and not to change the status of issues and CWSs only. It is essentially to still archive success with OpenOffice.org that the quality could be hold - better if the quality could be extended. This does not mean that OpenOffice.org will not have any bug. No, that is illusively. But new Features and Bug-fixes should integrate without Regressions and the quality should be always able to release.

The following information and links looks a strict and there are Processes which should be kept. But without Processes it is not possible to hold our highest goal – Quality. The customers do not want to have more and more features only, they want them in a high quality. Why otherwise so many Software products and other products have to shift the release dates very often.

The Processes are easy to understand, because an Action list, a Check list and Flow Charts exists. They help to do not forget any activity at CWSs or Issues in a CWS.


The Workflow of a CWS (view by QA project)

The CWS Workflow for QA-Representative show the complete process/workflow. It begins when the CWS-Owner (mostly a developer) set the status of a CWS to 'ready for QA' and ends when the QA-Representative for this CWS set it to 'approved by QA'. After that the Program Management and Release Engineering take the CWS to 'nominate' and 'integrate' it into the next Milestone.


Checklist for QA

The QA-Representative has responsibility to organize the QA effort. Very often more than one member of the QA team is affected by a CWS. They have to check new feature against Specification, have to run automated test scripts with TestTool and/or check a correct bugfix. These actions are also done, when only one QA member is responsible for the whole CWS. All activities are listed in the CWS Checklist for QA responsibilities.


Workflow of an Issues in a CWS

What have to be done with issues in a CWS. They should be in status 'fixed' and what else? The workflow is shown in the flowchart 'CWS Workflow for Issue Owners.


Action list for Issues Owner

Do not forget to analyze the It looks like very simple to approve a Child Work Space (CWS). It is only to set all issues in a CWS to status 'verified' and select 'approved by QA' for the CWS in the Environment Information System EIS. Is this really enough?!

The following information should be used to make Quality Assurance at a CWS and not to change the status of issues and CWSs only. It is essentially to still archive success with OpenOffice.org that the quality could be hold - better if the quality could be extended. This does not mean that OpenOffice.org will not have any bug. No, that is illusively. But new Features and Bug-fixes should integrate without Regressions and the quality should be always able to release.

The following information and links looks a strict and there are Processes which should be kept. But without Processes it is not possible to hold our highest goal – Quality. The customers do not want to have more and more features only, they want them in a high quality. Why otherwise so many Software products and other products have to shift the release dates very often.

The Processes are easy to understand, because an Action list, a Check list and Flow Charts exists. They help to do not forget any activity at CWSs or Issues in a CWS.


The Workflow of a CWS (view by QA project)

The CWS Workflow for QA-Representative show the complete process/workflow. It begins when the CWS-Owner (mostly a developer) set the status of a CWS to 'ready for QA' and ends when the QA-Representative for this CWS set it to 'approved by QA'. After that the Program Management and Release Engineering take the CWS to 'nominate' and 'integrate' it into the next Milestone.


Checklist for QA

The QA-Representative has responsibility to organize the QA effort. Very often more than one member of the QA team is affected by a CWS. They have to check new feature against Specification, have to run automated test scripts with TestTool and/or check a correct bugfix. These actions are also done, when only one QA member is responsible for the whole CWS. All activities are listed in the CWS Checklist for QA responsibilities.


Workflow of an Issues in a CWS

What have to be done with issues in a CWS. They should be in status 'fixed' and what else? The workflow is shown in the flowchart 'CWS Workflow for Issue Owners.


Action list for Issues Owner

Do not forget to analyze the dependencies of a Bugfix with other applications. Check the correct status and targets of an Issue, to easier find the relation between bugfix and integrated version of OOo. All these and many more information can be found in the Actionlist for fixed Issues.


QA Representative

Often a question is "who can be the QA Representative for my CWS?" The owner is clear, it is the developer, who wants to bring in his/her code. But who should make the QA part for the code. It is easy too. Everybody can do the QA job. They have to take care only of the Check-List (CWS Workflow for QA-Representative) and Action-List (Actionlist for fixed Issues). Everybody who is interested in a high quality of new features or bug fixes is invited to be the QA Representative of a CWS.


Gatekeeper

In Sun QA Team a Gatekeeper was installed and is still active. The Gatekeeper pick out CWSs randomly and check the formalities against the policies. He also has to take care on critical Features and Code Changes and check if enough QA was done. The Gatekeeper can reject a CWS back to Owner and QA Representative and inform they about failures. He also gives tips, how the QA part can be extended for their CWS.


Feedback is welcome!

Do you think the handling of CWS in QA is too complex or is something missing?
Do you think something is wrong or can be deleted?
Do you think something should be added or changed?
Please make the changes by yourself (it is Wiki!), discuss it on QA mailing list dev@qa.openoffice.org or add additional sections to this or the other pages.

Personal tools