{"id":2783,"date":"2018-06-21T16:24:17","date_gmt":"2018-06-21T14:24:17","guid":{"rendered":"https:\/\/wwwtest.tradecloud1.com\/?page_id=2783"},"modified":"2018-07-09T10:01:21","modified_gmt":"2018-07-09T08:01:21","slug":"2783-2","status":"publish","type":"page","link":"https:\/\/tradecloud.hdnk.nl\/en\/2783-2\/","title":{"rendered":"Planning the acceptance test"},"content":{"rendered":"

Introduction<\/h1>\n

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.\u00a0 The ATP establishes the acceptance test framework used by the acceptance test team to plan, execute, and document acceptance testing.\u00a0 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.<\/p>\n

Planning<\/h2>\n

A successful acceptance test effort requires planning.\u00a0 The acceptance test team identifies the tasks that need to be accomplished, including milestones.\u00a0 The functional requirements and company documents are the primary drivers for identifying those tasks.<\/p>\n

The acceptance test schedule is the timeline of acceptance testing activities and deliverable due dates.\u00a0 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.\u00a0 The client monitors the acceptance test effort.<\/p>\n

Assigning a test priority provides built in mitigation for schedule risks.\u00a0 Therefore, prior to the test effort, the most critical system features are identified and assigned a priority level.\u00a0 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.\u00a0 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.<\/p>\n

Acceptance test execution is an iterative process that begins with the initial execution of the planned tests.\u00a0 If no defects are discovered, then the test procedure has \u201cpassed.\u201d If defects are discovered, they are documented, discussed, corrected, and retested.<\/p>\n

Ideally, acceptance testing continues until all the acceptance tests are successfully executed.\u00a0 However, the acceptance test team recognizes that the system has firm deadlines.\u00a0 Thus, early in acceptance testing, the acceptance test team focuses on critical functionality and new features.\u00a0 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.<\/p>\n

At the end of the acceptance test, the acceptance test team produces two reports summarizing the results of the acceptance test.\u00a0 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.\u00a0 This report provides the with information to make an informed system software acceptance or rejection decision.<\/p>\n

The Acceptance Test Final Report is the detailed record of the acceptance test activities.\u00a0 It records which tests were performed, the pass\/fail status of each test, and the discrepancies or issues found.\u00a0 In addition, the Acceptance Test Final Report identifies new tests added to the planned tests.\u00a0 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.<\/p>\n

Goals<\/h2>\n

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.<\/p>\n