📣  We're hiring
Fulltime Full-stack Typescript Developer. Read more →
6 Types of User Acceptance Testing Explained
Book a demoTry Marker.io for free
How-To Guides

6 Types of User Acceptance Testing Explained

Last updated:
May 23, 2024
A list of the different types of UAT that exist in user acceptance testing.
A list of the different types of UAT that exist in user acceptance testing.
Contents
    Contents

    In this post, we look at the 6 different types of UAT: alpha, beta, operational, contract, regulation, and business acceptance testing.

    TL;DR:

    • User Acceptance Testing (UAT) is the final stage before lanching a website or software
    • There are 6 types of UAT: alpha, beta, operational, contract, regulation, and business acceptance testing
    • Each type serves a specific purpose. You may not need all 6 unless compliance and multiple stakeholders are involved
    • This post outlines each UAT type, what it involves, and its benefits

    Read on for details 👇

    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.

    💡Pro Tip: You don’t need a dedicated testing team to outsource this function, or even many testing tools.

    Typically, the same development team can manage the testing process using agile methods, effective tools, and best practices.

    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

    A high-level overview of alpha testing goals, participants, environment, and timing.

    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

    A high-level overview of beta testing goals, participants, environment, and timing.

    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)

    A high-level overview of operational acceptance testing goals, participants, environment, and timing.

    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)

    A high-level overview of contact acceptance testing goals, participants, environment, and timing.

    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)

    A high-level overview of regulation acceptance testing goals, participants, environment, and timing.

    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)

    A high-level overview of business acceptance testing goals, participants, environment, and timing.

    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.

    💡 Pro tip: Involve sales and marketing teams as they might identify overlooked issues.

    Allow time for necessary changes, ensuring they align with project scope and compliance requirements.

    To simplify all of this, we’ve put it into a handy quick-reference table below.

    Types of UAT: Comparison table

    UAT Type

    Goals 

    Who’s involved?

    Environment

    Key activities 

    Typical outputs 

    When should this happen?

    Alpha

    Test for bugs, other defects before a client tests for them

    Internal team, QA, product leads 

    Secure testing/staging environment

    Functional, UX/UI, bug reporting 

    Feedback and bug reports 

    Before any of type of testing, such as before a client is given access 

    Beta

    Crucial for testing for bugs, UX/UI, features, etc. 

    Internal + client team, and any other stakeholders. End-users too, or professional beta testers 

    Staging or closed beta 

    Functional, UX/UI, bug reporting. Crucially, this feedback is from real users and/or the client 

    Feedback and bug reports 

    Before final tests/checks are undertaken, after giving a client access so they can test the product or app 

    Contract (CAT)

    Testing against the contract, scope of work

    Internal + client team, and any other stakeholders. 

    Staging or closed beta 

    Compliance, checking it aligns with the SoW

    Functional user feedback and project specs 

    Part of a checklist of final tests, as required and within the SoW

    Operational (OAT)

    Testing for operational features 

    Internal + client team, and any other stakeholders. 

    Staging or closed beta 

    Making sure an app functions (UX/UI) as intended 

    UX/UI changes as required 

    Part of a checklist of final tests, as required and within the SoW

    Regulation (RAT)

    Testing against regulatory criteria 

    Internal + client team, and any other stakeholders. Data compliance or regulatory testers might need to be involved 

    Staging or closed beta 

    Making sure an app adheres to regulatory requirements 

    Data capture and protection changes as required 

    Part of a checklist of final tests, as required and within the SoW

    Business (BAT)

    Testing it will do the job that sales or marketing needs 

    Internal + client team, and any other stakeholders, especially marketing, sales, or customer success. 

    Staging or closed beta 

    Checking an app aligns with sales, marketing, growth goals

    UX/UI changes, or design changes as required 

    Part of a checklist of final tests, as required and within the SoW

    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.

    Continue reading

    Frequently Asked Questions

    Get started now

    Start free trial
    Free 15-day trial  •  No credit card required •  Cancel anytime