As testers, we look at everything with a critical eye. As soon as something comes up for testing, our instinct is to get down to examining it and looking for problem areas. After getting a written test script, a new tester would be tempted to begin executing scripted tests right away.
But stopping to gather our thoughts about possible test ideas first is a smarter approach that leads to better, more unbiased test coverage. However, we don’t always have a lot of time to imagine scenarios and different paths. Luckily, there is always some planning we can do beforehand.
In my article published at Gurock Testrail blog I shared some tips for generating test ideas in a time crunch.
Revisit classic test techniques
Our old, trusted test design techniques like boundary value analysis, equivalence class partitions, decision tables, and state flow diagrams are always a help when thinking about test cases. Although most of them are ingrained in the thought process of a tester and are mostly common sense, giving them a revisit, however informal, may still give us some more test ideas.
For example, creating a quick decision table for the interaction of two or more variables to observe the behavior of the system may reveal some unique combination that we might have missed. Or a quick boundary value analysis for the age field in our we form may show us a special case we might have missed.
Similarly, using state transition diagrams to draw end-to-end flows can help not only the testers, but also the developers in imagining the overall system flow and revealing problem areas.
Look at the history
The history of the project or the system can give us many insights into what we are dealing with, where the common defect clusters are, and the most problematic components.
If you are new to the test team, start by having a look at the defect tracking from past sprints or releases. You can then define and think of more test cases based on past defects and the components that have had the greatest number of defects.
If you’ve been part of the team for a while, you are probably intuitively bound to focus on these areas. But even then, it will help to consciously make an effort to list the most common types of bugs encountered and most problematic areas based on your experience. This will help not only you, but also your new and junior team members. Read full post->
Use defect taxonomies
Some common types of components, like login fields, an e-commerce shopping cart, or a simple client-server interaction, are built into a number of software systems. As a result, they have already been designed, developed, and tested by many teams all over the world, so there exist predefined defect taxonomies or checklists that can prove useful for teams that are creating similar system components for the first time. It’s smart to make use of the experiences other people have shared online.
These defect taxonomies will help you learn about common issues related to functional and non-functional aspects of what you are building. Use them to generate more test ideas. Over time, you can build your own project’s defect taxonomy to share internally with your team.
There can be no better way to find techniques to exercise the system than to actually do it. Begin working the system and explore your way around it so you can understand what it does, see how it behaves on different paths, and try out unique flows. More often than not, you will stumble onto new scenarios and flows that might have been missed in previous test designing. You can then proceed to look for problems or new behaviors and add them to your test cases.
When you find yourself pressed for time, try these tips to quickly generate better test ideas!
<image credits- freepik.com>