Difference between revisions of "CWS Checklist for QA responsibilities"

From Apache OpenOffice Wiki
Jump to: navigation, search
m
 
(12 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<H2> Step 1 : Check common CWS requirement  (Checklist in flow chart)</H2>
+
[[Category:Quality Assurance]]
- Check if release target of CWS is set correctly.
+
[[Category:Policy]]
 +
[[Category:CWSQAStatus]]
  
- Check right adjustment of due dates (plan at least an average of 5 working days for testing in QA).
+
It is very difficult to identify all Activities which are needed to approve a [[CWS]] in a high quality. So it is very easy to oversee small items, which can be followed easily by a Regression in the [[MWS|Master (MWS)]] builds. To avoid such kind of Regressions this list of Action Items should help.  
  
- Build version should not be too old compared to the current master.
 
<BR>(e.g. 1-2 build if many CWSs were integrated; 3-5 build if only a few CWSs were integrated  - release phase -; last build if important changes were made in this build)
 
  
- Appropriate information about specific and global risks must be provided, either in the comments section of the EIS status page and/or in one or more QA child tasks.
+
<H2> Step 1 : Check common [[CWS]] requirement (Checklist in flowchart of '[[CWS Workflow for QA-Representative]])'</H2>
 +
<UL>
 +
    <UL>
 +
        <P>Check if release target of [[CWS]] is set correctly.</P>
 +
        <P>Check the status of the [[RedTinderboxStatusInEIS|tinderbox]] in the [[EIS|'''E'''nvironment '''I'''nformation '''S'''ystem]]. Is the status red the [[CWS]] has to go back to development.</P>
 +
        <P>Check right adjustment of due dates (plan at least an average of 5 working days for testing in QA).</P>
 +
        <P>Build version should not be too old compared to the current master.
 +
        <BR>(e.g. 1-2 build if many [[CWS|CWSs]] were integrated; 3-5 build if only a few [[CWS|CWSs]] were integrated  - release phase -; last build if important changes were made in this build)</P>
 +
        <P>Appropriate information about specific and global risks must be provided, either in the comments section of the EIS status page and/or in one or more QA child tasks.</P>
 +
        <P>All issues must have the status 'Resolved/Fixed'</P>
 +
        <P>All issues must be assigned to a QA members (except those only developers can verify)</P>
 +
        <P>Issues that can only be tested by a developer must have the status 'verified' (set by another developer!)</P>
 +
        <P>For all new features a FINAL specification must be existent</P>
 +
        <P>For all features and changes a Change-Mail must be existent (see http://www.openoffice.org/servlets/SummarizeList?listName=allfeatures</P>
 +
        <P>For all new UI features and changes in general work flow or handling of older features the test case for automated test scripts has to be adapt that there isn't an error/warning in a test run of this script.</P>
 +
        <P>Issues submitted by developers must provide a test case to ensure appropriate verification.</P>
 +
        <P>All required install sets need to be existent (at least one Windows and one Unix/Linux build, whereas both must be a product build).</P>
 +
    </UL>
 +
</UL>
  
- All issues must have the status 'Resolved/Fixed'
 
  
- All issues must be assigned to a QA members (except those only developers can verify)
+
<H2>Step 2 : Check general [[CWS]] health  (Avoid wasted effort of other stake-holders)</H2>
 
+
<UL>
- Issues that can only be tested by a developer must have the status 'verified' (set by another developer!)
+
    <UL>
 
+
        <P>Run required automated test on both product build - Windows and Unix/Linux &ndash; (first.bas, topten.bas  from framework/first)</P>
- For all new features a FINAL specification must be existent
+
        <P>Run additional testing on at least one platform (if necessary)</P>
 
+
        <P>Run additional tests for specific testing areas or Update-Test for specific applications</P>
- For all features and changes a Change-Mail must be existent. The information can be found at http://specs.openoffice.org.
+
        <P>Evaluate test results against [[MWS|Master Workspace (MWS)]]</P>
 
+
    </UL>
- Issues submitted by developers must provide a test case to ensure appropriate verification.
+
</UL>
 
+
- All required install sets need to be existent (at least one Windows and one Unix/Linux build, whereas both must be a product build).
+
 
+
 
+
<H2>Step 2 : Check general CWS health  (Avoid wasted effort of other stake-holders)</H2>
+
- Run required automated test on both product build - Windows and Unix/Linux &ndash; (first.bas, topten.bas  from framework/first)
+
 
+
- Run additional testing on at least one platform (if necessary)
+
 
+
- Run additional tests for specific testing areas or Update-Test for specific applications
+
 
+
- Evaluate test results against Master Work Space (MWS)
+
  
  
 
<H2>Step 3 : Inform issue owners and wait for feedback</H2>
 
<H2>Step 3 : Inform issue owners and wait for feedback</H2>
- Provide CWS name
+
<UL>
 +
    <UL>
 +
        <P>Provide [[CWS]] name</P>
 +
        <P>Provide [[CWS]] location</P>
 +
        <P>Provide 'due dates'</P>
 +
    </UL>
 +
</UL>
  
- Provide CWS location
 
  
- Provide 'due dates'
+
<H2>Step 4 : Collect and evaluate Feedback</H2>
 +
<UL>
 +
    <UL>
 +
        <P>Inform about obstacles in the comments section of the EIS status page</P>
 +
    </UL>
 +
</UL>
  
  
<H2>Step 4 : Collect and evaluate Feedback</H2>
+
<H2>Step 5 : Nominate or reject [[CWS]]</H2>
- Inform about obstacles in the comments section of the EIS status page
+
<UL>
 +
    <UL>
 +
        <P>If the [[CWS]] must be rejected a comment with the reason for the rejection must be inserted in EIS.</P>
 +
    </UL>
 +
</UL>
  
  
<H2>Step 5 : Nominate or reject CWS</H2>
+
<H2>Further questions</H2>
- If the CWS must be rejected a comment with the reason for the rejection must be inserted in EIS.
+
<UL>
 +
    <UL>
 +
        <P>Questions should be asked and discussed in dev@qa.openoffice.org.</P>
 +
    </UL>
 +
</UL>
  
  
<H2>Further questions</H2>
+
<H2>Helpful Links</H2>
- Questions should be asked and discussed in dev@qa.openoffice.org.
+
<UL>
 +
    <UL>
 +
        <P>EIS - automatic guest login - : http://eis.services.openoffice.org/EIS2/GuestLogon</P>
 +
        <P>EIS - general user login -    : http://eis.services.openoffice.org/EIS2/Logon</P>
 +
        <P>Specification process        : http://wiki.services.openoffice.org/wiki/Category:Specification</P>
 +
    </UL>
 +
</UL>

Latest revision as of 11:27, 26 October 2009


It is very difficult to identify all Activities which are needed to approve a CWS in a high quality. So it is very easy to oversee small items, which can be followed easily by a Regression in the Master (MWS) builds. To avoid such kind of Regressions this list of Action Items should help.


Step 1 : Check common CWS requirement (Checklist in flowchart of 'CWS Workflow for QA-Representative)'

      Check if release target of CWS is set correctly.

      Check the status of the tinderbox in the Environment Information System. Is the status red the CWS has to go back to development.

      Check right adjustment of due dates (plan at least an average of 5 working days for testing in QA).

      Build version should not be too old compared to the current master.
      (e.g. 1-2 build if many CWSs were integrated; 3-5 build if only a few CWSs were integrated - release phase -; last build if important changes were made in this build)

      Appropriate information about specific and global risks must be provided, either in the comments section of the EIS status page and/or in one or more QA child tasks.

      All issues must have the status 'Resolved/Fixed'

      All issues must be assigned to a QA members (except those only developers can verify)

      Issues that can only be tested by a developer must have the status 'verified' (set by another developer!)

      For all new features a FINAL specification must be existent

      For all features and changes a Change-Mail must be existent (see http://www.openoffice.org/servlets/SummarizeList?listName=allfeatures

      For all new UI features and changes in general work flow or handling of older features the test case for automated test scripts has to be adapt that there isn't an error/warning in a test run of this script.

      Issues submitted by developers must provide a test case to ensure appropriate verification.

      All required install sets need to be existent (at least one Windows and one Unix/Linux build, whereas both must be a product build).


Step 2 : Check general CWS health (Avoid wasted effort of other stake-holders)

      Run required automated test on both product build - Windows and Unix/Linux – (first.bas, topten.bas from framework/first)

      Run additional testing on at least one platform (if necessary)

      Run additional tests for specific testing areas or Update-Test for specific applications

      Evaluate test results against Master Workspace (MWS)


Step 3 : Inform issue owners and wait for feedback

      Provide CWS name

      Provide CWS location

      Provide 'due dates'


Step 4 : Collect and evaluate Feedback

      Inform about obstacles in the comments section of the EIS status page


Step 5 : Nominate or reject CWS

      If the CWS must be rejected a comment with the reason for the rejection must be inserted in EIS.


Further questions

      Questions should be asked and discussed in dev@qa.openoffice.org.


Helpful Links

Personal tools