A test case is the main document of a tester, that describes step-by-step actions, needed for testing a certain product or its functional capabilities that will lead to the result you are looking for.
A test case can be also interpreted as the document that records a test case.
Test cases can be divided into two types (by their level):
- low-level test case – test case that has certain input information and expected results. This type of test case is ready for execution and is considered as the typical one. The newcomers of the testing field are taught how to write low-level tests since it’s easier to describe the overall information in detail than to choose the most important parts from huge data flow, not making a test case less relevant.
- high-level test case is a test case that doesn’t contain input information and expected results. Mostly, a test case of such a type describes only general principles and actions and is in some way similar to the checklist item that has been thoroughly described. High-level test cases can be used in smoke, integration and system testing. They can also serve as an initial push in exploratory testing or for writing low-level test cases.
Test Case Types
The word “case” in testing means the case that is created for testing the work of a certain function. The overall process described in a test case allows testing only one case, only one way of software usage.
What is a test case topic? How should it look like?
A highlight dark=”no”]test case topic[/highlight] is the test’s name that greatly simplifies the process of its searching and makes it clearer.
To write correct test cases, a tester needs to have certain skills, such as:
- Be familiar with test design techniques and know how to implement them in his/her work;
- Be able to divide the system into elements. This means that you should know how to work not only with the whole system but also know how to divide it into its structural parts. This skill is crucial for functional testing where every element should be tested;
- Be able to express your thoughts both in a written and oral form. This skill is important for a tester of any type and it helps a test designer to write the test cases;
- Be able to find the product’s requirements and to analyze them. If the test case has no product’s specific, you should ask the developers and users for them;
- Be able to properly prioritize.
Test case topic shouldn’t have:
1. Unclear, improperly set expressions. If a topic is unclearly written, this will not only interfere with test case passage but also will influence the general understanding of a test suite.
While creating a test case, you should remember that:
- Things that are currently clear to you can turn into something abstract, unclear in time;
- The abbreviations you made up while creating a test case and that can be interpreted currently, can turn into something unclear to you.
- Test case topic that can be interpreted by nobody but the person who created it can’t be used.
It’s clear: the creator of test cases can become ill or in, the worst case, retire, therefore, you should write a test case taking into account that it must be easily perceived by other workers as well.
2. Dependence on another test case. If test cases are interdependent, one of them can be deleted due to its uselessness or can be changed in some way. In this case, it will be unclear how to execute a test case that contains links. Moreover, since test cases are interdependent, it may look like the product that is being tested is already ready, with the help of test case execution.
3. Unnecessary details. Unnecessary details only make the perception of the topic’s sense more difficult. It’s important to keep in mind that the test case name should describe the functionality that is being tested and be unique for a product. This will greatly simplify searching for a necessary test case among other ones on a project.
The most common errors during the test case creation
If you design a test case that contains certain data, you remember that they should be correct and be designed in an established order. Or otherwise, such a test case becomes useless.
Example 1. Test case 01. Create a tenant
The first disadvantage of this test case is its name. It’s incorrect. At first glance, it may look like it’s simple, short and clear but if we try to create a test case that will contain incorrect data entering (a full name), they will be named in the same way.
Consequently, a tester that has the task to test the “create a tenant” test case, will find several test cases with the same name in a system and will simply not understand what test case must be checked.
Don’t forget about the rule “short but clear”. the name of a test case should tell a tester who works in a project what he/she should do, not looking at the detailed description of steps. Therefore, such a name needs to be complemented.
Example 2. Test case 02. Create a tenant with correct data (a full name) (a fixed variant)
It’s better but it can still be improved.
Let’s analyze its errors:
- its abstract name. Such words as “correct” shouldn’t be used.
Actually, you can create numerous tests of such a type but still, they will be different in some way. “Create a tenant without his/her patronymic” is also a text with correct data but its name directly says what this test case is about.
While designing test cases, you should take the following points into account:
- A test case should be written in such a way that it’s simple and clear. It’s important that a test case should be written in simple words, without technical terms and complex constructions since workers who have a different qualification and education;
- You should pay attention to sets of test data if any. They should be correct and written in an established order;
- You should understand the requirements, needed for test case design. To make a test efficient, you should understand how certain functionality of a product should work. Before starting writing a test case, you should specify all questionable details and only after this, start writing a working test case. Or otherwise, you’ll have to do double work.
Leave A Comment