"Sometimes, doing something different BEFORE you start testing can help you find hidden problems. It's like looking under the couch for lost toys."
Are you a new tester? Working on an app with a team of five or more developers seems like a foolproof way to deliver a bug-free product. But the truth is that the number of developers assigned to a project makes no difference in the final bug count. No matter how experienced a developer is, bugs happen. There is no such thing as a "bug-free product.”
After a while, developers know what kind of bugs you tend to find, and you'll generally see fewer of the same types of bugs in the product that you saw only a few sprints ago. However, that's no reason to rest on your laurels. It's the tester’s job to keep identifying new ways to find bugs before they find their way to production.
Not every bug-hunting strategy requires you to improve your abilities as a technical tester, although improvement in that realm should be a goal. Sometimes, a few techniques that seem like quick hacks can increase your bug-hunting prowess.
Here are a few simple techniques that I've found beneficial.
Take A Different Path Every Time: Monkey Testing
Have you ever seen your developers build a new feature only to break another, existing feature? Odds are, you have, or you will in time.
Ultimately, if there are bugs in the product's core features, new or old, your team (including you) did not deliver what was asked for.
Failure point: You test a single feature at a time, doing just enough testing to ensure that the feature in isolation doesn't have defects.
What can you try? Once you have tested a feature in isolation, enter the application from different points in the user journey, landing on the feature under test. This is a version of what some have called "monkey testing," where the tester throws random inputs at the application under test like a monkey at a typewriter.
Testing Fast Versus Finding Bugs: Finding the Balance
Sometimes, testing feels like racing while wearing flip-flops. You want to run, but end up falling on your face.
Being fast is good (gotta learn all that testing stuff!), but rushing can make you miss even the obvious bugs.
Failure point: You try to keep pace with development without having a discussion with your team about what you need as a tester. The result is that you shortchange your test plans. Silence is NOT golden here.
What can you try? Look at how you can improve your test plans and what kind of time it will take to run new test cases. Then, chat with your developers and the product manager about how to add buffers for testing to their timelines.
Building the right thing is a team effort.
Be Kind To Yourself (And The Product You're Testing): Take Breaks
Let's say you have a tight deadline and you're afraid not to use all the time available to you. So you test, and test, and test some more.
Feeling tired? Too many tasks at hand? Switching between lots of tasks and tests?
Failure point: You tested the product nonstop, or so it seemed to you. You felt yourself getting tired and frustrated. And then 50 percent of the features got to production with bugs.
What can you try? Take a quick break after each test. This will help to reduce fatigue and to keep your cognitive biases in check. (Yes, testers also have these biases).
Identify the times in each day when you’re most creative. Could be the early morning, could be late afternoon after tea. Take advantage of those "up" times: that's when you’ll find the most bugs.
P.S.: This is the hardest tip to stick with but it can really pay off. Remember: if you're tired, you'll miss seeing bugs. Better to take a break and start fresh.
Going To The (Cognitive) Gym: Solve Puzzles
Sounds silly, I know. But it’s useful to keep your mind open to new horizons.
When we start testing a product, after a month what you test may become stale to you. No new features have been added, but still, new bugs are slipping into production.
Failure point: You get stuck in a rut, cognitively, and you can't find a way out.
What can you try? Solving puzzles helps you to stay creative and flexible. If you can't think outside of the box sometimes, you’re done as a tester.
Here are a few of my favorite puzzle sites: blackboxpuzzles, testingchallenge
Our Memories Fail Us! Use Testing Checklists
Have you played GTA Vice City? If yes, you must have created a cheat sheet.
Why did you make a cheat sheet when you already know the cheat codes? Because it gave you near-instant access to the codes rather than relying on memory.
The same technique can be helpful in testing. And it doesn’t matter if you have a Jira ticket or a tool with a test suite or list of test cases.
Failure point: People sometimes don't have mental access to everything in memory, especially as they execute a new task.
What can you try? Take a pen and paper and write down what you’re going to test. A simple bulleted list of words can be enough. Here's a good example: A Checklist for Login Page Testing.
To Wrap Up
Sometimes, doing something different BEFORE you start testing can help you find hidden problems. It's like looking under the couch for lost toys.
Using a “hacky” testing technique can help you go beyond your prepared test plan to find critical bugs. These quick hacks could help in improving testing so much that you could start to challenge yourself to find new bugs within 10 minutes of starting to test.
Do you have any hacks like these that improved your testing? Share them with the Ministry of Testing Club.
For More Information
- Taming The Beast Of Irreproducible Bugs: Finding Opportunities in Chaos, Rahul Parwal
- Software Testing Heuristics: Mind The Gap!, Richard Bradshaw and Sarah Deery
- Thinking Outside the Box: Cognitive Bias and Testing, Lisa Crispin
