|
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.
 Share your thoughts on Software
Life Cycle in SQAtester Group.
 E-mail to a Friend.
|
