I found Kristin‘s article about how she forgot to retest a bug very funny. Not because it is a joke but because I recognised myself in her story. When others find a bug in 5 minutes, that were there just under my eyes during my one hour session, I cannot avoid feeling bad. And often, those bugs are not tricky ones, they follow a clear pattern, as if the tester would know where the bugs hide — which can be a developer, some developers are very good at testing.
Bugs are gregarious
Well, in fact, it is exactly how issues behave. Bugs follow predictable patterns: they like to hook to some behaviours or some modules in the product or some kind of features. When one of those actions or place reveal an unexpected behaviour, you can bet a cookie that you will find similar ones if you continue digging. And you will have a delicious breakfast next day. Same issue elsewhere, other issues near to the first one. Bugs, like zombies, feel stronger when they piece together. And when you think of it, this is obvious: the same bugged code can be called in several parts of the application. Some contexts are not well handled by some frameworks or browsers. (Please be patient, I’ll come with concrete examples in the last section.)
The power of heuristics
The fact to find patterns in bugs and to foresee, not with certainty but at least with confidence, a possible weakness in the context of an application has a name. It is called a heuristic. It comes from your experience or other’s. Each time you test, as you are challenging your product, you can think of previous issues, possibly useful in the current context. For example, that bug you found last week, can you try to trigger it again in this new feature?
When you test deeply a feature, you don’t type and click like a monkey, do you? You try to perform the most useful test in a context. As testing is infinite, the choices you make are essential. When you perform a test, there are possibly hundreds of test you choose not to perform. That’s why collective knowledge is so valuable to test the right behaviour at the right moment.
Heuristics are a powerful guide to perform targeted tests. You probably know Elisabeth Hendrickson’s test heuristics style sheet. Read it every day. Print it and pin it on your wall. You can read books about exploratory testing. You can use mnemonics. And finally, you must create your own heuristics.
In your context, once again, the more you test, the more you find patterns of issues. Write them on a doc and use them on your next testing session. As time goes on, you will create a map of all the risks and weaknessesof your product.
When I test a form for the first time, my first test is always to click on validation button without filling any field. You will be surprised about how it manage required fields. Something, the third required field raise an error message. Why not the first? If this first test raise some issue, you can be sure your testing session will be fun, finding misbehaviours and even bugs.
Modern websites often have a back-end separated from the front-end. Sometimes the page is telling you that your actions are validated but sending information to the server is broken. In that context, use the “refresh” and “go back with browser button” heuristics.
And so on. In the case of files format, you obviously has to test extensions, size, name with upper case and spaces… And if you didn’t know, well, nevermind, you can learn from others, and add it to your heuristics arsenal. When you learn from your mistakes or oblivions, you become stronger.
One last thing…
And one last tip to test in the right direction, to find bugs that matter : ask questions. Ask at every moment, before, during and after development. There is no stupid question, ask until you are sure you fully understand the scope, the logic and possible impacts of current team work.
Product managers know a lot of hidden behaviours and dependencies (I hope they do!). Developers can give you clues as they can do white box testing. Ask other testers, they have different history and their own heuristics. All those conversations will help you to become the most useful tester you can be.
And you, do you have other strategies to drive effective testing and find useful bugs?