Test coverage measures how well we test the software and is crucial for making sure it works reliably and effectively. It tells us how much of the software is tested and helps us find the parts that aren't. Visualisation of test coverage data can simplify this task, making it easier to understand coverage data, identify gaps and make informed decisions. This is achieved through test cases and test suites, which are discussed below.
Test scenarios and test suites
So far we have looked at test cases from a project documentation perspective. Here we will talk about test cases from a practical point of view. A test scenario and a test case are the same thing. Let us remind you that a test case contains a sequence of actions aimed at testing some functionality. That is, it describes how to get the expected result (embedded in the requirements).
Test cases are grouped together in test suites. This is a set of tests grouped by some characteristic. For example, by the impact on the system, or by the functionality they test.
Test statuses
Test execution states usually vary depending on the test management system. However, there are some commonly accepted statuses that you should study:
- Passed – all steps are checked and meet expectations.
- Failed – behavior is not as expected, a new defect has been found. Include a link to the bug report in the comment.
- Broken – incorrect test, e.g. no step, inaccuracies in steps, etc. Specify in the comment why the test case cannot be passed.
- Blocked – the test case cannot be executed because of a bug that blocks it. For example, the test case is for authorisation and it doesn't work.
- Skipped – the case is still unfinished, e.g. it says to go to page X, but it has not been implemented yet.
Good tone when writing test cases
In the world of testing, there are rules that allow you to write clear and usable test cases. A good test case differs from a bad one in that it can be understood by anyone, even a new employee. Here are a few conditions that should be observed when creating test cases.
- One test case – one test. This is about atomicity, a test case should only test one functionality and not depend on others.
- The title describes the essence of the test case. It is also important to avoid duplication.
- Exact names for application elements (buttons, popups, sidebars, etc.). The wording is important because the test cases will be used by different people and everyone should be able to understand the content.
- Use simple but technically competent descriptions, without describing obvious things.
- All the steps necessary to test the scenario are described. If at least one step is missed, the test is likely to fail.
- The error found will be obvious. Both the steps of the test case and the expected results should be described in such a way that any deviation from them clearly indicates a defect.
- Easy modification. It is easy to make changes to any part of the test. With this approach, tests are used repeatedly. Requirements may change so it is important to keep this in mind and make tests as flexible as possible. For example: combine the repetitive steps of several test cases into one test case and refer to it in the precondition.
Common mistakes when writing tests
We have described the best things to do when creating a test case. Now let's talk about the mistakes you should not make when working with them.
Mistakes in design and wording:
- There is no test case title or it is poorly worded.
- Future or past tense is used to describe expected results ("the page will load", "the data was obtained").
- No alternative to the word "check" in the steps and elsewhere in the test case. For example, verify, test, control, review, etc.
- Punctuation, spelling, and syntax errors.
Logical errors:
- References to other cases – the test should be independent.
- Ambiguous descriptions of steps and expected results.
- Prerequisites are not described when needed.
Conclusion
As we have seen, writing literate test cases is not just a matter of following attributes and describing them in detail. In practice, certain standards are developed which make the use of documentation easier and more convenient. This is useful not only for you as a tester but also for your colleagues.