A [highlight dark=”no”]test case[/highlight] is a certain list of actions, prevailing conditions and features that are necessary for checking to what extent the functionality that is being tested or certain separate function have been released.
[highlight dark=”no”]Preconditions[/highlight] are the combination of all necessary preparatory steps (program settings, testing environment), needed for executing this test case.
Preconditions contain important data (steps) needed for the initial preparation of OS, test program, mobile device, browser, etc. We should fulfill these conditions before starting test case execution.
If test case execution precedes the requirements that are described in preconditions, it can’t be executed or the actual results will be incorrect.
Preconditions may consist of one or a few sentences. There is no limitation to a sentence number but they should consist of [highlight dark=”no”]1 0r 2 sentences.[/highlight] In the same way as steps, preconditions should be concise but informative.
The preconditions may be also documented as steps if it’s required for a particular case (for instance, it’s needed for their proper implementation).
If it’s mandatory to fill the steps and expected results, the preconditions can be documented only in such cases when it’s necessary.
Examples
Примеры
Passed | Failed |
---|---|
A user has successfully logged in to a personal account. | A user has logged in with the help of a special “Authorization” form that is located on the main page and now he/she is in his/her personal account.
Note: in this case, it’s not logical to document everything in detail |
A user has logged in. One or several products have been added to a cart. | One or several products have been added to a cart.
Note: you didn’t mention important information on the authorization. It’s important in case if a user wishes to purchase a product. He/she can’t do this without authorization. Or you’ll need to write down various additional data and it’s a deviation from the steps of this test case. |
The PATH to the program’s components has been mentioned in the OS settings. | There are no preconditions
Note: in this case, it was mandatory to write down the PATH to the libraries since the program won’t function properly without this information. |
If there are several test cases and each of them requires executing several actions but these actions are not an object for testing, then the test cases of one type can be documented as preconditions.
For example, you need to create two test cases for testing the functionality of the “My address” form.
By using the preconditions in such a case, you can create clear test cases that are more properly designed:
Test-cases 1 (with preconditions) | Test-cases 2 (without preconditions) |
---|---|
Preconditions: a user has been authorized and is currently in a personal account, on the “My address” menu item.
1. Fill all fields with the necessary data; |
Preconditions: are absent
1. Log in |
Test-case 1 (with preconditions) | Test-case 2 (without preconditions) |
---|---|
Preconditions: a user has logged in and moved to his/her personal account, to the “My address” tab.
1. Fill all fields with the valid data |
Preconditions: are absent
1. Log in |
Apparently, preconditions may help to decrease the number of steps of test case execution [highlight dark=”no”]at least by 4 steps.[/highlight] This doesn’t actually impact the correct interpretation of test cases but significantly decreases its total number.
Such a practice helps not only [highlight dark=”no”]to build an efficient testing strategy[/highlight] but also to significantly [highlight dark=”no”]save[/highlight] the time of developers and the client’s budget required for testing!
0 Comments