You know when you have a set of test cases to get through before the end of the day, but something catches your eye? What do you do? Do you indulge your curiosity, or do you carry on like a good tester?
I find myself in this position nearly every focused testing moment of the day. While I’m obliged to execute my assigned test cases for the day, I have a difficult time ignoring peripheral abnormalities — perceived or otherwise. My curiosity is, well, insatiable at times.
If you’re like me, then you’ve probably noticed that indulging that “tester’s curiosity” tends to score bugs — some of them pretty nasty at times. Have you noticed that some of the best finds come on the heels of indulging your curiosity? I sure have.
Here are three reasons why curiosity makes the tester:
1. A Test Case is Just One Path
In a complex application, like we’re building on my current project, we surpassed the point of practical infinity a long time ago. That is to say, there are so many permutations to test that it’s virtually impossible to cover them all. Ideally, we’d have a test case for every possible path and combination of paths through various BPM processes and business cases, but that’s just not feasible.
Each test case is but one path through a workflow. Along these paths, we would expect the application to behave well. But what about everywhere else?
That’s where curiosity comes in. If something catches your eye while testing one of those standard paths you’re responsible for “patrolling,” an extra 1.5 minutes to assess what you notice and compare it to the requirements could be the difference between getting a pat on the back for catching the next PROD killer or getting blamed for not catching it.
2. Bugs Don’t Hide in the Spotlight
Similar to point number 1, bugs don’t hide in the spotlight. Ok, bugs don’t “hide;” I get it. What I mean is, all the little code devils don’t typically appear where you expect them to (e.g., the happy path). To use a different metaphor, the gravel that causes a motorcyclist to lose control of their bike usually isn’t in the tire tracks of the cars and trucks that have gone ahead of them. Where we tread most often, bugs are less likely to be.
That’s where curiosity comes in. Free-wheeling it may not fly as an M.O on an all-day-every-day basis, but given a few moments of downtime, you’ll be surprised what an un-structured free test session can scare up.
3. Exploratory Testing is Underrated
And, like a high school drill team contagion, that sets up my final point: exploratory testing is underrated.
Automation is hot right now and everyone wants automated testing this and automated testing that. In addition to automation skills, a “destructive” testing mentality seems to be equally popular. Don’t get me wrong; I’m not knocking either of these attributes. I’ve headed in the automated direction myself, and you can bet I want to break some stuff in the process of crafting an awesome system with my teammates.
Nevertheless, I think that being a world-class observer is THE skill required to be a tester. Let’s be honest, if you weren’t good at “Which of the following don’t belong” questions as a kid or you simply don’t care to get better at them, then you probably aren’t a software quality assurance tester. This is simply a seminal ability. It’s teachable, and therefore learnable, so anyone can become a great tester. The question is, do you want to be one, though?
Here’s where curiosity comes in. Exploratory testing is an exceptional way to explore the nooks and crannies of functional code. It’s a way to shine a light into a dark place that doesn’t normally receive scrutiny. It’s a way to observe hidden defects that could be the basis of a major snafu a few releases from now. And it’s also a way to practice being a world-class observer.
If you’re unfamiliar with exploratory testing, just Google it. There’s tons of information out there. I’ll write a follow-up post detailing some best practices for exploratory testing. In the meantime, stay curious, my friends!