...
| Excerpt |
|---|
The purpose of this document is to outline the User Acceptance Testing (UAT) process for the Implementation of Adonis for any customer both in Office and specifically in the Pilot Ship ([Client Vessel]). |
Introduction
The purpose of this document is to outline the User Acceptance Testing (UAT) process for the Implementation of Adonis for any customer both in Office and specifically in the Pilot Ship ([Client Vessel]).
...
Check that the functionality that is delivered works for relevant business scenarios.
Check that all functionality required for business scenarios has been delivered.
Check that the delivered functionality works to specification.
Check that any process gaps are identified and addressed accordingly, e.g., change process, etc.
Check that any functionality not delivered during UAT will be delivered within the agreed time before go-live. If not, a solution must be in place to address the gap. Such a solution should be evaluated as to acceptability before the sign-off of UAT.
Decide whether the functionalities that have been tested have met the Customer’s overall requirements to roll - out Adonis to the relevant business users.
...
The following are reference documents the Customer can use for assistance with the UAT plan:
Document | Repository Path / URL |
1. Application Readiness Test document |
|
2. Performance Testing document |
|
3. Test case scenarios |
|
4. Systems Investigation Report |
|
5. Change Request document |
|
6. Functional Requirements |
|
7. Requirements Specification (Reports) |
|
8. Design Documents (Interface) |
|
9. Users Guide |
|
10. Operational Manual |
|
Test Items
For each Phase, the customer should outline all modules to be tested or not.
Items to be Tested and Not Tested (see Scope in Phases) | ||
Modules | To be tested | Not to be tested |
1. |
|
|
|
|
|
Features To Be Tested
Features to be Tested (see Scope in Phases) | |
Adonis Modules/Features | Business Scenarios Being Tested |
1. |
|
2. |
|
3. |
|
Features Not To Be Tested
This is necessary to avoid later confusion when stakeholders thought something would be tested but was not.
Features NOT to be Tested |
Adonis Modules/Features |
1. |
2. |
3. |
User Acceptance Test Methodology
...
Rotation Planning
Crew Change
Payroll Module
Report Module for Phase 1
Phase 2:
Adonis Crew Portal
...
After the testing has been completed and the faults are fixed and re-tested, the test results need to be reviewed to make a decision about whether to accept or reject the current configuration and solutions.
| UAT Test Results | |||||
ID | Test Case Description | Module | Pass / Fail | Tested By | Date Tested | |
|
|
|
|
|
| |
|
|
|
|
|
| |
Plan Testing
This section will be planned during the Project together with the Customer. It will state what plans will be created and how they will be reported.
Change Management
Anything out - of - scope will go through the Change Management process to analyze the impact of costs, resources, time, or project duration.
...
The Customer should describe the process and overall standards for evaluating the test results.
Overall Standard for UAT Success Criteria | ||
ID | Adonis Module | Success Criteria |
1 | Rotation Planning | 90% of relevant test scenarios passed |
|
|
|
UAT Defects
Defects will be entered and tracked via spreadsheet by the assigned resource during the UAT process. Each entry will include detailed information about each defect.
...
This section outlines the RISK processes followed during UAT testing. It specifically deals with the process used to agree when to suspend and later resume testing.
Suspension Criteria and Resumption Requirements | |||
SI # | Suspension Criteria | Suspension Type | Resumption Requirements |
1. | If the output is not identical to what is expected for a given input, it will be suspended. | Partial Suspension | Testing will be resumed if the identified issue has been fixed and is ready to be re-tested.
|
2. | From point 1 it’s clear that the expected result is not equal to the actual result. If evaluated as requiring a change request, testing for that script/case/scenario should be stopped. | Partial Suspension | After going through the Change Management process and approval, such a change request should proceed. Once the project team can deliver/deploy the solution, such functionality/feature should be re-tested.
|
3. | If the system prompts show-stopper errors or any catastrophic failure rendering the solution unusable or preventing the tester/s from proceeding with a given test script. No workaround solution can be identified. | Partial Suspension | Testing will be resumed if the identified error/bug has been fixed and is ready to be re-tested. |
4. | If, for any reason, the Customer and/or Adonis decides that there are reasons preventing the UAT from proceeding. | Total Suspension | Subject to the decision of the Steering Committee – proceed. |
5. | The number of open incidents produces a situation where they cumulatively mean testing has no value at a given point in time | Total Suspension | Subject to the decision of the Steering Committee – proceed. |
6. | Suppose there is an absence of resources to proceed with testing. Resources can, in this case, mean either material resources or human resources. | Partial / Total Suspension | Delivery or availability of resources that allow UAT to proceed. |
UAT Activities
All core UAT activities are defined below:
...
A Test Manager or a Business Analyst should be assigned to oversee testing by assigning scripts, providing general support, and serving as the primary UAT contact point throughout the test cycle. The project managers will coordinate with the analyst. The analyst will be expected to filter out any duplicate defects found and escalate high priority issues to the team sensitively.
UAT Team Roles & Responsibilities | ||
Name | Roles | Responsibilities |
1. |
|
|
|
|
|
Schedule
UAT Schedule | ||
Activity | Estimated Completion Date | Initials |
1. Identify UAT Team |
|
|
2. UAT Plan |
|
|
3. UAT Plan Team Review |
|
|
4. UA Test Case Walk Through |
|
|
5. Test Data Acquisition |
|
|
6. UA Test Scripts |
|
|
7. UA Test Script Approval |
|
|
8. Desktop Validation |
|
|
9. UAT Environment Validation |
|
|
10. Test Script Execution |
|
|
11. UAT Sign-Off | ||
|
Risks and Contingencies
List any issues that could go wrong with the testing process.
UAT Risks | |||
Description | Probability (High/Medium/Low) | Impact (High/Medium/Low) | Mitigation |
1. |
|
|
|
2. |
|
|
|
|
|
|
|
Approvals
Document Signatures | |||
Name | Roles | Signature | Date |
1. |
|
|
|
2. |
|
|
|
|
|
|
|