User Acceptance Testing Planning
User acceptance testing (UAT) is the final validation phase in which intended users confirm that a system meets their needs before it is released. UAT planning decides what gets tested, who participates, which acceptance criteria apply, and how the business formally accepts the result.
itEngineering leadership and delivery management | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Intro
User Acceptance Testing Planning
User acceptance testing (UAT) is formal testing with respect to user needs, requirements, and business processes, conducted to determine whether a system satisfies the acceptance criteria and to enable the user, customers, or another authorized entity to decide whether to accept the system. UAT planning turns that decision into a concrete plan: what gets tested, who performs the tests, on what basis the results are judged, what must be true before testing starts, and what must be true before the business signs off.
A test plan describes the test objectives, resources, and processes for a test project. Planning is the activity that produces it, and the act of planning matters as much as the document: it forces testers to confront future challenges related to risks, schedules, people, tools, costs, and effort.
Validation, not verification
Verification confirms that a product is built correctly against its specification. Acceptance testing does something different: it focuses on validation and on demonstrating readiness for deployment, which means the system fulfills the user's business needs. Ideally, acceptance testing is performed by the intended users.
The distinction changes what you plan. For system testing you check the system against its technical specification. For UAT you check it against the users' needs and the business processes it must support. That is why the plan is built around acceptance criteria and user roles rather than around technical interfaces and code paths.
The forms of acceptance testing
The main forms are user acceptance testing (UAT), operational acceptance testing, contractual acceptance testing, regulatory acceptance testing, alpha testing, and beta testing.
- User acceptance testing is carried out by future users in an operational or simulated environment, focusing on user requirements and needs.
- Operational acceptance testing verifies readiness for operations, such as backup, recovery, maintenance, and support procedures.
- Contractual acceptance testing is performed against a contract's acceptance criteria, often signed off as a condition of payment or delivery.
- Regulatory acceptance testing verifies compliance with regulations, laws, and standards that govern the product.
- Alpha testing is performed at the developer's site by a selected set of users.
- Beta testing is performed by potential or existing users at their own locations, usually for commercial off-the-shelf software or software-as-a-service platforms.
A UAT plan commonly combines these forms. A regulated release might run UAT and regulatory acceptance testing in parallel, then sign a separate contractually required acceptance report. Identify which forms apply to your project before you decide the scope, participants, and criteria.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://glossary.istqb.org/en_US/term/acceptance-testing/1
Supports
- Definition of acceptance testing as formal testing with respect to user needs, requirements, and business processes to determine whether the system satisfies the acceptance criteria and to enable acceptance decisions.
- The statement in 01-intro.md that acceptance testing is validation, not verification.
- https://glossary.istqb.org/en_US/term/user-acceptance-testing/1
Supports
- Definition of user acceptance testing as testing by future users in a real or simulated operational environment, used in 00-novice.md and 01-intro.md.
- https://istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf
Supports
- Acceptance testing focuses on validation and demonstrating readiness for deployment (2.2.1).
- The six forms of acceptance testing: user, operational, contractual, regulatory, alpha, beta (2.2.1).
- Test plan purpose, test approach contents, entry and exit criteria, estimation, prioritization (5.1.x).
- Definition of Ready and Definition of Done as entry and exit criteria in agile (5.1.2, 5.1.3).
- Risk analysis and risk control and the definition of risk-based testing (5.2).
- User story elements (Card, Conversation, Confirmation) and the "As a ... I want ... so that" form (4.5.1).
- Acceptance criteria as conditions an implementation must meet to be accepted (4.5.2).
- Beta testing being not systematic, not measurable, with no guarantee of coverage (2.2.1).
- The quiz, cheatsheet, slides, and practice reference content on planning, estimation, and prioritization.
- https://www.gtb.de/wp-content/uploads/2023/10/ISTQB-CTFL-AcT_Syllabus_v2019_EN.pdf
Supports
- The role of acceptance criteria in requirements analysis and their good-practice rules.
- Acceptance Test-Driven Development and Behavior-Driven Development with Given-When-Then (1.2.3).
- Acceptance test cases as living documentation.
- Requirements-based acceptance test design and black-box techniques (2.2.1).
- Traceability between requirements, user stories, and test cases (2.2.1).
- The limits of beta testing within an acceptance strategy (2.3.2).
- The video script's claims about acceptance criteria and Gherkin.
- https://www.iso.org/standard/79428.html
Supports
- The test planning process and the monitoring and control process in ISO/IEC/IEEE 29119-2:2021.
- Inputs to planning: organizational test policy and strategy, project management plan, higher-level test plans, regulatory standards, and product documentation.
- The timeline event for the 2021 edition of 29119-2.
- https://wildart.github.io/ISO-29119-2-2013/
Supports
- The nine test planning activities TP1 Understand Context through TP9 Communicate Test Plan.
- The iterative nature of the risk- and strategy-related planning activities.
- The recorded content of a test plan including strategy, staffing, schedule, and risk mitigation.
- https://www.iso.org/standard/56737.html
Supports
- ISO/IEC/IEEE 29119-3 as the test documentation standard the CTFL syllabus points to for test plan structure.
- The timeline event that 29119-3:2013 supersedes IEEE 829.
- https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/
Supports
- The business-analysis perspective on acceptance, in particular the Solution Evaluation knowledge area.
- The 06-links.yaml recommendation to connect acceptance results to business value.
- https://github.com/sindresorhus/awesome
Supports
- TheJambo/awesome-testing is part of the canonical curated awesome list, which is why it anchors 09-awesome-links.yaml.
- https://github.com/TheJambo/awesome-testing
Supports
- Kiwi TCMS and TestLink are open-source test case management entries in the list.
- Testomatio is presented in the list as a modern TCMS syncing manual and automated tests.
- Courgette is presented in the list as declarative BDD UI testing with Gherkin.
- WireMock is presented in the list as an open source HTTP mock engine in Java.
- Xmind is presented in the list as a mind mapping tool for documenting test cases and strategies.
- The list's Awesome Cucumber suggested list leads to Cucumber and Gherkin tooling.
- https://kiwitcms.org
Supports
- The claim in 09-awesome-links.yaml that Kiwi TCMS describes itself as IEEE 829 compatible.
- https://www.testlink.org
Supports
- TestLink positioning as an open-source test case management system in 09 and 11.
- https://www.testrail.com
Supports
- TestRail positioning as test case management software for QA teams in 11-products.yaml.
- https://www.testmo.com
Supports
- Testmo positioning as a unified test management platform in 11-products.yaml.
- https://qase.io
Supports
- Qase positioning as a test management platform with a free tier in 11-products.yaml.
- https://www.practitest.com
Supports
- PractiTest positioning as end-to-end test management with requirement traceability in 11-products.yaml.
- https://www.testmonitor.com
Supports
- TestMonitor positioning as test management for business-facing teams in 11-products.yaml.
- https://www.smartbear.com/test-management/zephyr-scale/
Supports
- Zephyr Scale positioning as test management for Jira in 11-products.yaml.
- https://www.getxray.app
Supports
- Xray positioning as test management for Jira in 11-products.yaml.
- https://www.tricentis.com/products/unified-test-management-qtest
Supports
- qTest positioning as Tricentis unified test management in 11-products.yaml.
- https://azure.microsoft.com/en-us/products/devops/test-plans
Supports
- Azure Test Plans positioning as plan-based manual and exploratory testing in Azure DevOps in 11-products.yaml.
- https://www.opentext.com/products/application-quality-management
Supports
- OpenText AQM positioning as enterprise quality management in 11-products.yaml.
- https://centercode.com
Supports
- Centercode positioning as a user acceptance testing platform in 11-products.yaml.
- https://www.prefinery.com
Supports
- Prefinery positioning as beta program management in 11-products.yaml.
- https://www.applause.com
Supports
- Applause positioning as crowdtesting and digital quality services in 11-products.yaml.
- https://www.testlio.com
Supports
- Testlio positioning as managed QA and UAT with a network of vetted testers in 11-products.yaml.
- https://cucumber.io
Supports
- Cucumber positioning as open-source BDD tooling in 11-products.yaml.
- The timeline event that Cucumber and Gherkin appeared in 2008, via the BDD history page.
- https://www.specflow.org
Supports
- SpecFlow positioning as an open-source BDD framework for .NET in 11-products.yaml.
- https://standards.ieee.org/ieee/829/1217/
Supports
- The 1983 publication of IEEE 829, the Standard for Software Test Documentation, in the timeline.
- https://standards.ieee.org/ieee/829/1218/
Supports
- The 1998 revision of IEEE 829 in the timeline.
- https://standards.ieee.org/ieee/829/3787/
Supports
- The 2008 final edition of IEEE 829 in the timeline.
- https://standards.ieee.org/ieee/29119-3/5310/
Supports
- The 2013 publication of ISO/IEC/IEEE 29119-3 superseding IEEE 829 in the timeline.
- https://doi.org/10.1049/sej.1986.0003
Supports
- Paul Rook's 1986 Software Engineering Journal paper describing the V-model, cited in the timeline.
- https://en.wikipedia.org/wiki/V-model_(software_development)
Supports
- The V-model pairing development phases with verification and validation phases in the timeline.
- https://agilemanifesto.org/history
Supports
- The signing of the Agile Manifesto in 2001 in the timeline.
- https://en.wikipedia.org/wiki/International_Software_Testing_Qualifications_Board
Supports
- The founding of ISTQB in 2002 and its global qualification scheme in the timeline.
- https://www.istqb.org.cn/uploads/soft/20121023/istqbexamguidelines2005.pdf
Supports
- The delivery of the first CTFL syllabus in April 2005, effective July 2005, in the timeline.
- https://dannorth.net/blog/introducing-bdd/
Supports
- Dan North's Introducing BDD article and its Given-When-Then behavior format in the timeline.
- https://cucumber.io/docs/bdd/history/
Supports
- Aslak Hellesøy creating Cucumber in 2008 and the Gherkin format in the timeline.
- https://en.wikipedia.org/wiki/Cucumber_(software)
Supports
- Cucumber and Gherkin history in the timeline.
