Software Test Documentation: What Should It Contain and Why
Software Test Documentation: What Should It Contain and Why
In general, the test documentation can contain: a title, a step-by-step description, an expected result, a criterion of the correspondence between the expected result and the actual result.
The test case must necessarily contain at least the expected result (even, perhaps, without describing the actions that lead to it). For example, “The program must be able to show BMP files”. Such a test case is simply a copy of a software requirements specification document.
However, it is not clear how to run this test case. A person unfamiliar with the program may simply not know how to use its interface for displaying graphic files that have been selected. Therefore his bug report will say that the program just can’t do this.
Therefore, apart from the expected result, we also need a step-by-step description of the actions that will allow us to arrive at the actual result and compare it with the expected result.
It makes sense to include a brief description of the test case in the title.
Example
Title: “Checking whether the program can display bitmap (.bmp) files on the screen”.
Step 1. Click “Select File”.
Step 2. Select a file that has the file extension .bmp.
Step 3. Click “Open”.
Expected Result: the contents of the file are shown in graphical form, in full-screen mode.
It is a simple way to compare the expected result and the actual result, therefore there is no necessity to establish correspondence between them. Let’s consider a more complex example:
Title: “Checking the changes to user’s home phone number in ActiveDirectory”.
Step 1. Click the ‘Create User’ button.
Step 2. Enter username, user ID and password.
Step 3. Press the ‘OK’ button.
Step 4. Select the newly created user in the list by clicking on his login.
Step 5. Click the ‘Edit’ button.
Step 6. Enter the phone number in the ‘Home phone’ field.
Step 7. Click the ‘OK’ button.
Expected result: the home phone was saved in ActiveDirectory.
In this example it is best to represent the expected result as a sequence of steps, i.e. how to look in ActiveDirectory to make sure that the home phone has been saved. This will be a description of the criterion of correspondence. You can include these steps in the same document, starting with number 8, and refine the expected result:
Step 8. Log in to the AciveDirectory server.
Step 9. Open the dsa.msc snap-in.
Step 10. Find a user ID by login name.
Step 11. View the value of the Home phone field.
Expected Result: This value corresponds to the phone number in the ‘Home Phone’ field.
However, strictly speaking, these steps are not part of the test script. If you change or delete the script, this instruction may be lost. Therefore, it makes sense to write it on a special site – the Knowledge Base (KB), and include a link to this instruction in the test case.
If you want to write good software documentation then the services of technical writing company will prove to be invaluable for you.
