Thursday April 12, 2018
Software checking is a lot more complicated process than it seems alike. When it comes to software quality assurance, there are a lot many terminologies you have to deal. Like, test case, test plan, and test strategy. Let’s see what the terms means.
So what exactly is Test Case, Test Plan, and Test Strategy ?
A test case is a series of conditions against which the software is checked to see if it satisfies all requirements and works as desired.
The test lead or manager creates a test plan. Its primary goal is to contain all necessary information about required while testing, which includes what to test, when and how to test, who will test the software. The test plan remains the same throughout but is changed when there is a modification in the software or something new is added.
On the other hand, a test strategy is a complicated document that informs the test how to approach the software while testing it. It is created by a business analyst or a project manager. The test strategy document is more of a standard record and isn’t changed quite often.
Now that the meanings are clear, let’s move onto the differences between differences between test case, test plan, and test strategy:
1. What it contains
It is a sequence of steps that help the testers to test the software and changes from software to software. It includes environment, condition, expected and actual results, and whether the software failed the test or not. Mostly, enterprise test management software is used to manage the case and the process.
A test plan contains a lot of things including features to be tested, techniques, Test plan id, testing tasks, pass or fail criteria, responsibilities, test deliverables, and schedule of the best.
It consists of documentation formats, objectives and scope, test processes, client communication strategy, and team reporting structure.
2. Who conducts it?
It is usually the software developer that writes the test case.
It is conducted by a testing manager or someone who describes how, when, how, and who will test the software.
It is usually the project manager that carries out the test strategy. It contains everything from the type of technique to be used to which module needs to be tested.
It merely narrates the sequence of the test.
The plan narrates the specification.
It narrates the general approaches.
It is not usually changed, but if there is a significant change in the software, a few steps are added or removed from the sequence.
A test plan can change since it is conducive to a modification of the software.
A test strategy is never changed because it is a static document and remains the same for all records.
5. Purpose of the process
Validate the functionality of the software.
It is used to determine the possible dependencies and issues to identify the risks.
It is a long-term project. A test strategy doesn’t change from one software to another. Therefore it is used to abstract information from software and use it for test approach.
6. Level of use
It is a relatively stable concept and one test case can be used for numerous projects.
It is used at the project level, therefore can be used only for one project.
A test strategy is used at an organizational level and can be used across multiple projects.
Let’s take a look at how a test case, test plan, and test strategy are written:
Think of a strong title
Add a description
Write down assumptions and preconditions
Add the test steps now. Make sure that the steps are mentioned explicitly and in a concise manner
Mention the expected results
Make sure that the test case you make it reusable so that the software testing team doesn’t need to create a new one for every software
Any test plan first starts with analyzing the software. Ask yourself questions including who will use the software, purpose of making it, and you want it to work.
Design your test strategy. It is constant across all software, so you only have to modify it slightly
Write down test objectives
Define test criteria
Conduct resource planning
Plan the software’s test environment
Develop schedule and estimation
Determine the result of the plan
Write down objectives for your test strategy
Mention the test guidelines
Decide your test approach
Mention the tester’s roles and responsibilities
Write down all levels of testing
Mention the functional specifications, test scenarios, and acceptance criteria
Mention the entry and exit criteria
Write guidelines about what to do when a defect is identified
Provide information about migration procedures and environment information
Mention constraints of the test
Include risks of the software and how to solve them
However, all these three concepts are interdependent and work only when each one is present. A test case is used in the test strategy which in turn is used in the test plan. They might be developed or performed by different people, but the test result is cumulative of all their input.