The testing domain has its own scope of terms. Sometimes you can get confused even if you are working in the QA sphere for more than one year. What is the difference between test case and test script? Are test plan & test strategy synonyms? When is it better to use a checklist? Zebrunner’s team finds it out in this article.
Test plan vs. Testing strategy
A test plan is a document that describes the entire testing process. This document is the responsibility of the QA team. It includes a project description, goal, strategies, schedule, and criteria for launching and finishing testing. The test plan contains the hardware you need for testing, environment, skills requirements for QA team members, risk evaluation, and options for solving them in your test plan. In the test plan, you outline testing objects, tasks & testers that are responsible for them. Also, the test plan defines the level of independence for every QA team member.
A test strategy is not synonymous with a test plan. This is a high-level document that describes how to do testing at the level of an organization. This document is the responsibility of a project manager. It outlines what testing approach to use, and which modules to verify on a priority basis. As a member of a QA team you can’t change a testing strategy whereas you can step back from the plan.
Test case vs Test script
A test case refers to manual testing. This is a clearly defined micro-level of software testing. It focuses on what and how to test. A test scenario is a base for test cases. One scenario is a source for lots of test cases. You can’t do without test cases if you need to test thoroughly your application. Simply put, test cases are a sequence of actions that you need to check.
Test cases are written as detailed as possible to provide clarity for all team members. This way the QA engineer verifies if the application works as expected. Although test cases are performed manually, you can streamline and speed up your testing workflow. Create test cases through Zebrunner test case management to improve & simplify the process. The intuitive interface provides the opportunity to start working with a tool immediately. You also can track the results, and import your test cases from other test management tools as well as test automation results from reporting tools.
In plain English, a test script is an automated test case. This is a pretty short-size code that automatically checks the application module. Test scripts could be written in different programming languages.
Test scenario
The QA engineer creates a classification of verifiable high-level requirements. They are divided into categories depending on functionality. Simply put, a test scenario is a high-level document describing user cases in the app.
A test scenario is a sequence of customer steps in the application. The scenario describes any way of integration that can be tested. In creating a test scenario, the QA engineer puts himself in the user’s shoes. He includes in the scenario situations that may arise in software. One test scenario can contain lots of test cases.
Test suite
A test suite unites several test cases that are logically grouped. Test cases in a test suite refer to the same testing module, and functionality, have the same priority, or relate to the same testing type.
Every QA team decides how to organize a testing structure. So you can have one huge suite with hundreds of test cases if it’s convenient for your team. You also can divide your test suites into sub-suites. This way, you compose the test suites into many semi-independent parts. Suppose, you are developing a fitness application. Here, you provide several plans for users. Thus, your suite & sub-suite & test cases seem like that:
Suite: Prices
Sub suite #1: Plans
Test case #1_1: Verify that the user can see the Plan title
Test case #1_2: Verify that the user can see the Plan description
Test case #1_3: Verify that the user can see the Change plan bottom
Test case #1_4: Verify that the user can see the period of subscription (monthly/annual)
Test case #1_5: Verify that the user can see the cost of payment for subscription renewal
Etc.
Sub suite #2: Payment methods
Test case #2_1: Verify that the user can see Add bottom
Test case #2_2: Verify that the user can add a card for the payment method
Test case #2_3: Verify that the user can add PayPal for the payment method
Etc.
Test run
A test run consists of test cases/test scripts/ test suites combinations for a succeeding joint execution. It could be subsequent or parallel execution depending on an automation tool’s functionality & capacity & testing goals. You can launch your test run having test cases (scripts) or test suits. However, it doesn’t mean you must execute all the test scripts you have created. You choose the most appropriate ones based on specific functionality or related to a bug that recently was fixed to check if everything works properly.
Checklist
A checklist is one more testing term you can face often. It means a short designation for a sequence of steps in your application that you have to check. QA teams usually use checklists when they are working under tight deadlines. A checklist describes in a very short format what we want to check. In creating a checklist we don’t describe steps and actions. Suppose, we want to check if statistics data are represented in our fitness application. So, the point in our checklist will seem this way:
Verify if the user sees the statistics.
With a checklist, we don’t describe the steps, what to push, and what exactly to do. We just outline a direction.