Introduction

User Acceptance Testing (UAT) for SELV is intended as an opportunity for HSG to ensure the system (including both the website and reporting) is ready to be used by VillageReach and PAV staff. Prior to UAT, ISG has conducted functional testing of the individual components of SELV, as well as basic end-to-end tests from data entry through reporting. UAT moves beyond basic functional validation to focus on actual user behavior in the field, ensuring that the overall system meets user needs and works as intended.

Roles & Responsibilities

HSG & ISG are jointly responsible for UAT testing, however ultimately HSG is responsible for approving the results of UAT and deciding to roll-out to production. Roles & responsibilities are as follows:

_{RACI Definitions:}

_{Responsible: Those who do the work to achieve the task.There is at least one role with a participation type of responsible, although others can be delegated to assist in the work required (see also RASCI below for separately identifying those who participate in a supporting role).}

_{Accountable: (also approver or final approving authority)The one ultimately answerable for the correct and thorough completion of the deliverable or task, and the one who delegates the work to those responsible.[7] In other words, an accountable must sign off (approve) on work that responsible provides. There must be only one accountable specified for each task or deliverable.}

_{Consulted: (sometimes counsel)Those whose opinions are sought, typically subject matter experts; and with whom there is two-way communication.}

_{Informed: Those who are kept up-to-date on progress, often only on completion of the task or deliverable; and with whom there is just one-way communication.} 

Location

All UAT testing will be done in the VillageReach Mozambique office. If a test is also executed in Seattle that is fine, but it should not be considered "passed" until it has been verified locally.

UAT Testing Approach

Testing can take many forms. One approach is to write specific test cases (scripted tests) in advance of test sessions. Another alternative is exploratory testing, where general areas of testing are defined in advance but actual test execution is left up to the tester. Exploratory testing is more fluid and varied, exercising less predictable paths through the system. The advantage of this approach is that different scenarios are tried, which is more likely to result in identifying bugs. Because SELV has already been tested using a scripted testing approach (by ThoughtWorks), the UAT testing will primarily be exploratory:

• Scripted testing will be used for a basic set of SELV "smoke tests" that can be executed repeatedly whenever there is a new build (see attachment) SELV Smoke Test Tracking Sheet.xlsx
• Exploratory testing against the test strategies defined in the table below will be used for the majority of system testing

UAT Testing Strategy

Validations fall into four major categories. The testing strategy for each category is listed below.

Test Strategy Details

Some test strategies, particularly those where we aim to mimic real-world field conditions, or those that test specific data and reporting scenarios, require further definition before UAT. These are outlined below:

1B - SELV Website for Field Coordinators Real World Scenarios

<need input from Timoteo>

1D - Facility Special Cases

• Visited / Reporting
• Visited / Not Reporting
• Not Visited / Reporting
• Not Visited / Not Reporting 
• Not Visited / Not in Program 
• Not Visited / No Fuel or Per Diem

2A - Administrator System Configuration

• Remove Pull Roles from Admin Accounts
• Add Wendy and Vidya as Users

2C - Administrator Real World Scenarios

<need input from Timoteo>

4A - Report Special Cases

<need to complete this table>