Guidelines for User Acceptance Testing

11/26/2018 8:02 AM Page: 1 of 11 402958466.doc

 Table of Contents

Guideline for User Acceptance Testing..............................................................................3

Objective........................................................................................................................... 3
Entry Criteria..................................................................................................................... 3
Development of User Acceptance Test Plan......................................................................3
Review and approval of User Acceptance Test Plan.........................................................3
Environment and Data setup Coordination........................................................................3
Development of User Acceptance Test scenarios/test cases / scripts...............................3
Prioritization of Test scenarios/test cases..........................................................................3
Identification of Business scenarios..................................................................................3
Test Scripts....................................................................................................................3
Test steps...................................................................................................................... 3
Mapping of Test scripts to test steps & Test scripts to Test scenarios/test cases...........3
Test setup...................................................................................................................... 3
Data Specification Preparation for the Test scenarios/test cases...................................3
Review of Test scenarios/test cases & Business Sign-off..............................................3
Test Execution...............................................................................................................3
Running the tests........................................................................................................... 3
Defect Management Process............................................................................................3
Defect Status Description..............................................................................................3
Re-Tests........................................................................................................................ 3
Test Exit......................................................................................................................... 3
Mandatory Activities during User Acceptance Testing.......................................................3
Test exit criteria.............................................................................................................. 3
Test Summary Report.......................................................................................................3
Test Audit.......................................................................................................................... 3
Production Migration Review.............................................................................................3
Template........................................................................................................................... 3
Deliverable Acceptance.....................................................................................................3
Deliverable Revision Log..................................................................................................3

11/26/2018 8:02 AM Page: 2 of 11 402958466.doc

Guideline for User Acceptance Testing

Objective
The objective of User Acceptance Testing is to verify that any solution, provided through various
applications, hardware and business procedures, meets the business requirements. The purpose of
the acceptance testing is to give confidence to the business sponsor and end users that the system
is working as per business requirements. Moreover, it gives confidence to the users that system
is ready for operational use. In a nutshell, the Acceptance testing is a demonstration rather than a
test.

Entry Criteria

 Successful completion of Integration test with all the business flows working properly.
 No unresolved Critical / High / Medium priority defects exist.
 Availability of test scripts and data for all business requirements
 Availability of traceability matrix mapping business requirements with test scripts.
 Availability of test environment
 Availability of execution support for User acceptance test.

Development of User Acceptance Test Plan

The User Acceptance Test Plan describes the features and functionalities that are to be tested
during User Acceptance Testing and ensures conformance with business requirements. It
provides information on the approach, business flows to be tested, functionality not in scope,
entry and exit criteria, details of test environment, data, usage of test tool, known risks and
mitigation approach.

User acceptance plan has to be prepared using approved requirement specification and should
follow the template approved by the program.

User Acceptance Testing is a means of testing the solution as a whole to verify it meets the
business requirements from the usability perspective. In other words, it tests whether the solution
provided meets the business requirements from the end-to-end usability perspective.

11/26/2018 8:02 AM Page: 3 of 11 402958466.doc

Review and approval of User Acceptance Test Plan

Once the UAT plan is ready, it should be routed for review by the project team. The feedback
received need to be discussed before incorporating them back to plan. The updated plan should
be routed for approval by project manager, test manager, business analysts and the business
sponsor.
Note: the User acceptance plan should NOT be changed unless there is a written communication
from Program Leadership. If there are any changes to business requirements, the plan has to
undergo review and approval process again.

Environment and Data setup Coordination

Test lead works with the release management team to ensure availability of test environment and
data requirements for User Acceptance tests.

Note: User Acceptance Tests can be performed either on integration test environment or on a
dedicated test environment which is a facsimile of production environment.

Development of User Acceptance Test scenarios/test cases / scripts

The User Acceptance Test scripts should be developed based on the User Acceptance Test Plan
and Requirements specification document. The test scenarios/test cases prepared / identified for
user acceptance test have to identify all business functionalities, as per business requirement
specifications.
The test scripts need to be mapped to requirements to ensure full coverage of requirements. This
will be done with the aid of a traceability matrix.
A test scenario is a real life business requirement for an end user and without which the user can
not perform day-to-day business activities.

The scenario / script has to be prepared as per program approved template

11/26/2018 8:02 AM Page: 4 of 11 402958466.doc

Prioritization of Test scenarios/test cases

Risk based test approach will be used to address testing requirements of all functionalities and,
testing will be prioritized based on the criticality of a component from a functional perspective.
All components involved with testing will be identified with two parameters ‘Probability of
failure and impact of failure’ on a scale of 1 to 5 [higher the number, higher is the probability of
failure and impact of failure] and all components identified with highest/high “probability of
failure” and highest/high “impact of failure” will be tested early in the test cycle [testing will be
prioritized] and test defects from these components to be fixed on priority basis.

Functionality Business Probability of failure Impact of failure

Risk (Scale 1 to 5) (Scale 1 to 5)
associated

Note: 5 - Highest; 4 – High; 3 – Medium; 2 – Low; 1 - Lowest

 Highest – key process/function, will be used extensively from day 1, with no opportunity
to workaround or defer
 High – key process/function, will be used during first week, but with be opportunity to
workaround or defer if non-functional
 Medium – key process/function – will be used within a fortnight of go-live
 Low – secondary process/function or key process function with ‘rare’ data variants
 Lowest – others (generally cosmetics).

Identification of Business scenarios

There are business flow requirements written for the usage of individual applications such as
People soft, Data warehouse. These scenarios give step-by-step instructions for any operations
that can be performed by using the applications. A test scenario/test case can have multiple test
scripts.

Test Scripts

Each test scenario/test case would comprise of the test scripts that are required to execute the test
scenario. Each test script identifies a definite functionality to be performed.

11/26/2018 8:02 AM Page: 5 of 11 402958466.doc

Test steps

Each test scenario/test case would comprise of multiple test scripts that are required to execute
the test scenario. Each test script may have multiple test steps which are atomic in operations.
Each step would have the appropriate result attached to it so that during execution phase it would
help to track the status of each step.
.

Mapping of Test scripts to test steps & Test scripts to Test scenarios/test cases

The next step in test preparation would be mapping all the test scenarios/test cases/test cases to
the test scripts and test scripts to test steps.
The test scenarios/test cases need to be mapped to requirements.

Test setup

Any setup required for executing the scenarios have to be mentioned in the beginning of the test
suite. This consists of information on accessing the application, login details, any dependencies
between test scenarios/test cases / execution order, data requirements, who executes it etc.

Note: Prerequisite would define the basic set of criteria to be met for starting the execution of the
test scenario.

Data Specification Preparation for the Test scenarios/test cases

Before getting into the test execution, the final step of the test preparation is preparation of Data
Specification for the test scenarios/test cases identified. This activity involves identification of
data set that is going to be used for execution of test scenarios/test cases for UAT and this data
has to be populated in the test environment.

Review of Test scenarios/test cases & Business Sign-off

Every Test Scenario/test case has to be reviewed by business analyst or subject matter
expert to ensure it correctly represent the business flow. Test Case Review Checklist can be
used for Review and approval process

Note: Test Director will be used for these purposes.

Each business review is required to:

11/26/2018 8:02 AM Page: 6 of 11 402958466.doc

  Review each test scenario/test case identified with specific to a business requirement.
 Confirm the relevance and priority of the test scenario/test case, or confirm the relevance
of the test scenario/test case but advise a different priority, or advise that the test
scenario/test case is not relevant.
 Review coverage of a particular functional area / discipline in terms of the set of the test
scenarios/test cases that they have been assigned, and identify additional test
scenarios/test cases where appropriate

Once review of the scenarios is over and all the appropriate changes are made, the next
step would be to obtain sign-off for the test scenarios/test cases identified from the
business.

Test Execution

User Acceptance Testing will be performed in the specified environment. The identified
test scenarios/test cases will be executed by the Subject matter experts(SME) with the aid
of testing team and Process team.

Running the tests

Before a decision is taken to start the execution for any phase, the entry criteria is used as
the checkpoint. If the entry criteria are not met, either the test execution will not start or
the test execution will start but all variations from the defined entry criteria will be
formally documented as project risks, and action will be taken to mitigate the risks.

Tests are run in accordance with the relevant test schedule, which were updated as required
to reflect changes in circumstances (e.g. resource availability, outstanding application
problems etc.).

The Subject matter expert will update the hard copy of the test scenario header sheet with
details of their name, date plus other pertinent information (or in Test Director if available
for UAT). As they step through the scripts documented within the scenario, they will either
record each step as having ‘passed’ – where the actual result matches the expected result
documented on the script/data specification, or where there is a deviation from an expected
result, a ‘Defect’ will be raised. This will follow the Defect management process defined
at program level.
Test evidence, in the form of screen prints, run logs (for batch processes), hard copy
reports and tester sign offs will be collected during execution, and these will be retained for
future inspection/audit. Softcopy of these proofs will be attached in Test Director.

A business assurance review will be carried out at the conclusion of each test cycle to
ensure that the proposed level of coverage has been provided during test execution

Defect Management Process

11/26/2018 8:02 AM Page: 7 of 11 402958466.doc

Errors noticed during testing are documented in Test Director and assigned to the
development team for fixing. User Acceptance Testing will be closed after all the observed
errors have been fixed by the development team and re-tested by the Subject matter
experts(SME). The details of errors and fixes will be recorded in Test Director.

A Defect is a deviation between the actual result obtained by executing a test script, and the
expected result that is (usually) documented prior to the start of the test. Defects are due to
a variety of causes that include:
 Errors in the test scripts
 Faults in the software
 Environment problems
 Problems / inaccuracies in design documentation, business procedures etc.
 Data errors
 Test pre-requisites not being met
 Tester’s misinterpretation of expected results

When a Defect is raised, the Subject matter expert performing the test and test co-ordinator will
take a view on whether the test can be continued or whether it should be abandoned or placed on
hold, pending resolution. Each Defect is assigned a priority that would decide the criticality of
the issue. The priorities and their definition of criticality are defined in Defect Management
Process.

Defect Status Description

For valid defect status description, refer to Defect management Process.

Re-Tests

Re-tests are necessary where a test has failed, and the original test run has been abandoned.
When resolution for the incident has been provided, re-tests will be planned in and included in
the test schedule, and will be run as described earlier in the section. If the failure of the original
test has resulted in corruption of the data that was specified for the test, a new set of data meeting
the relevant conditions and test pre-requisites be identified and used.

Test Exit

The UAT stage will be deemed to be complete when all exit criteria have been met or the
decision is taken to close the UAT stage without all of the exit criteria being met. There is
a set of exit criteria defined for the UAT phase, which is listed out below.

At the end of the test execution stage of UAT, a review of the exit criteria will take place and the
results will be documented in the UAT exit report. The exit report will be presented to business
representatives and program management who will be asked to approve the closure of the UAT
stage through sign off of the exit report.

11/26/2018 8:02 AM Page: 8 of 11 402958466.doc

Mandatory Activities during User Acceptance Testing
# Does What Who When How
1 Prepares Test After reviewed Using the
User Coordinator Requirement and specified
Acceptance design document is template
Test plan available
2 Develops Test After reviewed Updates in
User Coordinator Requirement and Test Director
Acceptance design document is
Test cases available
3 Reviews process After preparation of Ensures
User team User Acceptance Test adequacy of
Acceptance cases test case
Test cases coverage
and approve
4 Executes Subject After reviewed code is As per User
User matter available Acceptance
Acceptance expert(SME Test plan and
Test cases ) records
results in
Test Director
5 Fixes issues Developer Found during User Fixes issues
Acceptance Testing and retests
6 Monitors Test On a periodic basis as Use data
progress Coordinator per User Acceptance available in
and metrics Test plan Test Director
reporting

Test exit criteria

The test exit criteria should be documented in User Acceptance Test Plan.

 Successful execution of all user acceptance test scripts; reviewed and approved by subject
matter experts / business sponsor.
 No Critical / High / medium priority defect exists
 Business workarounds have been formulated, tested and agreed for any pending minor
defects
 All deliverables are made available to the program office.

Test Summary Report

11/26/2018 8:02 AM Page: 9 of 11 402958466.doc

Test summary reports will be generated at the end of UAT test phase depicting the status of
defects; information on what went wrong, what went right, lessons learnt etc. This report helps
management in making decision before entering to next test levels. Test Summary to be filled in
program approved template.

Test Audit

Test Audit is conducted using the program approved template.

Production Migration Review

Review of the User Acceptance Test results, Test audit reports.

Template

For User Acceptance Test case template, refer -Test Plan template.doc

11/26/2018 8:02 AM Page: 10 of 11 402958466.doc

Deliverable Acceptance

Name Role Signature Date

Deliverable Revision Log

Date Change Description Author Approved

ID By
April 0.1 Initial Release Santosh Bungle
4,
2005

11/26/2018 8:02 AM Page: 11 of 11 402958466.doc