Demonstrate to all stakeholders that the testing processes to be undertaken will be appropriately managed and controlled. The intended audience is: ♦ <Business Unit representative> ♦ <Other Business Unit representatives etc.> 1.2. Scope The scope of this Acceptance Test Plan is: ♦ <e.g. Describe what is to be tested and cross-reference to the resource register if necessary.> ♦ <e.g. Detail if the Plan is focused on a single system or on multiple products covered.> 1.3. Output Outputs to be produced as a result of Acceptance Testing are: ♦ <Test results – describe in what format> ♦ <Recommendations – this may include the risk strategy to be adopted and the impact/consequences of such a strategy>
Acceptance Test Plan Version <n.n> – <Project Name> Page 3 1.4. Stakeholders Stakeholders and their involvement with the Acceptance Testing process have been listed in Table 1 (below). Reason Requirement <e.g. IMB> <e.g. Responsible for maintenance of hardware.> <e.g. To determine IMB resources needed for supporting actual testing environments.> Table 1. Stakeholders <This table may be attached as an appendix.>
Acceptance Test Plan Version <n.n> – <Project Name> Page 4 2. Testing 2.1. General Approach <Give a broad overview of the testing procedure that is to be undertaken.> The general approach for Acceptance Testing the <System Name> System is as follows: ♦ <e.g. the venues/sites that will be used> ♦ <e.g. how testing will be structured, grouped etc. - hands-on testing> ♦ <e.g. any other business units involved> ♦ <e.g. internal or external resources required> ♦ <e.g. audit assessment)> In addition, include a description of how many times any testing procedure will be executed e.g. Testing will be structured into test cycles. A test cycle is a complete pass through all the required tests. When new versions of the <System Name> System are delivered during testing, the Testing Team will cease the current cycle at an appropriate time and commence a new cycle. Each new cycle will include any retesting for problems corrected. It is expected, due to time constraints with this project, that only two test cycles may be possible.> 2.1.1. Programmer Unit Testing <This section does not need to be included for a small project.> <e.g. Where individual programs and modules are tested: ♦ Programmer Unit Testing will be the responsibility of <System Supplier>, and will be managed by the <System Supplier> Project Manager or a delegated <System Supplier> Test Manager; ♦ Programmer Unit Testing will be undertaken by <System Supplier> developers; ♦ For each type of module a set of standard tests will be established; ♦ For each module a set of test conditions or test cases will be established (over and above the standard tests) - these will include all possible conditions and errors; ♦ Programmer Unit Testing will be done progressively as programs are developed; ♦ Programmer testing will be undertaken in the development environment, located on the development server; ♦ Programmers will test their own programs;
Acceptance Test Plan Version <n.n> – <Project Name> Page 5 ♦
You've reached the end of your free preview.
Want to read all 96 pages?
- Fall '18
- acceptance testing, Acceptance Test Manager