Alpha testing
Alpha testing is acceptance testing of a near-complete product, done at the developing organisation's own site by people who did not build it, in an environment the team controls, before the product is released to outside users on their own devices. It exists to catch the defects and gaps a real user would hit first, in front of people who will tolerate a broken build and report it well.
The longer version
An alpha runs on a build that is feature complete or close to it, in an internal or staging environment, with testers who did not build it: an independent test team, staff from support or sales, or a few invited customers brought on site. They work through the product the way a customer would rather than the way a developer would, and file what they find. The build is expected to have defects. The point is that it has them in front of people who can describe what happened, on infrastructure the team controls, before anyone outside has formed an opinion of it.
Alpha and beta are the two halves of the same rehearsal, split by where it happens and who is watching. Alpha is on the developer's site, controlled and tolerant of a bad build; beta is external, uncontrolled and the first time strangers see the product. Alpha is also confused with user acceptance testing, and the difference is the question being asked. UAT asks the customer whether the product meets the agreed requirements. Alpha asks the organisation whether the product is ready to be shown to anyone at all. A product can meet its specification and still fail alpha because a signup path nobody specified turns out to be unusable.
Alpha testers usually know too much. Staff who have watched the product being built route around its rough edges without noticing them, use the demo account with the clean data, and never try the path a first-time visitor would. The alpha then reports a handful of cosmetic bugs and gives the team false confidence. The fix is to recruit alpha testers from the parts of the company furthest from the product, give them a fresh account and a realistic task, and treat every question they ask as a finding.
Common questions
What is the difference between alpha testing and beta testing?
Alpha testing is done at the developing organisation's site, by staff or invited users, in an environment the team controls, on a build expected to have defects. Beta testing is done by outside users on their own devices and networks, on a build the team believes is nearly ready. Alpha finds what breaks; beta finds what breaks in conditions the team could not reproduce.
Who does alpha testing?
People who did not build the product: an independent test team, staff from support, sales or operations, or a small group of customers invited to the developer's site. The best alpha testers are the people who know the least about how it works, because they use it the way a customer will. Developers make poor alpha testers of their own features, since they avoid the paths they know are fragile.
Is alpha testing the same as user acceptance testing?
Alpha testing and user acceptance testing are different questions. UAT is run by or for the customer and asks whether the delivered product meets the agreed requirements. Alpha testing is run internally and asks whether the product is ready to be seen by outsiders at all, including in the areas nobody wrote a requirement for.
When is alpha testing done?
Alpha testing starts when the build is feature complete or close to it and internal testing has cleared the obvious defects, and it ends when the team is willing to let outsiders see the product, which is the point where beta testing begins. Running it earlier wastes testers on known gaps; running it later leaves no time to act on what it finds before the beta date.
What does alpha testing look like in an agile team?
In an agile team the alpha is rarely a single phase. Each increment that reaches a demonstrable state goes in front of internal users who did not build it, often at the sprint review. Dogfooding, where staff use the product for their own work, is a neighbouring practice rather than a form of alpha. What makes a session an alpha is a near-complete build, outside testers, a controlled environment and a route for every finding into the backlog.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.