What is the difference between a test strategy and a test plan?

So, What is the Difference between a Plan and Strategy?

This is one of the most often asked questions in software testing classes and testing-related google searches as newcomers in the testing business are surrounded by confusion regarding the terminology.


Testing is a crucial part of any software development project as it ensures the project has no serious flaws or bugs that will later take a lot of resources and time to fix. But before any testing begins there are two documents that need to be drafted and approved: the test strategy and the test plan. 


To be able to understand the difference between them one must first know what these documents mean and what they are useful for.


The Test Strategy


This is a document developed by the Test Manager and is a high-level document. It defines the approach the team will have in achieving the testing objectives. It derives from the Business Requirements document and it sets the standards for the testing processes and activities. As appose to an actual testing model, such as The Waterfall, this is the high level strategy.


The Test strategy includes the following:


Scope and objectivesthe test strategy defines the business objectives and the test scope;


Business issues – the budget of the project, the amount of time allocated for testing, the resources needed and other parameters such as these are defined and set before the testing begins.


Testing approach–the document establishes what type of testing will be carried out (performance, functional, stress, load) and if the testing will be done automatically or only manually.


Test deliverables – will list the documents needed from the testing team and also the method they’ll use for testing record keeping.


Defect tracking approachthe test strategy defines the tools the team will use to keep track of the defects and the data flow between the testing and the development teams.


Training –this is especially important if new tools are introduced in the project. The test strategy also defines the type of training that’s needed and the person or entity in charge of delivering them.

Testing Training

Training


Other relevant information – testing measurements and metrics, change and configuration management, risk management, automation information, if it’s being used.


In smaller projects, the test strategy is just a section of the test plan as it’s not practical to separate the two. According to differencebetween, in large companies with many projects, there is usually one test strategy and a lot of test plans, typically one plan for every major component.


The Test Plan


According to getzephyr.com, The test plan focuses on describing what, how and when to test.  The document is necessary as the test strategy only covers a whole range of modules and it covers general principles on how to approach the testing process. The test plan, on the other hand, focuses more on the specifics, the details of who and how is responsible for testing.


The test plan has the following components:


Test plan IDit’s a unique code that it’s assigned to every plan. 


Test environment – defines the environment that’s needed in order to carry out the testing. It’s the setup of both hardware and software that’s required by the test teams in order to execute test cases.  It allows the team to carry out the tests by being configured with the necessary hardware, software and network.


Features to be tested or not – this section defines in details the software features that will be tested as well as the ones that will not be tested for any reason. They might not be available in that version of the software, for example.


Types of testing - the testing plan defines and describes in details the testing method used for every feature (stress, performance, usability, acceptance, integration, system etc).


Entry/ Exit criteria – basically specify when the testing has to start and when to stop. 


Other relevant information such as status, testing tasks, pass or fail criteria, schedule, responsibilities, test items and a brief introduction.


The test plan is very specific as it tells the team or even the team members what to test and when as well as criteria used for testing.  


A single development project can have multiple Test Plans and a waterfall project can have a test plan for every type of testing, as it is in an Agile project, for example, according to Focus Professional Services.


What are the differences?


When we put together the characteristics of the test strategy and the test plan, we observe some crucial differences.

1.  The Test Plan is formulated from SRS (Software Requirement Specification) and it describes the scope of testing as well as the activities performed, in detail. The test strategy describes the way testing is carried out, according to Art of Testing.

2.  The test plan is very detailed and specific when the test strategy talks about the general approach to testing.


3.  The test plan is subject to change while the test strategy remains untouched.


4.  The test plan is always a standalone document, the test strategy can be, in smaller projects, included in the test plan.


5.  While the test strategy is set at the organization level, the test plan is defined only at the project level.


6.  The test strategy outlines the necessary resources to complete the testing while the test plan assigns the testing tasks to specific roles.


7.  The testing strategy talks about the company vision and the expected results, the testing plan explains what needs to be done in order to achieve those results.

And the differences continue. The development of the testing plan, as well as the testing strategy, is viewed by many people as the most important part of testing and it really pays to have a very good plan that specifies clearly what steps are needed to ensure an error-free product.

Both these documents, however, are just pieces of paper unless they are checked regularly against the reality of the testing process and if the test plan is not updated to the current testing needs.

What is the difference between a test case and a test script?

WHAT IS A TEST CASE?

So, what is the difference between a test case and a test script? If this is something you've been asking yourself lately then you happen to be in just the right place. We'll first start by explaining what a Test Case is.

A test case is basically the specification of execution orders, inputs, expected results and testing procedures that define a series of single tests to be done with the main goal of achieving certain software testing objectives. These testing objectives could include compliance verification of specific requirements or exercising particular program paths.

Test cases rely on methodical testing procedures rather than the haphazard way of doing things. The desired coverage for software testing can be produced by building a series of test cases using this technique.

Test cases that have been formally defined give those same tests the ability to run repeatedly against the software's successive version. What this does is it allows for consistent as well as effective regression testing.

In order for an application's requirements to be fully tested, each requirement will require you to run a minimum of two test cases each. A negative test as well as a positive test.

Expected outputs and known inputs are the characteristics of a formal test case. Test cases based on normally accepted program operations are informally written test cases.

What is a Test Script?

Now for the Test Script description. This is basically a script module consisting of system instructions for testing purposes. The fact that you need to write actual coding language to produce this tool is why people in the IT realm gave this procedure the term "test script". 

It seemed better than just a plain text of a series of instructions. JavaScript, Python, Peri, VB Script and Ruby are all languages that can be used to write test scripts

The development of test scripts can be done in very many ways. A clear example is, when working with programming codebase that's object oriented, developers and programmers can access testing objects using several different strategies. 

In other cases, developers and programmers, once again, can take huge advantage of APIs or Application Programming Interfaces for the creation of high quality test scripts, which will in turn lead to development projects with high functionality levels.

In general, test scripts are basically mediums that give IT professionals the ability to determine predetermined input results and test case isolations. This is comprehensive testing's strategy for the elimination of glitches and bugs as well as the promotion of better software service and product functionality. Test harnesses are the test script repositories and the text execution engines.

What is a Test Scenario?

Any functionality that allows for testing is what a Test Scenario basically is. Most IT professionals also commonly refer to this as Test Condition or Test Possibility as well. In this approach, you as a software tester, will need to figure out real world scenarios by using the end user's point of view, as well as using the cases of the application that is currently being tested.

Two words make up Test Scenario. These are Test and Scenario. Here, "Test" represents verification or validation while "Scenario" is meant to represent the user journey's verification process.

Normally you'll find that large amounts of possible paths as well as large amounts of data combinations in the software will usually restrict you from using exhaustive testing, however, Scenario Testing ensures that the application's end to end functionality that is currently being tested is working as it should and it also makes sure that the business flows involved are also working as expected.

As Scenarios are just basically the User Journeys, in this approach the software tester, when checking the applications performance, just has to walk in the end user's shoes.

The Test Scenario's preparation stage is most often times the most vital part of the whole process. You as the software tester using this approach will need to get help or consult the business user, client, developer or business analyst. After the determination of these test scenarios is when you can begin to write test cases for each scenario. 

The high level concepts of what need to be tested are what make up Test Scenarios.

Conclusion

If you're an IT professional in this day and age, then you might want to consider fully understanding the fundamentals of Test Plan. It has the ability of making some of your work so much easier as well as way more effective.

Always try to make the test plan as concise as possible if you want the plan to be as effective as possible and avoid superfluousness and redundancy, and with that you'll be good to go. Hopefully, you now know a lot more about Test Plan.

Talented Tester Support
 

Click Here to Leave a Comment Below 0 comments

Leave a Reply:

Skip to toolbar