Difference between revisions of "CWS Checklist for QA responsibilities"
| Line 22: | Line 22: | ||
- All required install sets need to be existent (at least one Windows and one Unix/Linux build, whereas both must be a product build). | - 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> | <H2>Step 2 : Check general CWS health (Avoid wasted effort of other stake-holders)</H2> | ||
| Line 31: | Line 32: | ||
- Evaluate test results against Master Work Space (MWS) | - 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> | ||
| Line 38: | Line 40: | ||
- Provide 'due dates' | - Provide 'due dates' | ||
| + | |||
<H2>Step 4 : Collect and evaluate Feedback</H2> | <H2>Step 4 : Collect and evaluate Feedback</H2> | ||
- Inform about obstacles in the comments section of the EIS status page | - Inform about obstacles in the comments section of the EIS status page | ||
| + | |||
<H2>Step 5 : Nominate or reject CWS</H2> | <H2>Step 5 : Nominate or reject CWS</H2> | ||
- If the CWS must be rejected a comment with the reason for the rejection must be inserted in EIS.</PRE><P> | - If the CWS must be rejected a comment with the reason for the rejection must be inserted in EIS.</PRE><P> | ||
| + | |||
<H2>Further questions</H2> | <H2>Further questions</H2> | ||
- Questions should be asked and discussed in dev@qa.openoffice.org. | - Questions should be asked and discussed in dev@qa.openoffice.org. | ||
Revision as of 12:43, 2 October 2006
Contents
Step 1 : Check common CWS requirement (Checklist in flow chart)
- Check if release target of CWS is set correctly.
- 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. The information can be found at http://specs.openoffice.org.
- 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 Work Space (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.</PRE>
