What is an Alpha version and why is it declared as such?
A very early, internal stage of development
The development of products – and especially of software – is traditionally carried out in phases. The alpha version in software development follows the pre-alpha version and precedes the beta version. It includes first features or parts of features of a planned release and is a basis for early feedback from internal clients (as a substitute for later users or customers). Other characteristics of an alpha version include
- the incomplete implementation of individual features,
- the absence of features and functional areas, and
- the early use of tools such as stubs or mock objects, so that
- a basis for white box testing is available. (White-box testing is used to identify defects in components without checking compliance with the specification. For this reason, gray or back-box testing usually follows, but only in the beta version).
Some publications point out that click dummies or click prototypes are also created or used in the alpha version. Depending on the organisation and procedure, the use could also already have taken place in the pre-alpha version. It is undisputed that there is no documentation in the manual or change log at this early stage of development. This is usually only finalised in the course of a release candidate.
The alpha version as advance notice
The terminology of alpha and beta testing probably goes back to Martin Belsky, an IBM manager in the 1950s. IBM used the “A” test as verification of new software before public announcement and the “B” test as verification before product release. In addition, IBM also used a so-called “C” test as a final test before the general release of new software or software version. In this context, the alpha version was thus understood as a pre-announcement and the beta version as proof of product maturity.
Today, organisations provide selected customers and users with pre-release versions for testing. These are either release candidates or “at best” beta versions. Alpha versions are not in themselves used externally. An additional reason – despite the now widespread agile software development – is the uncertainty of further development. A release candidate is a version that “only” waits for the official release, an alpha version is a version where most of the planned features are not yet available. It is virtually a first, internal development stage of a new version. The point of explicitly declaring such an internal state is the intention,
- to document a state of development and progress,
- to lower expectations of the functional scope already implemented,
- in order to get a first, serious and at the same time benevolent feedback.