Learn how to write good test cases
A common discussion is whether we should automate our tests instead of doing it manually. Often the answer is yes. We want quick feedback, test earlier and free up more time for exploratory testing. What is right or wrong depends on the specific situation I would say, but my point here has nothing to do with this.
Expectations on new testers
As automation has become a natural part of testing today, new testers that starts their first job are expected to start writing automatic test cases from day 1. Writing good test cases is an underestimated skill needed for most types of testing. Even when you do exploratory testing and document what you have tested. Then your documentation becomes a scripted test case that you can either automate or test again in the future.
What does a good test case look like?
Good test cases are short and easy to understand if not by the title at least by the steps. They focus on one task, requirement or function call only. This makes it easy to understand what they are testing, and you only get one requirement connected to the test case instead of multiple. In an automated check you know directly which feature or part of the code that has failed, compared to if you have many checks in one, then you need to investigate what it was that failed.
An example could be a large function consisting of many different tasks inside. To test it you create a test case for each task instead of doing one test case. In this way you will immediately now what the problem is without investigate which task it was that failed.
“So how do you learn to write good test cases that don’t do these mistakes and are easy to understand?”
how to write good test cases
A good way to learn is always by doing and for that reason it is much easier to start with manual test cases that you will perform. Compared to automatic checks that run in the background while you wait. When you do, you will notice early when an instruction is strange or does not follow the correct order. For example, if you try to change a setting that is not possible until you activate a function. Your failed automatic check will probably tell you this as well when you investigate what the reason was.
That’s why it always a good habit to write down in advance what you want to test even when you automate.
How to design a good test case?
But this is only about the test case itself, then you have the design of the test case and which parts that should be included. For example, preconditions, so it becomes repeatable and easy to perform without upfront knowledge. Don’t have to many details and actions within one step, it will just become messy. Better to add one extra step instead. Also, how important it is with a strong title, so it’s easy to understand what you are testing. On test automation resources you can read more about how to design good test cases.
Conclusion
Writing good test cases are important and more difficult than you think or especially managers think. It is also important no matter what type of testing you do, such as manual script testing, automated checks or exploratory testing. Because of this it is hard to expect that new testers without experience will deliver good test cases from day one and especially good automated checks.
What are your experiences, or thoughts about test case design?
