Very often there are test cases, in which the testing progress of a specific function is not fully described.
Any test case should have a minimum necessary (and, at the same time, sufficient) amount of information.There is «a golden mean» in relation to the amount of information in test cases. If a test case has a lot of unnecessary (secondary) information — it slows the progress of reading, understanding and passing of a test case itself. And vice versa, if the amount of information is too small — it leads to a misunderstanding of what exactly needs to be done in order to pass a test case.
Main test case attributes are the following:
- «Preconditions» — contains the description of actions that should be done, but they are not directly related to the verification.
- «Steps to reproduce» — contains the description of actions that are required for verification.
- «Expected result» — the verification itself: what do we expect to get after completing the steps to reproduce.
If the filling of steps and an expected result are mandatory, the preconditions are filled only by the necessity. However during the participation in our courses, this point is a mandatory attribute of the test cases.
Preconditions combined with steps should provide the completeness of information and contain all of the necessary actions from launching the application and up to the detailing of the operation of the test object. Often there are test cases, in which some steps are missed or important information is filled in the preconditions. Expected result should as well be described extensively enough.
Consider the example:
Example 1
| Incorrect case | Correct case |
| Preconditions.
The application is launched, the the settings screen is opened Mistake: The information that the user is signed in is mandatory in our case. Steps to reproduce:
Expected result: The user is signed out Mistake: Besides the fact that the user’s status becomes «signed out», we also expect an automatic transition to the login screen |
Preconditions.
The application is launched, the user is signed in and the settings screen is opened Steps to reproduce:
Expected result: The user is signed out, the login screen is opened |
In addition, test cases should be described generalized enough. If this principle is not followed, the test cases will need to be adjusted after each small change in the application or site.
Example 2
| Incorrect case | Correct case |
| Preconditions.
The user opened the http://домен.ру site and signed in Mistake: It is not advised to indicate the url of the website, since testing of the website can be performed on different test environments. It can be a production, as well as the developer test environments. Steps to reproduce:
Mistake: If it does not complicate the understanding of steps, it is better not to specify the exact name of the button, but instead describe it in a more generalized format (e.g. by functional purpose). In this case, if the button is renamed, or if another language is set, the current test case will remain relevant without any changes |
Preconditions.
The user opened the site and signed in Steps to reproduce:
Expected result: The user is signed out |
Practice, write competent test cases.
And you will definitely succeed!
