Periodicamente, sou solicitado para dar formação sobre gestão de projectos, por parte de uma BIG CORPORATION. O exemplo exposto mais abaixo, serve-me como ponto de partida para os meus efémeros formandos, pegarem num caso concreto e partirem para o caminho das pedras:
Software Test Plan Template
--------------------------------------------------------------------------------
1. INTRODUCTION
1.1. Overview
This section provides a brief overview or summary of the product. It could also give background information as to how the product came about or specific information about the users, or anything that may be important to mention.
1.2. Product Scope
This section documents the specific items that are included in the release. If it’s a brand new product, it should provide a functional description of the product. If it’s an update to an existing product, it should itemize all changes included in the release.
This section may also refer to any pertinent documentation that can be used for reference, the Requirements Document, the Design Documentation, etc.
2. OBJECTIVES AND TASKS
This section of the Test Plan defines the objectives of the Test Plan along with the tasks that are included in completing the test plan. Objectives may include
3. RISKS AND ASSUMPTIONS
This section of the Test Plan should identify and prioritize risk areas of the application. This involves the participation of many team players, users, and Information Systems personnel who must evaluate the application and identify the testing focus.
Any assumptions related to the risk assessment should be documented in this section. For instance, one assumption could be that the design of the application is complete and that any changes to the design may impact the test schedule.
4. TEST STRATEGY
This section of the Test Plan describes the test strategy. The Test Strategy should identify the test approach in relation to the defined risks. This section should also identify what type of testing should be performed, whether it be functional testing, stress testing, performance testing, volume testing, etc. It must indicate what features of the application should be tested and when they should be tested.
The test strategy may identify the test cases that will be created for the areas of the application to be tested. It may also indicate what testing tools will be used for the test execution.
The selection of test data may also be discussed in this section.
5. RESOURCE REQUIREMENTS
This section of the Test Plan lists the resources necessary to accomplish the Test Plan. This includes personnel resources along with hardware and software resources.
Personnel resources should include:
Project Management Personnel
Test Personnel
Development Personnel
Database Administrators
System Administrators
Other Support Personnel
Hardware and Software resources should include:
PC’s and workstations
Server
Operating System and software
Database
Application Code
Network Printers
Communication equipment
Test Tools
6. TEST PREPARATION: PROCEDURES AND DOCUMENTATION
This section of the Test Plan identifies the tasks and documentation necessary to prepare for the actual execution of tests. It describes what needs to be accomplished before testing begins.
Included in this section would be:
6.1. Test Case Preparation
This section identifies the test cases to be developed, who should develop the applicable test cases for the appropriate sections of the application, and where they should be stored for easy access.
6.2. Test Environment Set Up
This section identifies who will set up the test environment with the needed software and hardware as defined in the Resource section of the Test Plan
6.3. Database Set Up
This section identifies who will set up the test data bases and any necessary information pertaining to the data bases, i.e. if they should be pre-populated, etc.
6.4. Change Request Procedures
This section documents the procedures for Change Requests. It is very important that changes are properly managed to ensure effective execution of any re-testing efforts.
6.5. Code Control Procedures
This section documents the procedures for the turn over of code to the test environment along with any necessary forms or deliverables which need to be turned over with the code.
6.6. Incident/Defect Tracking Tool and Procedures
This section identifies the Incident Tracking Tool and the procedures for reporting an Incident and for re-testing that incident. These procedures should identify basically what happens when a discrepancy is found during test and should include:
Proper identification and description of an incident
Incident severity assignment
Definition of severity types
Types of incidents (requirements issue, design issue, code issue, test case issue, database issue)
Incident Assignment and status
Who gets assigned what types of incidents
Life Cycle (status) of the incident (assigned to analyst, assigned to developer for fix, assigned to tester to be re-tested, assigned to DBA, etc)
Staging procedure to turn code over for re-test (refer to the Code Control Procedures)
Re-test procedure
Retest incident and status incident to ‘closed’ or ‘failed retest’
Regression test to insure other functions weren’t affected
6.7. Test Entrance Criteria
The Entrance criteria should be specified by the test manager before testing can commence. An example of the Test Entrance criteria for a System Test Plan would be:
All developed code must be unit tested and signed off by the assigned developer
The test environment (hardware, software, databases) must be set up and in place
All test cases must be documented
6.8. The Test Schedule
A test schedule should provide a list of major tasks that are important to the test process, with their scheduled start and end dates.
For example:
TASK START DATE END DATE
Document Requirements
Document Design
Create Test Cases
Conduct walk-through of System Test Plan and Test Cases
Set Up Test Environment
Set Up Data Bases
Create Test Data
Deliver code to Test Environment
Test Execution
Execute Test Cases X through X
Execute Test Cases X through X
Retest incidents and Regression Test
Sign Off on Test
7. Test Execution
This section of the Test Plan describes the steps for Test Execution, along with the procedures, tools and communications used during testing.
Test Execution steps include:
• Ensure the code, the test environment, and the database is in place
• Execute the test cases according to the pre-defined test sequence
Document the actual results
Compare the actual results against the expected results
• Document any discrepancies in the ‘incident tracking tool’ according to the Incident Tracking Procedures
Assign incident to applicable owner (notify, email, etc)
• Publish periodic Report of Incidents
• Define any other Test Deliverables (i.e., Test Status Reports)
• Re-test issues that are turned back for re-test
Regression test any code which may have been affected as a result of the fixes
8. Approval
This section of the Test Plan describes the approval process. It includes:
8.1. Acceptance or Exit Criteria
The Acceptance criteria should indicate what the stipulations should be before the application is released to the next phase.
An example of Exit Criteria for System Test would be:
There should be no outstanding Severity 1 Incidents
All remaining open Severity 2 errors must be reviewed by the Project Team Review Board to determine if they should be fixed
All pre-determined test cases must have been executed at least one time
8.2. Approval Identification
This section should identify the approval process and documentation required for that process (sign-off documentation, etc)
8.3. Test Archival
This section should explicitly define the test data retention process. Information should include:
Naming conventions for test script files and transaction data files
Cross reference detail test plan with test definition information, that provides meaningful traceability to the test data that has been saved
Where the data has been stored and any security provided to ensure its on-going protection
