This is a guest post by Nishi Grover Garg.
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. Here are four tips for generating test ideas in a time crunch.
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.
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.
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!
Nishi is a corporate trainer, an agile enthusiast, and a tester at heart! With 13+ years of industry experience, she currently works with Trifacta as a Community Enablement Manager. She is passionate about training, organizing community events and meetups, and has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.
Help us improve this page!
What problem are you trying to solve?
Building QA into your SDLC is key to delivering quality. Here are the mistakes to avoid when building quality throughout the SDLC.
Organizations need conceptual and QA has crucial strengths to effect that change. Here are three winning action plans to change your QA culture and integrate it with the rest of your SDLC.
DevOps implementation involves shifting the attitude of not only QA but all roles in a team. This takes a considerable amount of effort!