Professional Documents
Culture Documents
Written by: Organization: Location: Original Publication Date: Current Plan Version: Current Publication Date:
To prepare the plan, fill in the information specified within the Template, as described above, guided by the UAT methodology. Change the footer to reflect the plan being produced, with its version and date. The Test Plan Sample provides an example of a test plan following the template. The text may also be varied as required, as long as the underlying approach is followed. Familiarity with Word 6.0 is assumed. The following are some key tips: Use Edit/Find to locate all occurrences of { and [. If not familiar with using styles, to get a heading of any level, copy an existing one and insert it where the new heading is needed. The number will be updated automatically. Then change the text as needed. Update the Table of Contents at any time by placing the cursor in it and hitting F9. The entire Table of Contents should be updated, not just the page numbers, if you have added or changed headings at Level 1 or 2. These instructions are placed within the Template for convenience of reference. Delete this entire page when finished, and do a final update of the Table of Contents.
Table Of Contents
1. Introduction....................................................................................................................4 2. Strategy..........................................................................................................................8 3. Work Plan....................................................................................................................15 4. Testing Procedures.....................................................................................................18 5. Test Case Design........................................................................................................20 6. Test Case Execution....................................................................................................21 Attachment A: Requirements Hierarchy........................................................................23 Attachment B: Requirements Validation Matrices..................................................................................24 Attachment C: Work Plan..............................................................................................25 Attachment D: Test Case Design..................................................................................26
1. Introduction
This Test Plan describes how and when User Acceptance Testing will be performed to ensure that [version|release m.n of] the {name} System performs according to its business requirements and functional specifications. The business purpose of the {name} System is {brief statement of overall business functionality}. The business owner of this system is {name, title, location, phone}. The objectives of the current {version|release|project} are: {list/describe briefly}.
1.3. Assumptions
Prior to acceptance testing, the tests listed below will have been performed, and the results reviewed by the User Acceptance Testing group. These tests are considered to have been satisfactorily completed, with the exceptions noted below. {To be completed in updating the plan prior to acceptance test execution.} 1. Unit testing by the {name} group at {location}. Exceptions: {None|describe briefly and reference detail}. 2. Integration testing by the {name} group at {location}. Exceptions: {None|describe briefly and reference detail}.
3. System testing by the {name} group at {location}. Exceptions: {None|describe briefly and reference detail}. 4. [Other, if any. Exceptions: {None|describe briefly and reference detail}.] This test plan describes all of the remaining tests to be performed on the {system| release} [except for describe any subsequent tests not covered by this plan and reference the appropriate test plan(s)]. An adequate testing environment at {location}will be available beginning {n} days before the start of acceptance testing for setup and shakedown. {Select one of the following two items.} The software and non-software deliverables will be made available to the UAT group in builds, as detailed in the Build Strategy Section below. The entire system will be made available to the UAT group at one time on or before the above start date. Hence the term build as used in this plan refers only to the top level of the test hierarchy structure. Adequate staff resources with appropriate knowledge and/or training will be available as specified in the work plan during the period required to set up and complete the test. {Insert any other assumptions as appropriate.}
Description
Risks that may impact the ability to install the system on time and/or operate the system successfully: Description Severity Avoidance/Minimization Approach
2. Strategy
This key section of the test plan describes the approach used to assure that the system is thoroughly tested. It details the levels and types of tests to be performed and the requirements to be tested, as well as the coverage and build strategies [and the approach to pilot and parallel testing]. Finally, it presents the validation matrices or equivalent that assure coverage of the requirements at all levels.
Capacity/performance tests: Tests of the systems ability to handle specified volumes, or produce specified response time or throughput. Regression tests: Repeated tests in any of the above categories that verify that problems were fixed, or other changes were made, correctly and without adverse impact on other functions. [Other tests: Describe, if any.]
{Select one of the following two items.} The requirements to be validated by this test plan have been identified and decomposed hierarchically, and are shown {below|in Attachment A}. The requirements to be validated by this test plan have been decomposed hierarchically and are stored in {tool or environment} on {workstation|server identification} as { drive:\directory path\file }. [A hard copy listing is found in Attachment A.] {Hard copy should be attached unless the access to the on-line material is available and familiar to all concerned.}
Requirements Validation Matrices shown in {Section 2.8|Attachment B}. {Name of report} produced by {tool or environment} on {workstation/server identification} from the input file {drive:\directory path\file}. [A hard copy listing is found in Attachment B.] {Hard copy should be attached unless the on-line material is available to all concerned.} {Other approach.}
The sequence of builds reflects the following dependencies and other factors relating to the development and/or testing processes and the functionality to be delivered: {List factors leading to choice of build structure and sequence.}
{Include either or both of the following two items, if applicable.} Builds will be moved to parallel testing {individually|all at one time}. {Detail as required}. Builds will be moved to pilot testing {individually|all at one time}. {Detail as required}. {Reproduce either of the subsections below for each build. Build numbers should be unique through all builds.}
10
2.5.1.
2.5.1.1.
The tests for this build will be divided into the following test runs, each generally representing a single on-line session or batch job unless otherwise described in the text: Run No. Name Description/Objective(s)
2.5.1.3.
Test Files
The following test files must be available to test this build: The names provide a reference to the Test Execution section below. Description Content* Source** Name
{*e.g., empty file, valid records, records processed by specified subsystem or function} {**e.g., from developers, create by specified tool} 2.5.1.4. Test Tools
The following tools will be used in testing this build. Tool Name Tool Type* Purpose/How Used Required?**
{*e.g., Test Management, Capture/Replay or Scripting, Test Data Generator, File Comparison, Interactive Debugging, other categories such as Simulation or Performance Monitoring} {**i.e., use of this tool is required by current standards/methodology}
11
2.5.2.
2.5.2.1.
This build includes the following component(s): {Name: description} Acceptance Criteria
2.5.2.2.
2.5.2.3.
{List approach(es), e.g., inspection, review, user test. If appropriate, list test runs as above.}
12
2.8.1.
The following matrix has been used in determining the build strategy and verifying coverage of high-level requirements by builds. An X under a build number indicates that the build tests the requirement at the left. High-Level Requirement Number Name Build Number
2.8.2.
The following matrices have been used in determining the test run strategy and verifying coverage of intermediate-level requirements by test runs. An X under a test run number indicates that the test run tests the requirement at the left. {Repeat the following as required for each build, including any non-software builds that will be validated by actual testing.} Intermediate-Level Requirement Number Name Build n: Test Run Number
2.8.3.
The following matrices have been used in determining the test case strategy and verifying coverage of detail-level requirements by test cases. An X under a test case number indicates that the test case tests the requirement at the left.
13
{Repeat the following as required for each test run.} Detail-Level Requirement Number Name Build n Test Run m - Test Case Number
14
3. Work Plan
This section details the organization of the user acceptance test team, the breakdown of the work into tasks and milestones and the resources needed to execute the tests.
Start Date*
End Date
N/A
M: First Acceptance Transmittal to User M: Second Acceptance Transmittal to User (if needed)
N/A N/A
15
Start Date*
End Date
3.4.1.
Type
Hardware
Quantity Date Needed Location(s)
Issues: {Describe any potential conflicts or other issues impacting hardware access/capacity/ availability, their impact, and how they will be dealt with, or indicate None.}
16
3.4.2.
Software/USERIDs/Access/Accounts
Date Needed Location(s)
Issues: {Describe any potential conflicts or other issues impacting software availability, their impact, and how they will be dealt with, or indicate None.}
3.4.3.
Type
Networks
Date Needed Location(s)
Issues: {Describe any potential conflicts or other issues impacting network access/capacity/ availability, their impact, and how they will be dealt with, or indicate None.}
17
4. Testing Procedures
This section covers the procedures used to control the acceptance test. They include the areas of library control, problem reporting, change management, test execution control, and user acceptance. {For each of the following, reference may be made to existing documented procedures, giving version and date, and describing any exceptions for this project. Otherwise describe procedures in detail. Suggested text is included below.}
Integration Test
Acceptance Test
Production
reports and change requests will be composed using the Requirements TR form and stored in the Lotus Notes Requirements Problem Report database. The Problem Reporting procedure found in Section 2.07 of the UAT Life Cycle Version 2.0 will be used to document and control problem reports and change requests during normal acceptance test execution. Testers will document all problem reports and change requests using the system TR form. This facility can be accessed directly from the test scripts in Notes.
19
20
6.1.1.
Software Components
The following new or changed (N/C) software components will be tested. {Include all types of components, including JCL, DBMS coding, etc.} Build No.* Component Name N/C Description
6.1.2.
The following existing, new or changed (E/N/C) stored procedures will be used to install or remove software components or to control system execution. New or changed procedures will be tested as part of the acceptance test. Build No.* Procedure Name E/N/C Description
6.1.3.
User Documentation
The following existing, new or changed (E/N/C) user procedures or other documentation will be referenced and applied during test execution. New or changed procedures or other documentation (non-software deliverables) will be tested as part of the acceptance test:
21
E/N/C
Description
{*May be left blank if the same procedures are used in all builds.}
{*May be left blank if the same procedures are used in all builds.}
{*May be left blank if the same components are used in all builds.} {**E.g., flat file, VSAM file, database, database table - specify DBMS name where applicable.} {***Indicate if access by the build is Create, Read, Update or Delete (C/R/U/D) as well as any access by other systems or builds.}
22
23
24
25
26