In this post, we look at the 6 different types of UAT: alpha, beta, operational, contract, regulation, and business acceptance testing.
In this post, we’re giving you more information on the core six types of UAT:
- Alpha testing
- Beta testing
- Contract acceptance testing (CAT)
- Operational acceptance testing (OAT)
- Regulation acceptance testing (RAT)
- Business acceptance testing (BAT)
Want to know more detail about what is user acceptance testing? Here’s our in-depth explainer on UAT.
Each UAT type serves a unique function, and whether you need all six depends on several factors:
- The function and aims of the software you’ve developed;
- The business and operational goals;
- Larger clients with significant investments in software often require more comprehensive testing before launch.
- The number of stakeholders involved.
Let's dive in.
What are the different types of UAT testing?
There are six different types of user acceptance testing, based on their objectives:
- Alpha testing focuses on identifying critical bugs and gathering early feedback, primarily from internal stakeholders or a select group of users.
- Beta testing expands this to a broader group, typically end-users, to further test the software.
- Contract acceptance testing (CAT) validates that software meets the agreed specifications such as the original scope of the project and features/functionality.
- Operational acceptance testing (OAT) ensures that the software's workflows and user requirements function smoothly in real-world scenarios.
- Regulation acceptance testing (RAT) confirms compliance with relevant laws, crucial for apps in regulated sectors like finance.
- Business acceptance testing (BAT) verifies that the software meets business objectives; e.g., for marketing, sales, customer experience, or sales.
Let’s look at each of these types, discussing their advantages and how to implement them effectively.
6 Types of User Acceptance Testing (UAT)
Here are the six different types of UAT in detail, including use cases, and how they fit into the development lifecycle.
Alpha testing
Alpha testing is the initial quality assurance phase, conducted internally before involving clients or end-users.
Participants are typically internal team members, such as QA engineers and a product manager.
All alpha testing activities occur within an internal, controlled environment, such as a staging site.
Key activities
- Outline what testers should observe, such as product specifications and features.
- Create a test plan that might include various testing methods like black box and integration testing.
- Make sure the test plan includes the most common use cases/test plans
- Execute the testing sequences
- Log any defects, bug reports, and any UX/UI experience issues
- Assign fixing all of the issues to relevant team members via your product management (PM) suite
- Re-test once the above issues have been fixed and any necessary changes made.
Typical outputs
Outputs typically include bug and defect reports, functionality assessments, and API testing performance reviews.
When should this happen in the development lifecycle?
Alpha testing is the first type of system testing that’s performed on new websites and platforms.
This always precedes other tests to ensure major issues are resolved before client or end-user testing.
Often, the development team will find a whole load of things that need fixing or improving before beta testing can happen, or the product is ready for a client to view and test.
Beta testing
Beta testing follows alpha testing, allowing clients or internal stakeholders to test the app or software under real-world conditions.
The aim of beta testing is to find out whether an app or software functions as expected and as intended for real end-users.
It evaluates if the software meets its intended goals and client expectations.
Crucially, beta testing ensures users can navigate the app effectively to meet client goals, like making a purchase or completing a task.
Participants are limited, including client team members and possibly a few external developers.
Key activities
Similar to alpha testing, the scope of beta testing depends on whether it's open or closed.
If you’re running a closed beta session then you can give testers a list of things you want them to try and accomplish.
You can even recruit a team of beta testers through crowd-sourced testing platforms.
If working directly with a client, they aren't “testers” in the traditional sense but will still provide valuable feedback.
Provide them with specific tasks and be open to additional feedback during the testing phase.
Typical outputs
Many bug reports, and feedback on UX/UI, ease of navigation.
Feedback might include content and visual elements, such as text or image adjustments.
When should this happen in the development lifecycle?
Before an app is released live, or before any other type of testing.
Only after addressing these issues can an app, software, or website be released to the target audience and published.
A real example is aligning a highly technical SaaS product with a non-technical audience's needs. You ask them to test it and provide feedback.
Questions you should ask them include:
- How easy was this for you to use?
- Do you understand the terminology (even if you don’t have tech knowledge)?
- Are all of the features and functions functioning as you’d expect them to?
Operational acceptance testing (OAT)
Operational acceptance testing (OAT) focuses on verifying the system's operational readiness from a maintenance and support perspective.
You'll want to:
- Make sure everything is working as expected
- Check if the finished product meets operational requirements
- Potentially test backup/restore capabilities and maintenance procedures
Key activities
A small team, typically including client stakeholders and QA testers, conducts the testing within a controlled environment (restricted access).
Testing might cover unexamined aspects like performance under load, failover capabilities, and security robustness.
Typical outputs
Test results and changes enhancing infrastructure like APIs, databases, or servers to handle high traffic volumes.
When should this happen in the development lifecycle?
Part of a checklist of final tests before a new website or app can be launched.
Contract acceptance testing (CAT)
Contract acceptance testing (CAT) ensures the project meets contractual terms, scope, and functionality.
CAT is a compliance-driven process to verify that a new product fulfills contractual obligations.
It's crucial to ensure that the product meets quality standards after all UAT types have been completed.
This process typically involves collaboration between the client’s team and project managers, on a staging environment with logins for the participants.
Key activities
- The client or project lead should revert back to the scope/agreement
- Make a list of everything that will be delivered
- Check this against the features and functionality
- Verify against any project management notes to ensure alignment with original specs, scope, and agreements
- Both the client and project lead should then agree that all deliverables meet expectations, or further adjustments may be required
Typical outputs
Any further and final changes can be made based on the feedback from the CAT stage of UAT.
This enhances software quality, reduces risks, and increases client satisfaction with the project outcome.
When should this happen in the development lifecycle?
Before going live, a final series of checks that focus on compliance, quality control, user experience, and functionality.
Regulation acceptance testing (RAT)
Regulation acceptance testing (RAT) verifies compliance with relevant laws and industry standards.
For example, you’ve developed an app for a financial or healthcare client. In those sectors, there is a heavier regulatory burden than in other sectors.
Ensure the software complies with data protection laws like HIPAA and others relevant to the sector.
Data protection standards are stringent globally, so compliance with laws like GDPR is essential.
Do this collaboratively with the client’s team and project managers.
If complex issues arise, the client may need to consult regulatory professionals or a third-party consultant to ensure the relevant boxes have been ticked and everyone’s legal backs are covered.
Key activities
Assessing regulatory compliance might include examining data handling and user consent mechanisms within the app.
Testers need a thorough understanding of regulatory guidelines and their application in software.
Typical outputs
Test data helps determine if the app meets business requirements and what fixes are necessary for public release.
When should this happen in the development lifecycle?
Before launch, ensure compliance checks are part of the final review, especially in sectors with a heavier regulatory burden.
Business acceptance testing (BAT)
Business acceptance testing (BAT) ensures the app meets business objectives; e.g., for marketing, customer experience, or sales.
BAT helps:
- Measure performance using data analytics to track inputs, throughputs, and outputs, ensuring the software supports business goals
- Identify successful features and consider enhancements
Participants involve stakeholders like marketing and sales, to refine the product.
This all happens on a staging environment with restricted access.
Key activities
Testing real, business-facing customer interactions like:
- Adding items to a cart
- Applying a discount code
- Changing delivery addresses
Every testing activity and output depends on what’s being tested and who’s using it.
Typical outputs
Outputs typically include stakeholder feedback necessary for final adjustments before release.
This might result in further testing before it can be launched.
When should this happen in the development lifecycle?
Ideally, pre-launch.
To simplify all of this, we’ve put it into a handy quick-reference table below.
Types of UAT: Comparison table
Wrapping up…
We hope this definitive guide on the different types of user acceptance testing (UAT) has been helpful!
Using the right tools simplifies UAT, bug reporting, and issue tracking, easing the development process.
