APPENDIX A
UAT CHECKLISTS
1. Initiating the UAT Project (start of the development project)
2. Planning the UAT (as soon as agreed test basis deliverables are available for planning)
3. UAT Test Design (as soon as planning is complete)
4. UAT Test Execution (when the system is ready for test)
5. Release Decision (when the delivery was scheduled)
6. Post-UAT Actions (as soon as UAT is complete)
INITIATING THE UAT PROJECT CHECKLIST (SPONSOR)
1. Identify the key stakeholders (see)
• by name and role
• agree responsibilities/accountability for the system
• agree business intent and objectives for the system
• agree resources to be made available for UAT
2. Select a team leader (see Chapter 4)
• decide selection criteria
• decide internal or external recruitment
• initiate selection process
• interview shortlist
• select a candidate
3. Communicate the business intent, objectives and acceptance criteria of the system (see Chapter 2)
• communicate the business intent, objectives and acceptance criteria to the team leader
4. Agree on the UAT team resources (see Chapter 4)
• team size and expertise
• accommodation
• test environments
• tools
• training
5. Agree on documentation to support UAT (see Chapters 2 and 6)
• RS
• business processes
• user expectations
• any need to gather user stories/use cases
• test management tools/processes
• version control
• IM
• test logging
• test reporting
6. Agree on decision making structures (see Chapter 9)
• decision making process at delivery
• authority for release decision
• information required to enable decision making
• acceptance criteria
• quality of requirements and specifications
• test coverage
• stability of the system
• outstanding incidents
7. Select the UAT team (see Chapter 4)
• decide key roles
• business analyst
• testing specialist (with experience)
• tool specialist
• decide budget for staff
• decide skill requirements
• decide to hire or train skills
• create hiring specifications
• interview shortlist
• hire team
• identify training needs for each individual
8. Initiate UAT training (see Appendix C)
• decide training objectives
• in-house or external
• design or select course(s)
• provide introduction to UAT as a starter
• decide incremental training required
• draw up training programme
9. Form an initial project plan for UAT (see Chapter 6)
• identify key dates
• availability of RS
• availability of software/system to test
• availability of tools/environments
• UAT testing schedule
• planned release date
PLANNING THE UAT PROJECT CHECKLIST (UAT TEAM LEADER)
1. Identify the method of software/system acquisition to determine the best approach to UAT (see Chapter 1):
• in-house
• outsource
• COTS
• license
2. Ascertain whether the business intent and the user expectations have been captured and are measurable (see Chapters 2 and 6)
3. Verify that business requirements have been captured (see Chapters 2 and 6)
• unambiguous
• correct
• implementable
• necessary
• verifiable
• prioritised
4. Verify that all the requirements types are included (see Chapter 2)
• functional
• informational
• behavioural
• environmental
5. Write the acceptance criteria or check that the acceptance criteria are appropriate (see Chapters 2 and 6)
6. Ensure the scope is relevant, clear and unambiguous (see Chapter 2)
7. Capture or verify the business processes (see Chapters 2 and 6)
8. Evaluate the current documentation and its suitability to serve as a test basis (see Chapter 6)
9. Establish the FTP and TDP as the processes to be followed for UAT testing and the creation of the test documentation (see Chapter 3)
10. Build a plan to establish an adequate test basis and test using the FTP and TDP approach. Allow for regression testing and defect investigation/rework/retest (see Chapter 6)
11. Identify effort and elapsed time for UAT and any impact on the currently scheduled delivery date and report to the sponsor (see Chapter 6)
12. Ensure management controls are in place for test documentation and in preparation for test execution (see Chapter 6)
• version control
• IM
• test logging
UAT TEST DESIGN CHECKLIST
1. Establish the entry criteria for UAT (see Chapter 6)
2. Review test scripts where available (see Chapters 3 and 6)
3. Define the UAT strategy (see Chapters 3 and 7)
4. Review existing test conditions where available and write new test conditions (see Chapters 3 and 7)
• uniquely referenced to requirements
• at least one per requirement
• logical statements that can be verified by testing
• only outcomes are true or false
• all test conditions for a requirement must be true
5. Review existing test cases where available and create new test cases based on the test conditions (see Chapters 3 and 7)
• uniquely referenced to test conditions
• test design techniques
• EP
• BVA
• use case testing
• test by process
• test by data sequence
• test by post-condition and precondition match
• test by time sequence
• test by priority
6. Write test scripts based on the test cases (see Chapters 3 and 7)
• uniquely referenced to test cases
• high level test scripts or detailed test scripts
• depends on the test
• depends on the tester
• test data included or referenced
7. Test coverage requirements (see Chapters 3 and 7)
• minimum would be requirements coverage
• coverage can be by functions or structure
• essential to ensure adequate testing is achieved
• only effective measure of how much testing has been done
UAT TEST EXECUTION CHECKLIST
1. Check availability of test environment(s) (see Chapters 1, 6 and 8)
2. Define high level test schedule against UAT strategy to achieve priorities, e.g. risk based (see Chapter 8)
3. Define detailed test schedule to achieve best use of resources (people, environments, skills) and best completion date (see Chapter 8)
4. Ensure the test log is kept up to date (see Chapter 8)
• captures all tests to be run
• records results and any retesting to be done
• adds regression testing as necessary
• revised to accommodate all retesting requirements
5. Ensure incidents are being reported accurately and in good time (see Chapter 8)
• IM process
• incidents logged and reported to development
• confirmed defects retested after correction
• regression requirements decided after correction
• test schedule log updated
6. Check regularly on defect resolution with development team and ensure there are no bottlenecks
7. Generate regular test summary reports to identify
a. progress against plan
b. coverage achieved to date
c. incidents reported and resolved
d. outstanding incidents
e. progress against acceptance criteria
f. estimated completion based on performance to date (see Chapter 8)
UAT RELEASE DECISION CHECKLIST
1. Identify status against acceptance criteria (see Chapter 9).
• test coverage
• requirements coverage
• defects outstanding
2. Identify effort/time required to meet acceptance criteria in full
3. Examine alternatives based on residual risk (see Chapter 9)
• delay system release (if timing is not critical)
• define workarounds (avoid problems by changing process)
• revise acceptance criteria (if reduced quality is an option)
• review contingency plans for release (plan to minimize impact of problems, e.g. additional help and technical support services)
4. Emergency -release criteria to enable controlled release (see Chapter 9)
• stability
• usability
• coverage
5. Report status to key stakeholders with alternative proposals for release (see Chapter 9).
6. Prepare UAT completion report with recommendations (see Chapter 9)
POST-UAT ACTIONS CHECKLIST
1. User training design and plan (see Chapter 10)
• built on UAT training
• learn from UAT
• train workarounds
• include information for anticipated FAQs
2. Post-release support (see Chapter 10)
• help desk
• technical support
• FAQs
3. Continue testing (see Chapter 10)
• complete outstanding tests after initial release to reduce risk
• incorporate reliability growth if necessary
• monitor defects corrected and new incidents reported
4. Post-UAT report with details for FAQs etc. (see Chapter 10)
• capture all the actions and decisions
• report designed as an input to ‘lessons learned’