Difference between revisions of "Approve a CWS"

From Apache OpenOffice Wiki
Jump to: navigation, search
(QA representatives : add the link to QA Team Leads)
Line 31: Line 31:
  
  
<H2>QA Representative</H2>
+
==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.
+
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]].
 
+
  
 
<H2>[[Gatekeeper]]</H2>
 
<H2>[[Gatekeeper]]</H2>

Revision as of 09:02, 3 August 2007


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 dependecies 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.

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 QA Team Leads.

Gatekeeper

In the software development process a gatekeeper was installed and is still active. He picks up CWSes 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?
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.

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.

Personal tools