View source

From OpenOffice.org Wiki

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in the group: Users.
• You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences.

You can view and copy the source of this page:

[[Category:Quality Assurance]] It seems to be very simple to approve a Child Work Space ([[CWS]]). It seems that someone only needs to set all issues in a CWS to status 'verified' and to 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 CWSes only. It is essential to still archive success with OpenOffice.org, that the quality could be hold - better that the quality could be improved. This does not mean that OpenOffice.org will be bug free. No, that is illusive. But new features and bug fixes should be integrated without regressions and the quality should be always good enough to be able to release. The following information and links should be read carefully, and there are processes which should be kept. Without processes it is not possible to hold our highest goal – quality. The customers do not only want to have more and more features, but they want them in a high quality. Why do otherwise so many software- as well as other products have to shift the release dates so often? The processes are easy to understand, because an action list, a checklist and flowcharts exists. They help that no activity at CWSes or Issues in a CWS will be forgotten. ==The Workflow of a CWS (view by QA project)== The [[CWS Workflow for QA-Representative]] shows the complete process/workflow. It begins when the CWS-Owner (mostly a developer) sets the status of a CWS to 'ready for QA' and ends when the QA-Representative for this CWS sets it to 'approved by QA'. After that the Program Management and Release Engineering takes the CWS to 'nominate' and 'integrate' it into the next Milestone. ==Checklist for QA== The QA-Representative is responsible to organize the QA. Very often more than one member of the QA team is affected by a CWS. They have to check new features against specifications, have to run automated test scripts with the TestTool and/or check a corrected bug. 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 modules. 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]]. ==The Workflow of a CWS (view by QA project)== The [[CWS Workflow for QA-Representative]] shows the complete process/workflow. It begins when the CWS-Owner (mostly a developer) sets the status of a CWS to 'ready for QA' and ends when the QA-Representative for this CWS sets it to 'approved by QA'. After that the Program Management and Release Engineering takes the CWS to 'nominate' and 'integrate' it into the next Milestone. ==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 only have to take care of the checklist ([[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. If you have questions or want to find a QA representative please ask the [[Team Leads|QA Team Leads]]. ==[[Gatekeeper]]== In the software development process a [[gatekeeper]] was installed and is still active. He picks up [[CWS]]es randomly and check the formalities against the policies. He also has to take care on critical features and code changes and to check if enough testing work has been done. The [[Gatekeeper]] will reassign a [[CWS]] back to ''CWS owner'' or ''QA representative'' and inform them if he would find violations against the existing policies and rules. He also gives tips how the testing 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?<BR> Do you think something is wrong or can be deleted?<BR> Do you think something should be added or changed?<BR> 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. ==Autor== Autor: Thorsten Ziehm (Thorsten.Ziehm@Sun.com) Please do not change the logical content of this site without acknowledge of the author or the OOo QA Project Lead/Co-Leads.

Return to Approve a CWS.