What is a test case?
Testing documentation (or
But what makes a good test case? And how do you write one in such a way that anyone can understand and follow?
Test case 101
A test case is a set of written steps, the expected outcome and the actual outcome of a single test that has been derived from the user requirements of the AUT (application under test).
Test cases are (mostly) written by software testers with to help guide their testing of a particular feature. Essentially, you can think of a single test case as a list of step-by-step instructions to achieve an expected result which can be positive, or negative in its outcome.
What should be included in a test case?
A test case should be compiled using the following information at a minimum:
- Title
- Description
- Steps to completed
- Expected outcome
- Actual outcome (to be completed once the test case has been executed)
It is also a good idea to include details of any prerequisites for your test case such as any test data to be present before execution. This can be as a reference to a previous test case for example instead of including multiple additional steps for the reader to follow. As this can make your test case unnecessarily complex and difficult for developers to investigate if there is an issue with one of the steps.
Do you have an example of a test case?
As mentioned above, test cases are derived from the requirements of the application being developed. So if we take the example of a website in which there is a login box that logs you in if you provide valid credentials. A test case for this feature might look like the below.
As you can see, the title, description, steps to complete the test and the expected outcome are all clear, easy to understand and are to the point. This is very important in writing a test case as there can be no room for interpretation by the person reading it.
For example, in the test steps section. You should list out the steps as specific as you can and try not to leave things for the user figure out for themselves.
The following is an example of a bad test case.
If you are not clear on the expected outcomes or the steps required to successfully run your test. Seek further clarification first before authoring your test case as this will make things much easier when it comes time to execute it.
Test cases can and will change
Once you have written a test case. Go back over it with a critical eye and ask yourself the following questions.
- Is it clear?
- Does it make sense?
- Does it leave you with any questions about it’s intended purpose?
You should also from time to time go back and review older test cases. The world of software is constantly evolving. Existing functionality is prone to modification as the requirements are updated, and thus your test cases should also be revisited and updated over time to ensure they’re still effective.
Details of any changes made can be logged in a database, or online management tool if you are organizing your test cases in that way. But also a simple table in front of your test case is just as effective.
When are test cases used?
Test cases are utilized when the AUT is ready for the testing process to begin after the development of a certain feature. They should be prepared ahead of time using the requirements document where possible so that once development is complete. Testing can begin its process immediately.
A well-written test case can also be used as the basis for a bug report for the development team if an issue is discovered in one of the steps of your test cases that leads to unexpected result
Conclusion
We have seen what goes into writing an effective test case.
They should be short in their step numbers and use clear and easy to understand language that ensures the end-user can follow it without difficulty.
A well-written test case can lead to better quality software and better understanding within the testing team.
