Difference between Test Plan and Test Strategy

To find out the “Difference between Test Strategy and Test Plan“, first we need to see their individual definition. Here they are:

Test strategy is a high level document which defines the approach for software testing. It is basically derived from the Business Requirement document. Test strategy is developed by project manager or business analyst. It is kind of static document which sets the standards for testing so not updated often.

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.

Now, let’s make a list of points which are included in both respectively.

Test strategy contains:

1. Scope and objective: The objective of the business and how much testing scope is there is defined under test strategy.
2. Business Issues: How much is the budget of the project, how much time is required for testing, how much resources are needed etc. are the part of business issues which needs to be considered before the actual testing starts.
3. Testing approach: What type of testing is needed (performance, load, stress, functional etc.) and whether the testing is only manual or automation or both are some of the crucial points which defines the testing approach.
4. Test deliverables: What are the documents required from the testing team, how they would keep the record of the testing cycles etc. will be included here.
5. Defect tracking approach: Which tool will be used for tracking the defects and how will the testing team communicate with the development team and how the flow would go for defects are decided at this point in test strategy.
6. Training: If there is some complex or new tool is introduced in the business then it is helpful if the team members are given proper training. What type of training and the responsible person to conduct such training is defined here.
7. Automation: If the project or business needs automation testing then the script language, tool used, reporting and code maintained is planned in test strategy.
8. Risks: Nobody can anticipate all the risks beforehand but obvious risks can be avoided and also solution (if risk occur) can be included in the document for future help.

Test plan contains:

1. 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.
2. 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.
3. 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).
4. 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.
5. 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.
6. 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.
7. 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.

Basically, test plan is test strategy and test logistics (tools used, environment set up etc.). Strategy defines what approach should be there for testing and plan has all the details how those approach will be executed in a proper planned way. They both go hand in hand. Test plan will have all the names of the testers who tested a particular script and also it maintains cycle numbers so that if some feature fails in this cycle, previous cycle can be referred to see if that particular feature was passed or failed, in this way it is easy to get the root of the issue and hence becomes easy to resolve it.

As mentioned above. Test strategy should not be modified very often because it sets some standards for test plan and if standards are modified frequently then it becomes difficult to stick to a particular plan and changing plan frequently will affect the quality of the testing. Sometimes when small requirements are changed, we only need to update the test plan but test strategy remains the same.

Feel free to discuss your differences on Test Plan and Test Strategy in comments below. Sharing your own testing experience, tips or testing secrets in comments below will definitely make this article more interesting and helpful!!

⇓ Subscribe Us ⇓

If you are not regular reader of this website then highly recommends you to Sign up for our free email newsletter!! Sign up just providing your email address below: