2. Purpose of UAT
• The main Purpose of UAT is to validate end to end business
flow. It does not focus on cosmetic errors, spelling mistakes or
system testing. User Acceptance Testing is carried out in a
separate testing environment with production-like data setup.
It is kind of black box testing where two or more end-users
will be involved.
• UAT is performed by –
• Client
• End users
3. Need of User Acceptance Testing
• Need of User Acceptance Testing arises once software has
undergone Unit, Integration and System testing because
developers might have built software based on requirements
document by their own understanding and further required
changes during development may not be effectively
communicated to them, so for testing whether the final
product is accepted by client/end-user, user acceptance
testing is needed.
4. Acceptance Testing and V-Model
• In VModel, User acceptance testing corresponds to the
requirement phase of the Software Development life
cycle(SDLC).
5. Prerequisites of User
Acceptance Testing:
• Following are the entry criteria for User Acceptance Testing:
• Business Requirements must be available.
• Application Code should be fully developed
• Unit Testing, Integration Testing & System Testing should be
completed
• No Showstoppers, High, Medium defects in System Integration Test
Phase –
• Only Cosmetic error is acceptable before UAT
• Regression Testing should be completed with no major defects
• All the reported defects should be fixed and tested before UAT
• Traceability matrix for all testing should be completed
• UAT Environment must be ready
• Sign off mail or communication from System Testing Team that the
system is ready for UAT execution
6. Key points to be considered while
designing Acceptance Test Plan:
• It should be Detailed and Specific. Must include only what has
required for testing and what information is necessary for the
team to carry out testing.
• It should be Clear and Concise. No ambiguity. If at all there is
something that may lead to confusion, then elaborate on it,
but keep it short and effective.
• Each and every component in the document should be
written keeping only the Business Requirements in mind.
• Reliable and adaptable – It should be updatable as required in
future releases.
• Consistent – It should not have more changes in the future.
• Follow the template provided by the Organization or
Customer.
7. Acceptance Test Plan Template
• Title
<Mention Project Name with its release version if required. Say
Project_MainRelease1.0>
• Objective
<Mention the objective of the project. Explain the purpose of the
project and also mention the category of the end-users for
whom the project is intended. For Example: If the project is to
serve service for Bank employees/Sales Persons/Educational
institutes etc., then it has to be clearly mentioned. Also, it should
mention the reason for which that particular requirement has
been chosen.>
8. Revision History/Change Log
• <This should be in a tabular form with the below
information:
• Date: The date on which the document was modified.
• Modified By: Who has changed the contents of the document.
• Purpose: Why was the document modified.
• Version: Current Version of the document after modifications
(goes as 1.0, 1.1, 1.2, 1.3,… for a particular release. Next
release will start from 2, 2.1, 2.2, 2.3,…, The list goes on).
• Approved By: Who has approved the changes made (implicitly
means that the document has been reviewed and approved).
• The very first row in this table should be the document-
created details. Then follows the details of the changes
made.>
9. • Table of Contents
<Mention each and every component along with its page
number.>
• References
<Provide references to relevant documents for testing:
Requirement Specification Document, Use Cases, etc.>
• Scope
<Mention the scope of testing (Example: All the business
scenarios).>
10. • Introduction
<Clearly explain how the acceptance testing phase has reached
in the project starting from the development. Provide details
about the actions performed in this phase and how it was done.
Also, the different types of testing performed in this phase can
be detailed like Positive testing, Negative testing (not always),
etc.>
• Test Items
<Mention all the test items for this
phase: Features/modules/sub-modules etc. (Example: Client
Application, Server Application, etc.)>
11. • Features to be Tested
<Mention all the features that need to be tested: Basic
functionalities (Example: Search by different keywords,
navigations between modules and sub-modules, etc.), Security
features (Example: Registration to the website, login to the
website, transactions, etc.)>
• Features not to be Tested
<Explicitly mention all the features that are not to be tested like
Resilience to the server, database crashes, network delays, etc. >
• Approach
<Mention the approach to test in this phase. Provide details on
how the testing is performed (Example: Once all the acceptance
tests are executed, exploratory testing will be performed for a
very short duration to assess the ease and use of the product.
Each and every bug encountered will be logged in the bug
management tool and will be discussed in bug triage meetings
for RCA’s…)>
12. • Test Environment Details
<Mention testing environment details: Staging/UAT/Pre-Prod/
etc., Also mention Test Bed set up information
Entry Criteria
<Mention all the entry criteria for Acceptance Testing to begin.
Refer to Acceptance Testing – Part1 for more details.>
• Tests – If there are no separate Acceptance tests written
<List the series of tests to be conducted with each step described
in detail.
13. Each test must include:
• Test #.
• A description of what is being tested (Example: Verify whether a
user is able to create an account successfully).
• The business requirement to which this test maps (Traceability
Matrix) – Very important.
• Pre-conditions:
• State of the product before starting the testing (User should be
registered successfully but not activated the account, User should
have accessed the product at least 30 days ago, etc.)
• Any server conditions – Should the server be down for some time.
• Test Steps: Detailed numbered flow (Example: see below
• Open the application.
• Attempt to log in with valid credentials with Remember Me
checkbox selected).
• Expected Result: What is the expected behavior of the step>
14. • Exit Criteria
<Mention all the exit criteria for Acceptance Testing to end. Refer
to Acceptance Testing – Part1 for more details.>
• Resources
<Mention the names of all the members who will be a part of
the Acceptance Testing phase in proper order. Also, mention their
role in the phase.>
