User Acceptance Testing

Overview

User Acceptance Testing (UAT), which is performed on most UIT projects, sometimes called beta testing or end-user testing, is a phase of software development in which the software is tested in the "real world" by the intended audience or business representative. This type of testing is not intended to be menu-driven, but rather to be performed by business users to verify that the application will meet the needs of the end-user, with scenarios and data representative of actual usage in the field.

Details

• The Business Analyst should begin preparing a UAT Test Plan, with adequate time before the SIT phase is scheduled to end (SIT exit), to complete the plan, as well as allow for management review, updates, and approvals. This is usually a task in the overall project plan. Just like the SIT Test Plan, the UAT Test Plan has the following sections:
  1. Introduction
  2. Testing Scope
  3. Testing Approach
  4. Testing Deliverables
  5. High-Level Schedule
  6. Error Management & Reporting
  7. Environmental Requirements
  8. Roles & Responsibilities
  9. Risks & Assumptions
  10. UAT Exit Criteria

  Approvals of the UAT Plan should be obtained from the Project Manager, Project Sponsors, and the Business Owner or designee and recorded before proceeding with UAT testing.

• Test cases should be prepared by the Business Analyst, again allowing adequate time for review and approval by the Business Owner, and again ensuring that they are complete, approved, and uploaded to Zephyr before development exit. QA can assist the business with Zephyr and will usually agree to help with test results maintenance in Zephyr via spreadsheet updates from the Business Analyst. And again, this should be a task in the project plan.
• Business users have the option of re-running any or all SIT tests. Testing should be drive by business procedures, not by functionality. It should include end-to-end test cases and employ real-life data. The goal of UAT is to formally assess if the integrated solution satisfies the release acceptance criteria (see below).
• The Business Analyst should provide weekly updates on their page in the project Confluence (or via Box, Shared drives, etc.) that include: (1) completed test cases/scope from the reporting week; (2) overall test case execution progress and pass/fail percentages; (3) planned test cases/scope for the coming week; (4) any issues, concerns, or blockers. A high-level synopsis of UAT status should be included in the Executive Summary Report during the weeks that the project is in the UAT phase.
• As outlined in Business Requirements, for traceability, best practice is to ensure the business links all bugs logged in JIRA to both the corresponding Zephyr test case and the applicable business requirement JIRA issue. This practice can help mitigate disagreement among project team members about what is a bug and what is a change request.
• Be sure to follow the change control process (for more information, see Scope Management) closely during UAT. For many testers, this may be the first time they've seen or used the new application/system and they may have their own strong design opinions. The more changes that are requested and accepted during UAT, the more likely it is that regression bugs will crop up. Best practice is to always allow at least 1 - 2 weeks of regression testing at the end of UAT testing, before which time all baseline test cases should have been executed.
• The UAT release acceptance criteria, found in the UAT Exit Criteria Checklist template must be met (and approved by both the business and IT project sponsors) for the project to progress to the next stage of the Software Development Life Cycle, Implementation and Change Management.
• While exceptions for open P1 - P3 bugs are not permitted for UAT Exit, if the Project Sponsors agree, lower priority change requests and enhancements may be listed as exceptions on the UAT Exit Criteria document/page.
• For an example of UAT Exit Criteria from a previous project, see R12.