Our popular software testing questions and answers series is back again! Just to remind – in this series we answer questions asked by the readers. You can check some earlier posts in this series here and here. Got a question? Submit it in the comment section below or use the contact form.
In today’s article in this series, we are going to answer (with examples) some most commonly asked (and confusing) questions about the difference between test plan, test strategy, test case, test script, test scenario and test condition.
These questions are asked by “sasi C“.
“We almost have an overload of technical terms when working in an IT environment. There are processes, documents, tasks and everything else that is addressed by its own technical name. Now, how are we to remember, understand and use them in the right context every single time? “
This is the question that is most often asked in our software testing class and I always tell our participants that with an experience we hardly notice these words and that they become a part of our vocabulary.
But often, confusion surrounds these and in this article today I am trying to define few commonly used terms.
What You Will Learn:
The test plan is a term and a deliverable. The test plan is a document that lists all the activities in a QA project, schedules them, defines the scope of the project, roles & responsibilities, risks, entry & exit criteria, test objective and anything else that you can think of. The test plan is as I like to call a ‘super document’ that lists everything there is to know and need. Please check this link for more information and a sample.
This is also a deliverable and also a document at that. Test strategy outlines the testing approach and everything else that surrounds it. It is different from the test plan, in the sense that a Test strategy is only a subset of the test plan. It is a hardcore test document that is to an extent generic and static. There is also an argument about at what levels test strategy or plan is used- but I really do not see any discerning difference.
Example: Test plan gives the information of who is going to test at what time. For example, Module 1 is going to be tested by “X tester”. If tester Y replaces X for some reason, the test plan has to be updated.
On the contrary, a test strategy is going to have details like – “Individual modules are to be tested by test team members. “ In this case, it does not matter who is testing it- so it’s generic and the change in the team member does not have to be updated, keeping it static.
In my opinion, these two terms can be used interchangeably. Yes, I am saying there is no difference. The test case is a sequence of steps that help us perform a certain test on the application. The test script is the same thing.
Now, there is one school of thought that test case is a term used in the manual testing environment and test script is used in an automation environment. This is partly true, because of the comfort level of the testers in the respective fields and also on how the tools refer to the tests (some call test scripts and some call them to test cases). So in effect, test script and test case both are steps to be performed on an application to validate its functionality whether manually or through automation.
This is a one line pointer that testers create as an initial, transitional step into the test design phase. This is mostly a one-line definition of “What” we are going to test with respect to a certain feature. Usually, test scenarios are an input for the creation of test cases. In agile projects, Test scenarios are the only test design outputs and no test cases are written following these. A test scenario might result in multiple tests.
Examples test scenarios:
1. Validate if a new country can be added by the Admin
2. Validate if an existing country can be deleted by the admin
3. Validate if an existing country can be updated
Test conditions, on the other hand, are more specific. It can be roughly defined as the aim/goal of a certain test.
Example test condition:
In the above example, if we were to test the scenario 1, we can test the following conditions:
1. Enter the country name as “India”(valid )and check for the addition of the country
2. Enter a blank and check if the country gets added.
In each case, the specific data is described and the goal of the test is much more precise.
Further reading => 180+ sample test scenarios for testing web and desktop application.
The test procedure is a combination of test cases based on a certain logical reason, like executing an end-to-end situation or something to that effect. The order in which the test cases are to be run is fixed.
For example, if I was to test the sending of an email from Gmail.com, the order of test cases that I would combine to form a test procedure would be:
1. The test to check the login
2. The test to compose email
3. The test to attach one/more attachments
4. Formatting the email in the required way by using various options
5. Adding contacts or email addresses to the To, BCC, CC fields
6. Sending email and making sure it is showing in the “Sent Mail” section
All the test cases above are grouped to achieve a certain target at the end of them. Also, test procedures have a few test cases combined at any point in time.
The test suite, on the other hand, is the list of all the test cases that have to be executed as a part of a test cycle or a regression phase etc. There is no logical grouping based on functionality. The order in which the constituent test cases get executed may or may not be important.
Example of the test suite: If an application’s current version is 2.0. The previous version 1.0 might have had 1000 test cases to test it entirely. For version 2 there are 500 test cases to just test the new functionality that is added in the new version. So, the current test suite would be 1000+500 test cases that include both regression and the new functionality. The suite is a combination too, but we are not trying to achieve a target function.
Test suites can contain 100s or even 1000s of test cases.
This brings us to the end of this definition based segment.
Usually, articles like these are excellent starting points for deeper discussions. So, please contribute your thoughts, agreements, disagreements and anything else, in the comments below. We look forward to your feedback.
We also welcome your questions about software testing in general or anything related to your testing career. We will address these in more details in our upcoming posts in the same series.
Thanks, Swati S. for helping us to answer these questions.