Software Test Plan (STP) Template

Items that are intended to stay in as part of your document are in bold; explanatory comments are in italic text. Plain text is used where you might insert wording about your project.

This document is an annotated outline for a Software Test Plan, adapted from the IEEE Standard for Software Test Documentation (Std 829-1998). Tailor as appropriate. Where you decide to omit a section, you might keep the header, but insert a comment saying why you omit the element.

Agency Name

Project Name
Software Quality Assurance Plan

Version: (n)

Date: (mm/dd/yyyy)

Document History and Distribution

1. Revision History
Revision # Revision Date Description of Change Author

2. Distribution
Recipient Name Recipient Organization Distribution Method

Software Test Plan

TABLE OF CONTENTS
1. INTRODUCTION ....................................................................................................................................................1
2. TEST ITEMS ...........................................................................................................................................................3 3. FEATURES TO BE TESTED ...............................................................................................................................4 4. FEATURES NOT TO BE TESTED ......................................................................................................................4 5. APPROACH ............................................................................................................................................................4 6. PASS / FAIL CRITERIA ........................................................................................................................................6 7. TESTING PROCESS .............................................................................................................................................7 8. ENVIRONMENTAL REQUIREMENTS ...............................................................................................................8 9. CHANGE MANAGEMENT PROCEDURES .......................................................................................................9 10. PLAN APPROVALS ..........................................................................................................................................10

10/16/2012

9:38:40 PM

Software Test Plan

1. INTRODUCTION
(NOTE 1: THE SOFTWARE TEST PLAN GUIDELINES WERE DERIVED AND DEVELOPED FROM IEEE STANDARD FOR SOFTWARE TEST DOCUMENTATION (829-1998)). (Note 2: The ordering of Software Test Plan (STP) elements is not meant to imply that the sections or subsections must be developed or presented in that order. The order of presentation is intended for ease of use, not as a guide to preparing the various elements of the Software Test Plan. If some or all of the content of a section is in another document, then a reference to that material may be listed in place of the corresponding content.) The Introduction section of the Software Test Plan (STP) provides an overview of the project and the product test strategy, a list of testing deliverables, the plan for development and evolution of the STP, reference material, and agency definitions and acronyms used in the STP. The Software Test Plan (STP) is designed to prescribe the scope, approach, resources, and schedule of all testing activities. The plan must identify the items to be tested, the features to be tested, the types of testing to be performed, the personnel responsible for testing, the resources and schedule required to complete testing, and the risks associated with the plan.

1.1 Objectives
(Describe, at a high level, the scope, approach, resources, and schedule of the testing activities. Provide a concise summary of the test plan objectives, the products to be delivered, major work activities, major work products, major milestones, required resources, and master high-level schedules, budget, and effort requirements.)

1.2 Testing Strategy

Testing is the process of analyzing a software item to detect the differences between existing and required conditions and to evaluate the features of the software item. (This may appear as a specific document (such as a Test Specification), or it may be part of the organization's standard test approach. For each level of testing, there should be a test plan and an appropriate set of deliverables. The test strategy should be clearly defined and the Software Test Plan acts as the high-level test plan. Specific testing activities will have their own test plan. Refer to section 5 of this document for a detailed list of specific test plans.) Specific test plan components include:
10/16/2012 9:38:40 PM

Software Test Plan

Purpose for this level of test, Items to be tested, Features to be tested, Features not to be tested, Management and technical approach, Pass / Fail criteria, Individual roles and responsibilities, Milestones, Schedules, and Risk assumptions and constraints.

1.3 Scope
(Specify the plans for producing both scheduled and unscheduled updates to the Software Test Plan (change management). Methods for distribution of updates shall be specified along with version control and configuration management requirements must be defined.) Testing will be performed at several points in the life cycle as the product is constructed. Testing is a very 'dependent' activity. As a result, test planning is a continuing activity performed throughout the system development life cycle. Test plans must be developed for each level of product testing.

1.4 Reference Material

(Provide a complete list of all documents and other sources referenced in the Software Test Plan. Reference to the following documents (when they exist) is required for the high-level test plan: Project authorization, Project plan, Quality assurance plan, Configuration management plan, Organization policies and procedures, and Relevant standards.)

1.5 Definitions and Acronyms

(Specify definitions of all terms and agency acronyms required to properly
10/16/2012 9:38:40 PM

Software Test Plan

interpret the Software Test Plan. Reference may be made to the Glossary of Terms on the IRMC web page.)

2. TEST ITEMS
(Specify the test items included in the plan. Supply references to the following item documentation: Requirements specification, Design specification, Users guide, Operations guide, Installation guide, Features (availability, response time), Defect removal procedures, and Verification and validation plans.)

2.1 Program Modules

(Outline testing to be performed by the developer for each module being built.)

2.2 Job Control Procedures

(Describe testing to be performed on job control language (JCL), production scheduling and control, calls, and job sequencing.)

2.3 User Procedures

(Describe the testing to be performed on all user documentation to ensure that it is correct, complete, and comprehensive.)

2.4 Operator Procedures

(Describe the testing procedures to ensure that the application can be run and supported in a production environment (include Help Desk procedures)).

10/16/2012

9:38:40 PM

Software Test Plan

3. FEATURES TO BE TESTED
(Identify all software features and combinations of software features to be tested. Identify the test design specifications associated with each feature and each combination of features.)

4. FEATURES NOT TO BE TESTED

(Identify all features and specific combinations of features that will not be tested along with the reasons.)

5. APPROACH
1. THE VARIOUS TESTING THAT WILL be performed are as follows: Regression testing Unit testing System testing Component testing Integration testing Interface testing Security testing Performance testing 2. The testing will be performed on the most risky and important part of the software initially and then will move ahead to the less risky parts. 3. There is a must have, should have, could have approach to the priority of new functionality and so the test approach should take this into account? 4. Rapid-test techniques such as exploratory testing to get an early assessment of the stability of the software will be used. 5. Regression tests will be carried out manually. 6. The time for the regression testing should be inside the time frame.

5.1 Component Testing

Testing conducted to verify the implementation of the design for one software element (e.g., unit, module) or a collection of software elements. Sometimes called unit testing. The purpose of component testing is to ensure that the program logic is complete and correct and ensuring that the component works as designed. The different modules to be tested are: Customer

10/16/2012

9:38:40 PM

Software Test Plan

5.2 Integration Testing

(Testing conducted in which software elements, hardware elements, or both are combined and tested until the entire system has been integrated. The purpose of integration testing is to ensure that design objectives are met and ensures that the software, as a complete entity, complies with operational requirements. Integration testing is also called System Testing.)

5.3 Conversion Testing

(Testing to ensure that all data elements and historical data is converted from an old system format to the new system format.)

5.4 Job Stream Testing

(Testing to ensure that the application operates in the production environment.)

5.5 Interface Testing

(Testing done to ensure that the application operates efficiently and effectively outside the application boundary with all interface systems.)

5.6 Security Testing

(Testing done to ensure that the application systems control and auditability features of the application are functional.)

5.7 Recovery Testing

(Testing done to ensure that application restart and backup and recovery facilities operate as designed.)

5.8 Performance Testing

(Testing done to ensure that that the application performs to customer expectations (response time, availability, portability, and scalability)).

5.9 Regression Testing

(Testing done to ensure that that applied changes to the application have not adversely affected previously tested functionality.)
10/16/2012 9:38:40 PM

Software Test Plan

5.10 Acceptance Testing

(Testing conducted to determine whether or not a system satisfies the acceptance criteria and to enable the customer to determine whether or not to accept the system. Acceptance testing ensures that customer requirements' objectives are met and that all components are correctly included in a customer package.)

5.11 Beta Testing

(Testing, done by the customer, using a pre-release version of the product to verify and validate that the system meets business functional requirements. The purpose of beta testing is to detect application faults, failures, and defects.)

6. PASS / FAIL CRITERIA

!"At the Unit test level this could be items such as: !"All test cases completed. !"A specified percentage of cases completed with a percentage containing some number of minor defects. !"Code coverage tool indicates all code covered. !"At the Master test plan level this could be items such as: !"All lower level plans completed. !"A specified number of plans completed without errors and a percentage with minor defects. This could be an individual test case level criterion or a unit level plan or it can be general functional requirements for higher level plans. What is the number and severity of defects located? !"Is it possible to compare this to the total number of defects? This may be impossible, as some defects are never detected. !"A defect is something that may cause a failure, and may be acceptable to leave in the application. !"A failure is the result of a defect as seen by the User, the system crashes, etc.

6.1 Suspension Criteria 6.2 Resumption Criteria

(Specify the conditions that need to be met to resume testing activities after suspension. Specify the test items that must be repeated when testing is resumed.)

6.3 Approval Criteria

(Specify the conditions that need to be met to approve test results. Define the formal testing approval process.)

10/16/2012

9:38:40 PM

Software Test Plan

7. TESTING PROCESS
Identification of the methods and criteria used in performing test activities are mentioned here. In this part definition of the specific methods and procedures for each type of test is done and also definition of the detailed criteria for evaluating test results are mentioned.

7.1 Test Deliverables

What is to be delivered as part of this plan? 1. Test plan document. 2. Test cases. 3. Test design specifications. 4. Tools and their outputs. 4. Simulators. 5. Error logs and execution logs. 6. Problem reports and corrective actions. One thing that is not a test deliverable is the software itself that is listed under test items and is delivered by development.

7.2 Testing Tasks

1. Create Acceptance Test Plan 2. Create System/Integration Test Plan 3. Define Unit Test rules and Procedures 4. Define Turnover procedures for each level 5. Verify prototypes of Screens 6. Verify prototypes of Reports

7.3 Responsibilities
This issue includes who is responsible for all areas of the plan. They are as follows: 1. Setting risks: This will be done together by the project manager and designing team with the help of the customer. 2. Selecting features to be tested and not tested: This will be performed by the system design team with the help of the testing teams 3. Setting overall strategy for this level of plan.: This will be performed by the project manager with the design team. 4. Ensuring all required elements are in place for testing: This is performed by the coding team 5. Who provides the required training : This is decided by the human resource head 6. Who makes the critical go/no go decisions for items not covered in the test plans : This is done by the project manager.

7.4 Resources
(Identify the resources allocated for the performance of testing tasks. Identify the organizational elements or individuals responsible for performing testing activities. Assign specific responsibilities. Specify resources by category. If automated tools are to be used in testing, specify the source of the tools,
10/16/2012 9:38:40 PM

Software Test Plan

availability, and the usage requirements.)

7.5 Schedule
Time has been allocated within the project plan for the following testing activities. The specific dates and times for each activity are defined in the project plan time line. The persons required for each process are detailed in the project time line and plan as well. Coordination of the personnel required for each task, test team, development team, management and customer will be handled by the project manager in conjunction with the development and test team leaders. A. Review of Requirements document by test team personnel (with other team members) and initial creation of Inventory classes, sub-classes and objectives. B. Development of Master test plan by test manager and test with time allocated for at least two reviews of the plan. C. Review of the System design document by test team personnel. This will provide the team with a clearer understanding of the application structure and will further define the Inventory classes, sub-classes and objectives. D. Development of System/Integration and Acceptance test plans by test manager and other essential personnel with time allocated for at least two reviews of the plans. E. Review of the Detail design document(s) by test team personnel as required. This will provide the team with a clearer understanding of the individual program structure and will further define the Inventory classes, sub-classes and objectives. F. Unit test time within the development process. G. Time allocated for both System/Integration and Acceptance test processes.

8. ENVIRONMENTAL REQUIREMENTS
Both the necessary and desired properties of the test environment including the physical characteristics, communications, mode of usage, and testing supplies are the environmental requirements. Also the levels of security required to perform test activities.

8.1 Hardware
The different hardware needed are : 1. Any Windows operating system

8.2 Software
(Identify the software requirements needed to complete testing activities.)

8.3 Tools
The different tools used are:

1. Name: SQA TestFoundation for PeopleSoft applications Company: Rational

10/16/2012 9:38:40 PM

Software Test Plan

Description: PeopleSoft offers customizable packages for business use, including accounting, materials management, distribution, manufacturing, and human resources. Rational has taken much of SQA Suite and integrated it with PeopleSoft packages, including some new customized features 2. Name: Visual Test Description: Test cases and suites described as program (in special TestBasic language) rather than scripts. Develop test programs, manage suites of tests. May write tests by hand or Scenario Recorder can record session and make into a test (capture & playback). Tests created by the Scenario Recorder can be edited. Can write failure tests to catch exceptions. System testing only, not unit testing.
Testing Levels The testing for the Reassigned Sales project will consist of Unit, System/Integration (combined) and Acceptance test levels. It is hoped that there will be at least one full time independent test person for system/integration testing. However, with the budget constraints and time line established; most testing will be done by the test manager with the development teams participation. UNIT Testing will be done by the developer and will be approved by the development team leader. Proof of unit testing (test case list, sample output, data printouts, defect information) must be provided by the programmer to the team leader before unit testing will be accepted and passed on to the test person. All unit test information will also be provided to the test person. SYSTEM/INTEGRATION Testing will be performed by the test manager and development team leader with assistance from the individual developers as required. No specific test tools are available for this project. Programs will enter into System/Integration test after all critical defects have been corrected. A program may have up to two Major defects as long as they do not impede testing of the program (I.E. there is a work around for the error). ACCEPTANCE Testing will be performed by the actual end users with the assistance of the test manager and development team leader. The acceptance test will be done in parallel with the existing manual ZIP/FAX process for a period of one month after completion of the System/Integration test process. Programs will enter into Acceptance test after all critical and major defects have been corrected. A program may have one major defect as long as it does not impede testing of the program (I.E. there is a work around for the error). Prior to final completion of acceptance testing all open critical and major defects MUST be corrected and verified by the Customer test representative. A limited number of distributors will participate in the initial acceptance test process. Once acceptance test is complete, distributors will be added as their ability to generate the required EDI data is verified and checked against their FAX/ZIP data. As such, some distributors will be in actual production and some in parallel testing at the same time. This will require careful coordination

8.4 Publications
The different IEEE documents can be used for reference during testing

8.5 Risks and Assumptions

The different types of risks can be: 1. Lack of personnel resources when testing is to begin. 2. Lack of availability of required hardware, software, data or tools.
10/16/2012 9:38:40 PM

Software Test Plan

3. Late delivery of the software, hardware or tools. 4. Delays in training on the application and/or tools. 5. Changes to the original requirements or designs. The solutions for all these risks are as follows: 1. Requirements definition will be complete by January 1, 19XX, and, if the requirements change after that date, the following actions will be taken. 2. The test schedule and development schedule will move out an appropriate number of days. This rarely occurs, as most projects tend to have fixed delivery dates. 3. The number of test performed will be reduced. 4. The number of acceptable defects will be increased. 5. These two items could lower the overall quality of the delivered product. 6. Resources will be added to the test team. 7. The test team will work overtime. 8. The scope of the plan may be changed. 9. There may be some optimization of resources. This should be avoided, if possible,

9. CHANGE MANAGEMENT PROCEDURES

If any changes are made in the testing plan they need to be checked with the project head (manager) and take his approval for the change.

10. PLAN APPROVALS

APPROVALS by:
Project Sponsor Development Management EDI Project Manager - Peggy Project Test Manager Development Team Manager

10/16/2012

9:38:40 PM

10