Table of Contents

1.0 Introduction....................................................................................................................2
1.1Project Overview........................................................................................................2
1.2 Scope..........................................................................................................................2
1.2.1 In Scope.............................................................................................................2
1.2.2Out of Scope........................................................................................................2
1.3 Objective...................................................................................................................2
1.3.1 Primary Objective..............................................................................................2
1.3.2Secondary Objective............................................................................................2
2.0UA Tet !et"odo#o$y....................................................................................................2
2.1 Tet P"ae.................................................................................................................3
3.0 UA Tet %nvironment....................................................................................................3
3.1 UA Tet &e'top......................................................................................................3
3.2 UA Tet &ata.............................................................................................................3
(.0Prere)uiite of Uer Acceptance Tetin$*.....................................................................(
+.0Ana#yi of ,uine -e)uirement................................................................................(
..0-o#e and -eponibi#itie..............................................................................................(
(.1 UAT Team.................................................................................................................+
(.2Tet Partner................................................................................................................+
+.0UAT &e#iverab#e...........................................................................................................+
+.1 UAT Activitie...........................................................................................................+
+.2 UAT Sc"edu#e............................................................................................................
Tet -eportin$ and Ana#yi.............................................................................................
..0 UA Tet /ae.................................................................................................................
..1 UA Tet /ae............................................................................................................0
0.0UAT &efect...................................................................................................................0
0.1 UAT &efect Trac'in$................................................................................................0
0.2 UAT &efect Prioriti1ation..........................................................................................0
0.3 UAT &efect 2ifecyc#e................................................................................................0
3.0Aumption....................................................................................................................3
4.0-i'................................................................................................................................3
10.0Preparation Tip............................................................................................................4
11.0/"ec'#it.....................................................................................................................10
Project Name User Acceptance Test Plan
1.0 Introduction
The purpose of this document is to outline the User Acceptance Testing (UAT) process for the
[Project Name]. Project Sponsors from all participating departments are intended to revie this
document. Approval of this document implies that revieers are confident that folloing the
e!ecution of the test plan" the resulting s#stem ill $e considered full#%tested and eligi$le for
implementation.
UAT is to $e completed $# the &usiness 'epartments (UAT Team) that ill $e utili(ing the softare
and)or support departments. The testing is conducted to ena$le a user to validate that the
softare meets the agreed upon acceptance criteria.
1.1 Project Overview
['escri$e the project here]
1.2 Scope
1.2.1 In Scope
[*ist testing of functional and use case re+uirements" non%automated $usiness processes" user
interface" etc. here]
1.2.2 Out of Scope
[*ist s#stem integration" disaster recover#" $usiness continuit# and other e!clusions here]
1.3 Objective
1.3.1 Primary Objective
User Acceptance Testing is conducted to ensure that the s#stem satisfies the needs of the
$usiness as specified in the functional re+uirements and provides confidence in its use.
,odifications to the aforementioned re+uirements ill $e captured and tested to the highest level of
+ualit# alloed ithin the project timeline.
1.3.2 Secondary Objective
To identif# and e!pose defects and associated ris-s" communicate all -non issues to the project
team" and ensure that all issues are addressed in an appropriate manner prior to implementation.
2.0 ! Test "et#odolo$y
[.!plain the method of testing" descri$e test phases" and applications to $e tested]
User Acceptance Testing ill $e conducted primaril# $# the end users (i.e. Su$ject ,atter .!perts).
Users ill e!ecute all [Project Name] test scripts referenced in section /.0. Users ma# also
1
Project Name User Acceptance Test Plan
perform additional tests not detailed in the plan $ut remain relevant and ithin the scope of the
project. UAT progress ill $e reported $ased on the percentage e!ecuted test cases and other
relevant testing activities.
Users ill report issues and defects to the $usiness anal#sts for documentation and escalation.
These incidents ill $e descri$ed" prioriti(ed" and trac-ed $# using screen captures" ver$iage" and
steps necessar# for '.2.*3P,.NT to reproduce the defect. 4nformation on defect prioriti(ation
can $e found in section 5.1.
2.1 Test Phases
Unit testing (single transaction)
Business Process testing (unit test strings within the same functional module like SD,
MM, PP, FI, C, etc!)
Integration testing (Business Process testing including the integration "oints with other
functional modules)
Interface testing
Data con#ersion testing (test the data load "rograms)
Con#erted data testing (test the con#erted data at "erforming #arious functions)
User $cce"tance %esting
&egression %est
Batch 'o( testing (test (atch "rograms, timing, and se)uence)
Securit* %est
Performance + #olume testing
$n* "ositi#e and negati#e testing re)uirements for securit* or transactions
Ad hoc testing of un"lanned #ariations and #ariants
3.0 ! Test %nvironment
['etail the environments used for testing. *ist application configuration" test locations" U6*s" etc.]
Applica$le 4P addresses and U6*s should $e provided to the UAT Team and all or-stations
should $e configured appropriatel# for access to the test environment.
3.1 UA Test Desktops
.ach test participant ill $e provided ith a chec-list to verif# access to all applications ithin the
defined scope of testing. The tester ill then log in and validate the sign%on data generates the
e!pected results for each application. This includes" $ut is not limited to" correct menus"
permissions" and general access. An# applications identified as missing from the test or-station
des-tops should $e formall# re+uested and installed prior to testing.
3.2 UA Test Data
[*ist the re+uired data that must $e received $efore testing $egins % i.e. access to s#stems"
accounts" etc.]
Access to test data is a vital component in conducting a comprehensive test of the s#stem. All
UAT participants ill re+uire usage of test accounts and other pertinent test data hich should $e
7
Project Name User Acceptance Test Plan
provided $# end user support upon re+uest. Participants not currentl# utili(ing test data must
receive appropriate clearance and)or permissions to perform desired actions in the UAT
environment. All user roles should full# emulate production in the UAT path. 8ompletion of an
online access re+uest ma# $e re+uired in order to create test accounts.
&.0 Prere'uisites of ser !cceptance Testin$(
Business Requirements must be available.
Application Code should be fully developed
Unit Testing, ntegration Testing ! "ystem Testing should be completed
#o "ho$stoppers, %igh, &edium defects in "ystem ntegration Test Phase
'nly Cosmetic error are acceptable before UAT
Regression Testing should be completed $ith no ma(or defects
All the reported defects should be fi)ed and tested before UAT
Traceability matri) for all testing should be completed
UAT *nvironment must be ready
"ign off mail or communication from "ystem Testing Team that the system is ready for
UAT e)ecution
).0 !nalysis of *usiness +e'uirements
One of the most important activities in the UAT is to identify and develop
test scenarios. These test scenarios are derived from the following
documents:
Pro(ect Charter
Business Use Cases
Process +lo$ ,iagrams
Business Requirements ,ocument-BR,.
"ystem Requirements "pecification-"R".
,.0 +oles and +esponsibilities
[Note team mem$ers specificall# &usiness Anal#st(s) and S,.(s) performing UAT. Testing
participants should include representatives from all areas involved in the s#stem]
9e#s to a successful UAT process involve open channels of communication" detailed
documentation" and a$ove all" clearl# defined roles and responsi$ilities. .ach team mem$er must
function fluidl# in a group setting as ell as or- independentl# for e!tended periods of time. UAT
is largel# a colla$orative process and test results must $e anal#(ed from different perspectives and
$# team mem$ers ith various levels of e!pertise across the $usiness to ensure success.
:
Project Name User Acceptance Test Plan
4.1 UAT Team
The test team is comprised of mem$ers ho possess a thorough -noledge of the current s#stems
and processing methods" i.e. S,.s. These team mem$ers ill $e $etter a$le to initiate test input"
revie the results" and $e more intuitivel# familiar ith the impact on other related $usiness issues
and staff activities. ,em$ers should $e detail%oriented and $e diligent in collecting proper
documentation to support the test results. Team mem$ers are selected $ased" in part" on the
a$ilit# of management to reassign the dail# duties the# ill have to forgo hile performing the
testing.
All team mem$ers ill $e presented ith an overvie of the test process and hat their specific
role in UAT ill $e. The &usiness Anal#st;s role in the UAT process is to oversee testing $#
assigning scripts to S,.s" providing general support" and serving as the primar# UAT contact point
throughout the test c#cle. The &A ill $e e!pected to filter out an# duplicate defects found and
escalate high priorit# issues to the team in a time sensitive manner.
4.2 Test Partners
[*ist an# third parties that ill $e participating in the UAT proces. 'escri$e test strateg# if third
part# is involved.]
).0 !T -eliverables
The folloing sections detail milestones crucial to the completion of the UAT phase of the project.
3nce all dependent milestones have $een completed" UAT ill formall# sign%off on the s#stem;s
functionalit# and distri$ute an e%mail to all project sta-eholders.
5.1 UAT Activities
All core UAT activities are defined $elo<
dentify UAT Team = &usiness Anal#st lists S,.s that ill ta-e part in testing for the
project. The Project Sponsor is often the source of information for the team list. A full
description of team mem$er attri$utes is detailed in section :.0.
UAT Plan / A strateg#%$ased document defining test methodolog# and criteria is
distri$uted to the team.
UAT Plan Team Revie$ / Session ith $usiness sta-eholders to revie plan and provide
feed$ac- and sign%off.
UA Test Cases / A document that details each specific test case that ill $e performed
during the UAT process.
Test ,ata Acquisition / 6eceipt of accounts and test environment data from >A re+uired
to e!ecute test scripts. #ote0 one full $ee1 of lead time is needed to acquire test accounts
from 2A.
UA Test Cases = A detailed step%$#%step $rea-don of each individual test case.
UA Test Case Revie$ = Approval from $usiness team and)or third parties on completed
scripts.
?
Project Name User Acceptance Test Plan
,es1top 3alidation / 2alidation of installed applications and configuration necessar# for
testing.
UAT *nvironment 3alidation / 2alidation of connectivit# and e!pected results in the test
environment for each end user participating in testing.
Test Case *)ecution / 8ompletion of all test scripts $# test team.
,efect Trac1ing / 'efects ill $e entered and trac-ed via spreadsheet $# the &usiness
Anal#st and)or Project ,anager. .ach entr# ill include detailed information a$out each
defect.
UAT Touch Point / 6egularl# scheduled meeting to evaluate UAT progress and
outstanding defects.
UAT "ign4'ff / @ormal sign%off indicating the s#stem satisfies the needs of the $usiness
as specified in the functional re+uirements and provides confidence in its use.
5.2 UAT Sche!"e
[*ist -e# delivera$le dates and milestones in the ta$le $elo]
Activity Estimated Completion Date Initials
4dentif# UAT Team
UAT Plan
UAT Plan Team 6evie
UA Test 8ase Aal- Through
Test 'ata Ac+uisition
UA Test Scripts
UA Test Script Approval
'es-top 2alidation
UAT .nvironment 2alidation
Test Script .!ecution
UAT Sign%3ff
Test #eportin$ an Ana"%sis
o %est Metrics
o Defect Management
,.0 ! Test Cases
['escri$e test case approach and provide lin- to full document]
Test cases provide a high%level description of the functionalit# to $e tested. All regression and ne
functionalit# test cases are contained in the .!cel spreadsheet BUA Test 8asesC availa$le at<
[insert h#perlin- to UAT folder in Project 'irector# here]. The team plans to leverage relevant >A
/
Project Name User Acceptance Test Plan
test cases for project specific functionalit#. .ach test case $ased on ne functionalit# ill
reference a specific functional re+uirement.
&.1 UA Test 'ases
Test cases contain a detailed step $# step $rea-don of each test case to $e performed $# the UA
tester. .ach script contains< test case num$er" product" test description" re+uirement num$er"
re+uestor" tester" action to $e performed" test data to $e utili(ed" e!pected results" error
descriptions (if applica$le)" pass)fail results" date tested" and an# additional comments from the UA
tester.
The UA test scripts are contained ithin the UAT test case spreadsheet and can $e accessed via
h#perlin- from each individual test case.
..0 !T -efects
['escri$e the defect capture and prioriti(ation methods]
'efects ill $e entered and trac-ed via spreadsheet $# the &usiness Anal#st during the UAT
process. .ach entr# ill include detailed information a$out each defect.
(.1 UAT De)ect Trackin$
Team mem$ers ill $e provided ith instruction on ho to effectivel# e!ecute test scripts" as ell
identif#" capture" and report defects. Utili(ation of ,icrosoft 3ffice applications and screen capture
programs (e.g. Snag4t) ill $e re+uired to document defects for escalation. Team mem$ers ill $e
e!pected to present findings on regularl# scheduled touch point meetings in the event that end
user support and)or 'evelopment re+uire additional detail.
(.2 UAT De)ect Prioriti*ation
The &usiness Anal#st ill function as a liaison $eteen the $usiness and development on matters
of prioriti(ing and classif#ing defects. 'efects found in UAT can $e assigned one of four (:) levels
of severit#<
Regulatory = This re+uest is regulator# and mandator#
Critical = Testing defects that due to the comple!it# of the function or the scheduled dates
are putting the implementation date at ris-. No or-around e!ists.
%igh = Testing defects occurring in a less comple! function of the application ith sufficient
time to resolve $efore the implementation date = $ut must $e implemented as scheduled.
A or-around has $een identified and is listed in the defect.
5o$ = Testing defect occurring in a function that are simple to fi! or could $e e!cluded if
not resolved $# the scheduled implementation date.
(.3 UAT De)ect +i)ec%c"e
'efects must $e clearl# captured and escalated to ensure prompt resolution $# development.
.ach defect su$mitted $# UAT ill $e assigned a priorit#" or-ed $# development" resolved" and
re%tested $# UAT prior to closure. The folloing is a snapshot of the standard defect lifec#cle<
5
Project Name User Acceptance Test Plan
/.0 !ssumptions
[4dentif# an# assumptions prior to UAT]
The folloing are -e# assumptions made $# UAT prior to the commencement of the acceptance
test phase<
>A testing has $een completed ithout an# outstanding critical defects.
The UAT environment ill $e availa$le for testing.
8onfiguration information and test data has $een provided and applied as designed.
All des-tops identified for UAT ill have the necessar# softare applications installed.
Su$ject ,atter .!perts (S,.) are availa$le to participate in testing.
0.0 +is1s
[4dentif# an# ris-s that could impact UAT]
&elo are ris-s that could potentiall# impact the UAT process and prevent its successful and timel#
completion<
Unsta$le UAT environment.
4nade+uate test data.
4ncorrect softare version(s).
@ailure to emulate production environment.
*ac- of human resources.
D
Project Name User Acceptance Test Plan
10.0Preparation Tips
0. Formal scripts = prepare formal scripts for the $usiness users to run. 4f #ou can re%use
an# of >A;s scripts" all the $etter. At a minimum" use #our use cases to $uild test scripts.
As an added $onus" these scripts ill serve as training to the $usiness users on ho to
use the s#stem after deplo#ment. Ae suggest #ou have scripts for testing $oth functionall#
and migrated data.
1. Informal scripts = prepare informal" unstructured scripts for the $usiness users to run as
ell. 4 strongl# encourage #ou to do these in addition to formal scripts" in that these are the
ones that ill pull out defects a$out ho the s#stem isn;t intuitive to use. 4n addition" the#
ma# thin- to test things #ou didn;t formall# script. As an e!ample" this t#pe of script might
simpl# sa# B*ogin to the s#stem and ta-e a training course.C And #ou are hoping it;s
intuitive to the user to figure out ho to do that on their on.
7. Traceability % much of the value in doing tracea$ilit# comes from the a$ilit# to identif#
holes = such as missed functionalit# or tests
:. Use a tool = e strongl# encourage #ou to put #our scripts in a tool and teach the
$usiness users ho to use that tool. @or e!ample" >ualit# 8enter is a tool that or-s ell
for this.
?. Internal releases % offer a a# for the customer to ac+uire hands%on evaluation of s#stem
functionalit# and usa$ilit# $efore deplo#ment in a live environment.
Eigh >ualit# &uilds< the $uilds must $e ro$ust enough for users to interact ith the
s#stem and provide meaningful feed$ac-.
8ustomer 8ommitment< the customer must commit to revieing each interim $uild
and providing feed$ac- to the development team.
.nd User 4nvolvement< end users of the s#stem must $e involved in the revie
process.
6evie .nvironment< the $uilds should $e deplo#ed to a staging environment that
is as close to a replica of the production environment as possi$le.
/. Master data = create master data that can $e used for testing $# the $usiness users. This
includes logins and passords and an# data the# must loo- at and)or consume in the tool.
A great starting place to determine hat data #ou need is to loo- at #our &usiness 'ata
'iagrams" and then of course loo- at #our scripts. @or e!ample" if #ou have a training
s#stem" upload sample training courses for them to ta-e during UAT. Fou should also
organi(e this master data into a format such as a spreadsheet $# test case" so the# can
+uic-l# reference hat data the# should use in each script.
5. UAT Kic!off dec = 8reate a slide dec- to -ic- the UAT indo off ith. This -ic-%off
should include the scope of testing" a reminder a$out the value of the s#stem" a reminder
that it is a testing phase and the# ill find defects in the s#stem" and instructions on ho to
perform UAT. Fou need to teach them a$out using the tools" ho to login" and even here
to go to access the s#stem.
D. UAT User Man"al = 8reate a manual for the users to +uic-l# reference to hile the#
e!ecute the UAT scripts. Fou can hopefull# reuse some or all of #our -ic-%off slides. Fou
definitel# must include here to access the s#stem (U6*s)" logins" and here to find
master data.
G. Pre!r"n scripts = 4deall# #ou should pre%run the scripts $efore the $usiness users tr# to
e!ecute them. Fou are familiar ith the s#stem" so #our e#es on the scripts ill $e loo-ing
G
Project Name User Acceptance Test Plan
for things that are not o$vious or incorrect steps. This ill help ensure a much more
smoothl# run UAT.
0H. Teac# t#em #o$ to $rite a %ood defect = 4f #ou ant to avoid a lot of manual la$or
#ourself" teach the $usiness users ho to enter their on defects into a defect trac-ing
s#stem (and #es" 4;m assuming #ou have oneI). Fou need to teach them hat information
to include (logins" urls" and steps to recreate) and ho to set severit# and priorit# values if
appropriate.
00. Coordinate b"ild sc#ed"le $it# dev & ,a-e sure #our dev team is on$oard ith #our
UAT testing schedule so that the# don;t do a $uild hile users are tr#ing to test. And more
importantl#" if the# do a $uild overnight that the# don;t ta-e the s#stem don ith a $ro-en
$uildI 4n general #ou need to coordinate ith #our entire 4T teamJ 4 just call this one out as
the# have an immediate a# to cripple testing $# accident.
01. 'or $it# a b"siness o$ner so t#ey tr"ly o$n acceptance = All of that said" #ou need
to ma-e sure there is someone in the $usiness ho ons the UAT process. Fou are
simpl# here to facilitate it going ell and do a lot of the prep or- for them. &ut trul#" the#
must $e the ones ho on acceptance of the s#stem or the# ill never actuall# adapt it for
use. So ever# step of the a# as #ou go through #our prep tas-s $e sure #ou are getting
the $usiness UAT oner;s $u#%inI
11.0C#ec1list
0. 4dentif# UAT $usiness sta-eholder
1. &usiness sta-eholder 4's UAT testers
7. &A creates training materials to help the $usiness users hen testing the s#stem. These ill
$e updating during testing
:. >A rites test scripts
?. &A revies test scripts ith >A to ensure the# are correct and ritten appropriatel#
/. &A completes master data to test
5. &A assigns test scripts to $usiness testers
D. &A revies test scripts ith $usiness testers to ensure users are capa$le of e!ecuting test
scripts
G. &A or-s ith 4T to ensure the s#stem on hich UAT ill $e conducted is clean and has no
e!isting data or tests from >A
0H. &A creates 6oles K 6esponsi$ilites ,atri!" including all $usiness testers. This ill sho
hat the $usiness tester ill $e capa$le of testing and his permissions ithin the s#stem
00. &A creates testing schedule and allocates da#s)times hen $usiness testers ill $e
needed to test
01. &A revies the testing schedule ith the $uiness sta-eholder and it is approved
07. &A creates manual for ho to use the defect management s#stem and e!plains hat is a
defect (this ill reduce the BS#stem doesn;t or-C t#pe of defect)
0:. &A ensures $usiness users have access to defect management s#stem
0?. &A or-s ith each $usiness tester to ensure the defect management s#stem is on their
computer and the# can login
0/. &A reserves UAT room and completes room logistics (netor- access" projector access"
etc)
05. &A communicates ith $usiness testers here the UAT room is located
0H
Project Name User Acceptance Test Plan
1H. Plan Lo)No%Lo ,eeting" hich determines hether UAT passed and if the application ill
proceed to release" alpha testing" etc
00