Common mistakes in test cases on the course

One of the practical exercises types, which is a part of our course, is the test case  filing. To solve this task successfully, we will discuss the most common mistakes that beginners make when they create a test case  in this article . We hope that after reading this it, it will become much easier to design good test cases.

1. The topic of the test case is not described according to the principle «What is tested? Where is it checked? What type of data is it checked with?»

Answer of the question «Where is it checked?» may be omitted  in case the functionality is only available in one place. Also you don’t need to answer the question «What type of data is checked?» if the functionality does not require data entry.

For example: Authorization on the site using invalid data.

In this case, the «Where is checked» part can be omitted because the authorization on the site is available only in one place. The topic of the test case becomes more concise without explanatory information: Authorization using invalid data.

2. Description of the steps in the preconditions.

The preconditions do not need to describe the sequence of user`s actions (steps). It is enough to mark which page the user is on or which form is open (its name). But you do not need to insert a link to a form or page as its address may change during development.

Also, in the preconditions section, it is necessary to describe the criteria that have nothing to do with the functionality, but are mandatory to fulfill (whether  the user is registered, authorized, in what state the system should be brought, etc.).

3. Input data type not specified.

In the steps, you must indicate the type of input data (valid, invalid). In the case of invalid ones, examples must be given (for an email input field, only numbers, special characters, no @, no domain will be invalid). This information is indicated to speed up the verification of the test case.

4. The test case consists of one step.

If the test includes only one action, there is no point in completing a whole test case for this function. So, it will be enough to use the checklist. Test cases are designed for complex functionality, which includes filling out forms and/or navigating through the pages (or other elements) of the product tested. At least two steps should be described, but no more than 9-10 (The more information, the higher probability of missing an important detail).

Also, one step should describe one action, you do not need to combine several actions in one step.

5. The test case ends with a step describing the actual result.

This is because test cases are usually created at the test design stage, BEFORE getting to know the tested product. It is necessary to describe checks based on how certain functionality MUST work. For the same reason, the steps do not need to include a link to the bug report.

6. There is a link to the site in the first step.

Do not confuse writing test cases with making bug reports, where the link to the site is indicated in the first step. This is unacceptable for test cases. The link can be specified only in preliminary conditions and only to the main domain, since the address may change in the future during development.

7. Duplicate step numbering.

In TestRail, steps are numbered automatically, so there is no need to duplicate the steps numbers manually.

8. The grammar of the test case.

A common mistakes in the test cases is the misusage of tenses and voices. The preconditions and results are described in the Present Simple Passive Voice, where the focus is on the element. Steps are written with the help of the  infinitive without using a third person endings it is done to shift the focus directly to the action.

In test cases, as in bug reports, preconditions and results should be described in full sentences (subject + predicate) in order to convey the essence as accurately as possible.

9. Test case is incomplete.

Another common mistake is when a test case does not fully describe a function and ends halfway. For example, a password recovery function should end with  a successful password change but not with  sending an email with a password recovery link to email.

10. Duplicate test cases.

Quite often, such an error occurs when several test cases are created for one functionality with one type of data (for example: in one case, for checking authorization, an invalid email and a valid password are entered. In the second, on the contrary, a valid mail and an invalid password). To test one functionality, two test cases are enough - with valid and invalid data. The rest of them simply repeat the essence of the checking process so they are closed as duplicates.

We hope that our tips will help you to fill test cases correctly. After all, a well-written test case helps to understand the product deeper and simplifies the testing process.