hrhfhf
This document describes the Acceptance Test Plan (ATP) for the Tradecloud platform. The acceptance test verifies that the system works as required and validates that the correct functionality has been delivered. The ATP establishes the acceptance test framework used by the acceptance test team to plan, execute, and document acceptance testing. It describes the scope of the work performed and the approach taken to execute the tests created to validate that the system performs as required. The details of the ATP are developed according to the requirements specifications, and must show traceability back to those specifications.
Planning
A successful acceptance test effort requires planning. The acceptance test team identifies the tasks that need to be accomplished, including milestones. The functional requirements and company documents are the primary drivers for identifying those tasks.
The acceptance test schedule is the timeline of acceptance testing activities and deliverable due dates. For each acceptance testing effort, a test schedule is developed identifying the major test preparation, test execution, and test reporting activities, as well as providing interim checkpoints to measure the progress of acceptance testing. The client monitors the acceptance test effort.
Assigning a test priority provides built in mitigation for schedule risks. Therefore, prior to the test effort, the most critical system features are identified and assigned a priority level. The most critical items are tested first, followed by progressively less critical items. This ensures the critical items are tested when insufficient test time is allocated for acceptance testing. This approach also provides immediate feedback on the critical system features early in the acceptance test so the developers can begin addressing serious defects immediately. Any test cases and system features that are not tested are documented and provided in the Acceptance Test Summary Report.
Acceptance test execution is an iterative process that begins with the initial execution of the planned tests. If no defects are discovered, then the test procedure has “passed.” If defects are discovered, they are documented, discussed, corrected, and retested.
Ideally, acceptance testing continues until all the acceptance tests are successfully executed. However, the acceptance test team recognizes that the system has firm deadlines. Thus, early in acceptance testing, the acceptance test team focuses on critical functionality and new features. If test time expires before completion of the acceptance tests, the acceptance test team provides a list of the untested tests along with a risk analysis regarding the untested functionality.
At the end of the acceptance test, the acceptance test team produces two reports summarizing the results of the acceptance test. The Test Summary Report is a short report summarizing the test activities, and identifies outstanding deficiencies and issues. The acceptance test team delivers this report on a mutually agreed upon timeframe shortly after the end of acceptance test. This report provides the <client> with information to make an informed system software acceptance or rejection decision.
The Acceptance Test Final Report is the detailed record of the acceptance test activities. It records which tests were performed, the pass/fail status of each test, and the discrepancies or issues found. In addition, the Acceptance Test Final Report identifies new tests added to the planned tests. The Acceptance Test Report is delivered as part of the appendix to the Final Acceptance Test on a mutually agreed upon date at the conclusion of acceptance testing.
Goals
The purpose of the Acceptance Test is to formally document that the software application/system satisfies its acceptance criteria. The Acceptance Test enables the program manager, project owner and project sponsor to determine whether to accept the software application/system.
- All test cases should be executed
- All defects in Critical, Major severity should be verified and closed
- Any open defects or suggestions in Medium or Low severity should be discussed for road map yes or no and with or without financial impact to be solved later
Product suggestions & improvements are not part of the acceptance test.
Scope
To be defined per project.
Test scenarios for the Buyer
1. …
Test scenarios for the Supplier
1. Requested date not possible
2. Item number missing
3. Quantities not possible
4. Price not correct
5. Approval process
6. Rejection / cancel process
Risks
Provide a list of the system test risks from the project’s Risk Management Plan and the possible mitigation for those risks. These risks can be included as a separate section in this document, or referenced as part of the Risk Management Plan.]
The following are typical, general overall acceptance test risks:
- Insufficient test time –
Risk: If the amount of time available is too short, the acceptance test team may not have enough time to complete acceptance testing or perform regression testing.
Mitigation: Develop a critical path of tests, prioritized by importance.
- Incomplete requirements –
Risk: May result in insufficient testing of the system.
Mitigation: Use the traceability matrices to track the testing/requirements relationship.
- A test environment that is not the same as the production environment –
Risk: May prevent the detection of some defects and issues.
Mitigation: Note the differences and work to have them as close as possible.
