Have you ever felt stuck in your testing approach, running the same kinds of checks but not uncovering new insights? Fifty Quick Ideas to Improve Your Tests challenges conventional testing habits and offers fresh perspectives to make tests more effective, reliable, and insightful.
This book delivers exactly what the title promises—50 practical ideas, drawn from real-world experience, to enhance different aspects of testing. While not every idea may fit every situation, the book encourages testers to think differently, experiment, and refine their strategies.
It’s not a beginner’s guide; it assumes some prior knowledge of software testing. But if you’re looking for actionable tips to generate better test ideas, improve testability, and manage large test suites, this book is a goldmine.
What stands out is the book’s format: each idea is neatly packed into two pages, making it easy to absorb and apply. You can, for example, read a few ideas each morning and reflect on them throughout the day.
In this blog post, we’ll cover three key ideas offering a fresh approach to tackling common testing challenges.
Idea 1: Ask “What happens instead?”
When writing automated tests for asynchronous systems or functions, waiting for an event is usually the best approach. But how do you test for something that shouldn’t happen as there’s no event to wait for?
Waiting for an arbitrary amount of time is a bad idea: it makes tests brittle, environment-dependent, and easily affected by many other factors.
The book suggests a different approach: asking “What happens instead?”.
Rather than trying to prove the absence of an event, identify an alternative observable event that should occur. This makes tests more reliable. If no such event exists, consider using log files or other technical output to determine when an action has ended.
It’s also possible to take this a step further—applying it early in the development process. For example, discussing “what should happen instead” when defining new features not only improves testability of the software but can also reveal hidden requirements and expose assumptions.
Idea 2: Tap into your emotions
When thinking about test scenarios, you often start with the “happy path”—the simplest case that is expected to pass every time. However, Fifty Quick Ideas to Improve Your Tests introduces a heuristic that broadens this perspective by linking various testing approaches to emotions and behaviors.
The authors use the “SHADED FIGS” mnemonic to help remember these different paths:
- 😨 Scary path: Tear the house down. What’s the worst that could happen? Identify scenarios that would terrify stakeholders.
- 😁 Happy path: The simplest, most straightforward test case, where everything works as expected.
- 😡 Angry path: Be aggressive. What could cause the system to react badly and throw errors?
- 😎 Delinquent path: What are the security risks?
- 😳 Embarrassing path: What would be a big embarrassment? Look for typos, broken features, and more.
- 😑 Desolate path: Test with empty or incomplete input—zeros, nulls, blanks, or truncated data.
- 🫤 Forgetful path: What happens when memory or CPU is low? Could data be lost?
- 🤨 Indecisive path: Act like an indecisive user. Go back and forth, enter and erase data repeatedly.
- 🤑 Greedy path: Select everything—click all buttons, enable all options, etc.
- 😓 Stressful path: Push the limits. Find the breaking point.
What makes this heuristic valuable is how easily it sparks interesting conversations about potential scenarios and edge cases, e.g. during specification workshops.
Idea 3: Let the chaos monkey out periodically
The best way to ensure tests correctly detect unexpected impact is to introduce problems on purpose and verify that they are caught.
Netflix is famous for their approach to testing network resilience. They use a service called “Chaos Monkey” in production, which randomly switches off virtual machines or causes other types of common network failures, just to ensure their system can withstand real-world disruptions.
A similar approach can be applied to critical parts of any software. By deliberately breaking components and running tests, you can assess coverage. If alarms go off, those areas are well-tested. If nothing happens, it’s a sign more tests are needed. The same applies to the software itself: if something is broken and no alerts are triggered, improvements may be required.
Periodically “letting the chaos monkey out” allows teams to create controlled disruptions in a safe environment, improving their processes without the added pressure of dealing with real customer issues. You can see these sessions as exploratory testing exercises that benefit from cross-functional group involvement. By scheduling them periodically with a fixed timebox, teams can systematically address risks. The insights gained can then be used to improve both automated tests and the software itself.
Conclusion
These are just a few of the 50 ideas explored in the book.
Each concept encourages a fresh perspective on testing—from considering different emotional paths to embracing controlled chaos.
Whether you’re looking to improve test coverage, enhance testing processes, or spark meaningful discussions in your team, this book offers practical insights that can be applied right away.