You are a QA manager and you have been given the responsibility of managing overall quality of the product developing in your company. You are now worried because the product is big and complex. What is the first thing you can think of to help you out?
A test plan!
A test plan is a document that outlines the planning for test process. It contains guidelines for the testing process such as approach, testing tasks, environment needs, resource requirements, schedule and constraints.
Once you know the right tool, you must be thinking about how to write a good test plan. What goes into creating a test plan? What are the test plan steps? No problem! Here, we are going to discuss answers to all your questions related to test plan.
What is a test plan?
A test plan is a document that defines the strategy that will be used to verify that the product or system is developed according to its specifications and requirements.
It describes the scope of testing, testing techniques to be used, resources required for testing and the schedule of intended test activities. The scope helps in identifying test items and the features to be tested. A test plan also contain details of who will perform a given task.
Wikipedia defines test plan as:
A test plan is a document detailing the objectives, target market, internal beta team, and processes for a specific beta test for a software or hardware product. The plan typically contains a detailed understanding of the eventual workflow.
A good test plan covers all the testing phases in Software Development Life Cycle(SDLC).
You create a test plan to verify your design and compliance with the standards. After design, the product development is started so you create a manufacturing or production test plan. If your product has different components and modules, you also need a regression test plan to verify that entire product works together flawlessly. Finally, you hand over the project to client for approval. This phase is controlled by following user acceptance test plan.
The format of test plan document may vary with the type of product and the organizations. For larger and complex projects, you can prepare a master plan with high level details of overall requirements. The master test plan is supported by subsidiary test plans with the required details for testing of each component or module.
Why create a test plan?
You might be probably wondering why is it necessary to invest all this time and effort to create a test plan? How about just jumping off to testing and getting the work started?
Well, hold on! You might need to re-think. Testing is an important process in the SDLC which controls and determines the quality of your deliverables. If you want to deliver a bug free product at its planned timeline, you need a good test plan to make it happen.
Making a test plan offers multiple benefits:
- It is the guide book for the testing process. It directs your testing approach and describes the testing practices to be followed.
- It contains details of the testing scope which prevents team from putting any efforts in testing ‘Out of scope’ functionalities.
- It helps to determine the time and effort required for testing the product.
- It clearly defines roles and responsibilities of every team member so every individual in the testing team knows what is required of him.
- It provides schedule for testing activities. Hence, it provides you a baseline schedule to control and track your team’s testing progress.
- It outlines the resource requirements and equipment needs which are essential to carry out the testing process.
- It can be shared with your client to give them insight about your testing process and gain their confidence.
How to write a good test plan?
At this stage, you are convinced that a test plan drives a successful testing process. Now, you must be thinking ‘How to write a good test plan?’ We can write a good test plan by following the below test plan steps:
1. Analyze the Product
The first step towards creating a test plan is to analyze the product, its features and functionalities to gain a deeper understanding. Further, explore the business requirements and what the client wants to achieve from the end product. Understand the users and use cases to develop the ability of testing the product from user’s point of view.
2. Develop Test Strategy
Once you have analyzed the product, you are ready to develop the test strategy for different test levels. Your test strategy can be composed of several testing techniques. Keeping the use cases and business requirements in mind, you decide which testing techniques will be used.
For example, if you are building a website which has thousands of online users, you will include ‘Load Testing’ in your test plan. Similarly, if you are working on e-commerce website which includes online monetary transactions, you will emphasize on security and penetration testing.
3. Define Scope
A good test plan clearly defines the testing scope and its boundaries. You can use requirements specifications document to identify what is included in the scope and what is excluded. Make a list of ‘Features to be tested’ and ‘Features not to be tested’. This will make your test plan specific and useful. You might also need to specify the list of deliverables as output of your testing process.
The term ‘scope’ applies to functionalities as well as on the testing techniques. You might need to explicitly define if any testing technique, such as security testing, is out of scope for your product. Similarly, if you are performing load testing on an application, you need to specify the limit of maximum and minimum load of users to be tested.
4. Develop a Schedule
With the knowledge of testing strategy and scope in hand, you are able to develop schedule for testing. Divide the work into testing activities and estimate the required effort. You can also estimate the required resources for each task. Now, you can include test schedule in your test plan which helps you to control the progress of testing process.
5. Define Roles and Responsibilities
A good test plan clearly lists down the roles and responsibilities of testing team and team manager. The section of ‘Roles and Responsibilities’ along with ‘schedule’ tells everyone what to do and when to do.
6. Anticipate Risks
Your test plan is incomplete without anticipated risks, mitigation techniques and risk responses. There are several types of risks in software testing such as schedule, budget, expertise, knowledge. You need to list down the risks for your product along with the risk responses and mitigation techniques to lessen their intensity.
What to include in test plan?
Different people may come up with different sections to be included in test plan. But who will decide what is the right format? How about using IEEE Standard test plan template to assure that your test plan meets all the necessary requirements?
Usage of standardized templates will bring more confidence and professionalism to your team. Let’s have a look at the details to know how you can write a test plan according to IEEE 829 standard. Before that, we need to understand what is IEEE 829 standard?
IEEE 829 Standard for Test Plan
IEEE is an international institution that define standards and template documents which are globally recognized. IEEE has defined IEEE 829 standard for system and software documentation. It specifies that format of a set of documents that are required in each stage of the software and system testing.
IEEE has specified eight stages in the documentation process, producing a separate document for each stage.
According to IEEE 829 test plan standard, following sections goes into creating a test plan:
1. Test plan identifier
As the name suggests, ‘Test Plan Identifier’ uniquely identifies the test plan. It identifies the project and may include version information. In some cases, companies might follow a convention for a test plan identifier. Test plan identifier also contains information of the test plan type. There can be the following types of test plans:
- Master Test Plan: A single high level plan for a project or product that combines all other test plans.
- Testing Level Specific Test Plans: A test plan can be created for each level of testing i.e. unit level, integration level, system level and acceptance level.
- Testing Type Specific Test Plans: Plans for major types of testing like Performance Test Plan and Security Test Plan.
Example Test Plan Identifier: ‘Master Test plan for Workshop Module TP_1.0’
Introduction contains the summary of test plan. It sets the objective, scope, goals and objectives of the test plan. It also contains resource and budget constraints. It will also specify any constraints and limitations of the test plan.
3. Test items
Test items list the artifacts that will be tested. It can be one or more module of the project/product along with their version.
4. Features to be tested
In this section, all the features and functionalities to be tested are listed in detail. It shall also contain references to the requirements specifications documents that contain details of features to be tested.
5. Features not to be tested
This section specifies the features and functionalities that are out of the scope for testing. It shall contain reasons of why these features will not be tested.
In this section, approach for testing will be defined. It contains details of how testing will be performed. It contains information of the sources of test data, inputs and outputs, testing techniques and priorities. The approach will define the guidelines for requirements analysis, develop scenarios, derive acceptance criteria, construct and execute test cases.
7. Item pass/fail criteria
This section describes a success criteria for evaluating the test results. It describes the success criteria in detail for each functionality to be tested.
8. Suspension criteria and resumption requirements
It will describe any criteria that may result in suspending the testing activities and subsequently the requirements to resume the testing process.
9. Test deliverables
Test deliverables are the documents that will be delivered by the testing team at the end of testing process. This may include test cases, sample data, test report, issue log.
10. Testing tasks
In this section, testing tasks are defined. It will also describe the dependencies between any tasks, resources required and estimated completion time for tasks. Testing tasks may include creating test scenarios, creating test cases, creating test scripts, executing test cases, reporting bugs, creating issue log.
11. Environmental needs
This section describes the requirements for test environment. It includes hardware, software or any other environmental requirement for testing. The plan should identify what test equipment is already present and what needs to be procured.
In this section of the test plan, roles and responsibilities are assigned to the testing team.
13. Staffing and training needs
This section describes the training needs of the staff for carrying out the planned testing activities successfully.
The schedule is created by assigning dates to testing activities. This schedule shall be in agreement with the development schedule to make a realistic test plan.
15. Risks and contingencies
It is very important to identify the risks, likelihood and impact of risks. Test plan shall also contain mitigation techniques for the identified risks. Contingencies shall also be included in the test plan.
This section contains the signature of approval from stakeholders.
In this article, we discussed details of test plan and what to include in test plan. A Test plan is a document that outlines the strategy of how a given project or product will be tested.
The Test plan is also a guidebook for testing process and is vital to keep testing process on the right track. There can be a difference of opinion over what to include in a test plan so we can follow IEEE 829 standard to curtail the differences.
According to this standard, the essential elements of a test plan include test plan identifier, introduction, test items, features to be tested, features not to be tested, approach, item pass/fail Criteria, suspension criteria and resumption requirements, test deliverables, testing tasks, environmental needs, responsibilities, staffing and training needs, schedule, risks and contingencies, approvals.
Ready to create a test plan for your next project? Don’t forget to add all these clauses into your test plan to make it in accordance with the IEEE 829 standard. Let us know how useful this template is for you in the comments section below.