Describing software quality requires concise language. While Alpha, Beta, Release Candidate (RC) and Release to Manufacture (RTM) are commonly used terms, they are often loosely used. In this article, I offer a set of concise definitions, and describe how they are used.
The software quality definitions I use are:
Pre-Alpha – incomplete
Alpha – feature complete, not fully tested
Beta – fully tested Alpha with no test blocks, may have known defects
RC – Beta with acceptable defects
RTM – approved RC
Pre-Alpha is declared by the Development team stating that the software is incomplete. Releasing of Pre-Alpha software is discouraged. If a release is necessary, then Pre-Alpha designator and its definition must be clearly indicated with the release. Appropriate legal language should be included for protection.
Alpha is declared by the Development team stating that the software is ready for test. This is subject to Test team’s acceptance. The Test team may want to verify that the source code is checked into the version control system and tagged, and that all the required documents are completed and placed under configuration control. In the Alpha phase, the number of new bugs may climb rapidly. The initial set of bugs found tends to block further testing, therefore the Development team should be on standby to resolve these bugs quickly so tests can continue. As with Pre-Alpha, Alpha releases are discouraged.
Beta is declared by the Test team once the software can be fully tested, i.e., the entire test plan executed without blocks. Not all test cases have to pass to reach Beta. This seemingly peculiar definition is meaningful because when the entire test plan can be executed, all defects are known, therefore the remaining effort can be accurately quantified. When Beta is reached, the defect rate tends to plateau or start declining. At this inflection point, the software may be stable enough that some companies will release it externally for evaluation. As with any releases, proper quality designator and protective legal language should be included with the release.
RC is declared by the Test team that the software has been fully tested, and any remaining bugs are likely acceptable by the Stakeholders. The acceptance is ultimately decided by the Stakeholders after reviewing the test report. The Stakeholders may require customer acceptance before approve the software for RTM. The customers may also want to conduct their own tests before accepting the RC for final release.
RTM is declared by the Stakeholders when a RC is accepted as the final release. Once accepted for RTM, the software is packaged and released to customers or to the Manufacturing team for inclusion in the production process. The package should include the installer, installation instruction, license files (or click-wrap license), content list, and release note. The package should be deposited on a secure server with login access, so that there is a record of retrieval.
There are many different software quality definitions, and I found the above definitions most concise and useful. Readers are encouraged to fine-tune the definitions to suit their own development processes, and use them concisely and consistently.
Further Reading:
(The above article is solely the expressed opinion of the author and does not necessarily reflect the position of his current and past employers)