Project
A user defined software test effort. Projects contain the specific test plans, test procedures, test cases, defect information, test schedule information, and performance data used to test software applications and track results.
Pre-Alpha
Pre-Alpha is the test period during which the product is made available for internal testing by QA, Information Development and other internal users. Shipping Pre-Alpha drops to external customers during this time is explicitly for the purpose of getting feedback about the implementation or usability of one or more features.
Alpha
Alpha is the test period during which the product is complete and usable in a test environment but not necessarily bug-free. It is the final chance to get verification from customers that the tradeoffs made in the final development stage are coherent.
Entry to Alpha
All features complete/testable (no urgent bugs or QA blockers, including automation)
High bugs on primary platforms fixed/verified
50% of medium bugs on primary platforms fixed/verified
All features tested on primary platforms
Purify run on post-FF drop to obtain baseline
Performance measured/compared to previous release (user
functions)
80% of automation complete (not including UI tests)
Media verified by QA Doc review started
Usability testing and feedback (ongoing)
Alpha sites ready for install
Final product feature set Determined
Beta
Beta is the test period during which the product should be of "FCS quality" (it is complete and usable in a production environment). The purpose of the Beta ship and test period is to test the company's ability to deliver and support the product (and not to test the product itself). Beta also serves as a chance to get a final "vote of confidence" from a few customers to help validate our own belief that the product is now ready for volume shipment to all customers.
Entry to Beta
At least 50% positive response from Alpha sites
All customer U/H/M bugs addressed via patches/drops in Alpha (except OAR bugs)
100% run to plan
Secondary platform/compatibility testing complete:
All U/H/M bugs fixed/verified
Bug fixes regression/confidence tested
Bug fix rate exceeds find rate consistently for two weeks
Preliminary release notes available
Beta sites ready for install
Second doc review complete
GM (Golden Master)
GM is the test period during which the product should require minimal work, since everything was done prior to Beta. The only planned work should be to revise part numbers and version numbers, prepare documentation for final printing, and sanity testing of the final bits.
Entry to Golden Master
Beta sites declare the product is ready to ship
All customer U/H bugs addressed via patches/drops in Beta
All negative responses from sites tracked and evaluated
Support declares the product is supportable/ready to ship
QA-qualified U/H bugs re-verified in final drop
All patches delivered to Beta sites included in final drop
Final drop selectively regression tested with no new U/H bugs
Bug find rate is lower than fix rate and steadily decreasing
Docs signed off
FCS (First Customer Ship)
FCS is the period which signifies entry into the final phase of a project. At this point, the product is considered wholly complete and ready for purchase and usage by the customers.
Entry to FCS
Product baked for two weeks with no new urgent bugs (multiple attempts may be required)
Product team declares the product is ready to ship
OHG (Hand-off to QA) approval to ship
Test Phase
Pre - determined period of QA evalution of each software build
Builds
In many software projects, programming and testing are treated as separate phases. Code units are written and unit tested before any form of integration or system testing. Although this approach may be acceptable on small projects, there are many advantages to overlapping development and testing activities. Builds, which are fundamental approach to testing, allow overlapping development and testing activities.
