Having confusion about test strategy vs test plan is a very common issue. And sometimes, it’s hard to understand, which one to apply in different situations.
Test Strategy is a high-level document, which contains an overview of how the testing of projects of an organisation has to be done, whereas test plan is the one that contains all the details of, how a particular project will be tested.
Let’s find out in detail what is test strategy and test planning. Both of these documents answer a lot of questions when it comes to software test planning.
Testing strategy starts with recognising that, ‘what to do?’. The scope of testing is determined. This is done to find the areas of the testing. And which functionality should be in focus.
Before starting it is very important to know ‘what are the goals and targets, you want to achieve with the testing?’. Along with that, strategizing ‘how the testing will be done?’.
‘What to do?’ includes identifying the types of testing necessary for proper analysis of the software. In testing strategy, you will try to find out the tasks to be carried out while testing and the tools, that will be required for the testing.
Test strategy identifies whether the use of any framework required. It will identify the metrics to be calculated, the deliverables and reports to be prepared, while testing.
Then comes, ‘How to do the testing?’. While strategizing the testing, identifying the testing requirements and resources is a major task. The document will define the environment requirements.
Figuring out ‘what are the testing activities to complete the task?’, ‘what are the ways to conduct them?’ and ‘which test cases to be considered while testing?’, is done in the testing strategy.
The testing strategy also includes the ways to meet the deliverables, which are to be provided to the stack holders. A major part of the Software Development Life Cycle.
Let’s discuss how software test planning is done and what makes knowing test strategy vs test plan important.
Test plan as mentioned earlier can be regarded as a detailed and a bit more specific version of test strategy, as it contains the minute details of the testing process of a project.
The first question that it answers is ‘who should do the test?’. It is very important to identify the most suitable persons available for systematic testing. The persons are chosen based on skills, roles and responsibilities.
Formation of the team, responsible for conduction of test is done. After this, the team is allocated the testing tasks and distribution of tasks among individuals is done accordingly.
Second, comes to the efforts involved in software test planning. The efforts required in the test activities and tasks are determined.
The business aspects of the software are also dealt with in function point analysis. It is used to recognise, the issues fixed by the software.
Delphi method is also used to find the answers to various questions about the project in an interactive fashion of two or more rounds.
The Work Breakdown Structure helps in organising the tasks to be carried out by the team. It breaks the whole testing process into small definable components.
COCOMO II, which stands for Constructive Cost Model, is a key component of software development planning. It measures the efforts and cost, that will be required to build new software.
Planning is done to make sure, that 100% of test cases are executed during testing. Even analogies play a vital role when, an idea is to be spread among peoples, who share different culture and background.
In this process, the project idea is shown analogous to a common object, like a car, as most people are familiar with them. And it made them easier to explain their idea.
Software sizing helps to find out the amount of source code required, and other deliverables, that will be required to meet the functions need of the software.
Before starting, building any software it is important to test the feasibility of the project. In this, it is analysed,’ whether the software development will be a profitable step for the organisation or not?’. Development cost efficiency of the software is a very important factor when it comes to business issues.
Legal feasibility is also to be considered, during software test planning. It gives a proof, that the concept of the project is viable.
Next step in the test plan is to decide, ‘when to do the testing?’. The testing is recommended to start as early as possible. It will provide more time for the team to fix the loopholes. And it will also reduce the cost of development.
The stopping time of testing is also required to be planned. It is decided based on many factors like,
1. If the percentage test cases cross a certain value.
2. If the test budget is exhausted.
3. If the functionality of the software, meets a specified point.
4. If the bugs are below a certain level.
The deliverables to be provided to stakeholders after testing are test cases, test results, test reports and the changes and reviews done at different stages of testing.
The test plan also involves maintenance planning. Maintenance planning is the process of continuous defect tracking and fixing it. It is required for improving the quality of a product.
Even the ideas for future improvement and modifications are also planned. And how this new software could be able to flourish as a new business. And what are the other fields, where this software can expand its scope?
Difference between test strategy and test plan
Let’s summaries the difference between a test strategy and test plan.
- On one hand, where test plan is derived from the Software Requirement Specification, containing the details about the scope of testing and activities involved. On the other hand, the test strategy describes the way of testing.
- The test plan is designed for the ground level of a project, whereas the test strategy is designed for organization level.
- Test plan describes the whole testing activities as techniques used, schedule and resources required. Test strategy figures out an estimation of the testing requirements.
Now, we hope that the test strategy vs test plan confusion would have ended.