Difference between revisions of "Approve a CWS"

From Apache OpenOffice Wiki
Jump to: navigation, search
(change to Wiki style)
 
(11 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
[[Category:Quality Assurance]]
 
[[Category:Quality Assurance]]
  
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?!
+
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 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 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 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 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 Check list and Flow Charts exists. They help to do not forget any activity at CWSs or Issues in a CWS.
+
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.
  
  
<H2>The Workflow of a CWS (view by QA project)</H2>
+
==The Workflow of a CWS (view by QA project)==
The [[CWS Workflow for QA-Representative]] show the complete process/workflow.
+
The [[CWS Workflow for QA-Representative]] shows 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.
+
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.
  
  
<H2>Checklist for QA</H2>
+
==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]].
+
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]].
  
  
<H2>Workflow of an Issues in a CWS</H2>
+
==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]].
+
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]].
  
  
<H2>Action list for Issues Owner</H2>
+
==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?!
+
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 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 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.
  
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.
 
  
 +
==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]].
  
<H2>The Workflow of a CWS (view by QA project)</H2>
 
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.
 
  
 +
==[[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]].
  
<H2>Checklist for QA</H2>
 
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]].
 
  
 
+
==Feedback is welcome!==
<H2>Workflow of an Issues in a CWS</H2>
+
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]].
+
 
+
 
+
<H2>Action list for Issues Owner</H2>
+
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]].
+
 
+
 
+
<H2>QA Representative</H2>
+
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.
+
 
+
 
+
<H2>Gatekeeper</H2>
+
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.
+
 
+
 
+
<H2>Feedback is welcome!</H2>
+
 
Do you think the handling of CWS in QA is too complex or is something missing?<BR>
 
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 is wrong or can be deleted?<BR>
 
Do you think something should be added or changed?<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.
 
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.

Latest revision as of 12:19, 22 October 2009


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