Techniques to make exploratory testing even more efficient

Having coined the term in 1983, Cem Kaner now defines exploratory testing as “a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.”

Exploratory testing is a hugely efficient test technique in many situations. When it is extremely important to get it right, you want to try test in every possible way and then also test by exploration. When the tests have to be fast and it takes too long to write down in advance what is to be tested, exploratory testing comes in handy. Even in most other situations, it is useful to think exploratory.

In this article you will learn more about some important techniques that will give you great benefits in exploratory testing.

Test comprehensive, yet simple

When testing exploratory you test more or less in different ways each time. The opposite way (running the same tests over and over again) is good to catch things that have broken (regression testing), but to find new information, you need to run new tests or variations on the old ones. When varying tests you get deeper and better tests with a greater chance of finding new, important information.

Keep it simple; you get far without frills. Use the principle of ALAP (As Late As Possible) and determine the details as late as possible. Start by describing what is most in important in the format of one-liners or checklists, which can be reviewed just before being used.

It is better to test well enough in many ways than to test perfectly in just one or two ways.

Serendipity

Serendipity is not just the 2001 romantic comedy starring John Cusack and Kate Beckinsale, it is also to look for something, but then finding something else that is valuable. This is extremely common for testers who have their eyes wide open. Very often we’ll be testing something, but seeing something very different, important, somewhere along the road. Specs are a good start, but there is so much more you can do, for example, the below.

Use RIMGEA before you write a bug report

An mnemonic which comes in handy is that of RIMGEA. This one is especially useful when filling out bug reports.

What does it stand for?

Replicate it – Try to see if you can replicate the bug.

Isolate it – Try to limit the steps or the conditions that trigger the bug.

Maximize it – Try to do follow-up steps to see if you can trigger a worse failure.

Generalize it – Try to broaden the extent of the bug.

Externalize it – Try to consider the value and impact of the bug in other stakeholders’ perspective.

And finally, say it clearly and dispassionately – Try to create bug reports that are as easy to understand and as neutral as possible.

This blog post gives a good overview of the RIMGEA mnemonic http://testkeis.wordpress.com/2011/06/22/rimgea/

Once you have done the above, write bug reports according to this template to make them extra clear – https://reqtest.com/blog/newsletters/how-to-fill-out-a-bug-report/