What are Quicktests and when are they used?
What are Quicktests?
Tests that don’t cost much to design, are based on some estimated idea for how the system could fail (risk-based) and don’t take much prior knowledge in order to apply are often called quicktests (sometimes stylized as quick tests or even called attacks).
When are Quicktests used?
When I’m about to test a new application the first part of my strategy is often to start with a few quicktests. I might choose to test around a particular interface, around error handling or even around boundaries cases. Similarly, when I’m about to test a new feature I can take a strategy where I look for common places where bugs might exist based on past experience (keeping an internal list of common bugs is a very good idea).
Boundaries are a good quicktest example: If there’s an input field on an billing or contact form we might decide to try testing some boundaries. Try to figure out what the upper limit is, lower limit, enter no information, try some weird characters, etc. Turns out you don’t really need to know much about the program to be effective with this approach and there are some handy tools that can help you.
The vast majority of us (developers, testers) use quicktests on a daily basis. And why wouldn’t we? They’re great if they work and if they don’t you can switch to something else. It’s not until these tests run out of steam that we’ll either need to switch focus to a new failure type or start testing the product in a deeper way. Hopefully by then we’ve gained some knowledge about the product and built a strategy around where we think additional valuable failures are so we can make better decisions about where / what to test.
More Quicktest Examples:
- Interface tests
- Boundaries
- Intial States
- Error Handling
- Happy paths
- Variable tours
- Blink Tests
- And many more… I’ve collected a few dozen examples and put them on this GitHub list.
When should Quicktests NOT be used?
Not every test is a quicktest, nor should they be. While boundaries are a good quicktest example, applying domain tests (specifically equivalence class partitioning) are not. In order to partition our field(s) (sometimes called variables) to develop our equivalence classes we need to know about the underlying data types for our variable (we might not know for sure, but we can make educated guesses). We need to know it’s primary purpose and what other variables might be dependent upon it. All of these things take time and effort to understand and apply. They’re still risk-based but they require more knowledge of the underlying system and are more costly to design.
It’s important to understand this concept of quicktests for a few reasons:
- Test Strategy. Depending on the context of our work our test strategy should probably consist of quick and deeper tests.
- Tool Selection. Really great tools like BugMagnet help with quicktests but not deeper boundary + equivalence class tests.
- Creating Examples. It’s hard to find good examples of deeply applied test techniques. Most are only quicktests.
As I look around the web for the available resources on teaching test design many of the examples we have of particular test types or techniques revolve around showing these quicktests. Hey put in some boundaries. You are done! Yay. (facepalm) Starting with inexpensive tests optimized for a common type of bug is a great start but not a great ending. Here’s to better endings!
Notes:
- I first came across the term Quicktests in BBST Test Design by Cem Kaner, while the term Attacks was introduced in How to Break Software by James Whittaker
- Check out my Testing Guides catalog on GitHub for more test ideas.