Test plan is derived from SRS (Software Requirement Specification) which is prepared by test lead or manager. The main goal of test plan is to include all the details related to testing such as what to test, when to test, how to test and who will be the tester. Test plan is often not updated but if there is some new feature or change is introduced then it has to be updated accordingly.
In the Test Plan, test focus and project scope are defined. It deals with test coverage, scheduling, features to be tested, features not to be tested, estimation and resource management.
Test plan contains:
- Test plan ID: This is a unique ID which defines the test plan. It can be a number or name or mix of both, as per the convenience.
- Test environment: This section defines what kind of environment is needed for the testing to carry out. For e.g. in device testing, usually a virtual set up is made to test emergency calling.
- Features to be tested/Not tested: This will have all the details about the features which tester needs to test and what are the feature which are not tested (may be because it is not yet implemented or not tested for that particular release).
- Entry/Exit criteria: These are the terms which define when to start or stop the testing. Standards will be defined under test strategy and followed by testers in test plan.
- Status: Whether a test case is passed or failed or not tested, all these test results are included in test plan with a proper reason.
- Types of testing: The types of testing required such as regression, functional, non-functional, stress etc. are defined and then executed by the respective tester.
- Brief Intro: Brief introduction is also included sometimes so that if any new member joins the team, he should get an idea how things work.
Sample Test Plan Template
1. INTRODUCTION
1.1 OBJECTIVES
1.2 TEAM MEMBERS
2 SCOPE
3 ASSUMPTIONS / RISKS
3.1 ASSUMPTIONS
3.2 RISKS
4 TEST APPROACH
4.1 TEST AUTOMATION
5 TEST ENVIRONMENT
6 MILESTONES / DELIVERABLES
6.1 TEST SCHEDULE
6.2 DELIVERABLES
Introduction
The Test Plan has been created to communicate the test approach to team members. It includes the objectives, scope, schedule, risks and approach. This document will clearly identify what the test deliverables will be and what is deemed in and out of scope.
Objectives
Test Case Tamer is a web-based Test Management tool used to create and store tests as well as the results of running those tests. This tool is a new product written with Ruby on Rails using a ‘mysql’ database. The test team is responsible for testing the product and ensuring it meets their needs. The test team is both the customer and the tester in this project.
Phase 1 of the project will deliver TCT (Test Case Tamer) with functionality to create and store manual tests. This will allow the test team to start transferring tests over to the new system. Must have functionality is considered more important than the delivery date in this project.
Team Members
| Resource Name | Role |
Scope
The initial phase will include all ‘must have’ requirements. These and any other requirements that get included must all be tested. At the end of Phase 1, a tester must be able to:
- Create a manual test with as many steps as necessary
- Save it
- Retrieve it and have the ability to view it when running the test
- Enter results and appropriate comments
View results
As the team works with the product they will define the needs for the second phase. Load testing will not be considered part of this project since the user base is known and not an issue.
Rewriting, moving or porting existing test cases from the existing Word documents is not considered part of this project.
Assumptions / Risks
Assumptions
This section lists assumptions that are made specific to this project.
1. Delivery of the product is in format that the test team can check it into CVS.
Risks
The following risks have been identified and the appropriate action identified to mitigate their impact on the project. The impact (or severity) of the risk is based on how the project would be affected if the risk was triggered. The trigger is what milestone or event would cause the risk to become an issue to be dealt with.
| # | Risk | Impact | Trigger | Mitigation Plan |
| 1 | Scope Creep – as testers become more familiar with the tool, they will want more functionality | High | Delays in implementation date | Each iteration, functionality will be closely monitored. Priorities will be set and discussed by stakeholders. Since the driver is functionality and not time, it may be necessary to push the date out. |
| 2 | Changes to the functionality may negate the tests already written and we may loose test cases already written | High – to schedule and quality | Loss of all test cases | Export data prior to any upgrade, massage as necessary and re-import after upgrade. |
| 3 | Weekly delivery is not possible because the developer works off site | Medium | Product did not get delivered on schedule | |
| 4 |
Test Approach
The project is using an agile approach, with weekly iterations. At the end of each week the requirements identified for that iteration will be delivered to the team and will be tested.
Exploratory testing will play a large part of the testing as the team has never used this type of tool and will be learning as they go. Tests for planned functionality will be created and added to TCT as we get iterations of the product.
Test Automation
Automated unit tests are part of the development process, but no automated functional tests are planned at this time.
Test Environment
A new server is required for the web server, the application and the database.
Milestones / Deliverables
Test Schedule
The initial test schedule follows……….
| Task Name | Start | Finish | Effort | Comments |
| Test Planning | ||||
| Review Requirements documents | 2 d | |||
| Create initial test estimates | 1 d | |||
| Staff and train new test resources | ||||
| First deploy to QA test environment | ||||
| Functional testing – Iteration 1 | ||||
| Iteration 2 deploy to QA test environment | ||||
| Functional testing – Iteration 2 | ||||
| System testing | ||||
| Regression testing | ||||
| UAT | ||||
| Resolution of final defects and final build testing | ||||
| Deploy to Staging environment | ||||
| Performance testing | ||||
| Release to Production |
Deliverables
| Deliverable | For | Date / Milestone |
| Test Plan | Project Manager; QA Director; Test Team | |
| Traceability Matrix | Project Manager; QA Director | |
| Test Results | Project Manager | |
| Test Status report | QA Manager, QA Director | |
| Metrics | All team members | |
