3 Simple Tricks to Make Exploratory Testing More Efficient

By 3rd March 2016 Testing

The Impact of Exploratory Testing

Traditional testing follows a fairly simple model in which there are test cases written beforehand for all the possible use cases and then, after the test cases are final, they are executed until they all pass.

Exploratory testing follows a different approach.

In exploratory testing, the test cases are written by the tester simultaneously, as they are executed. This technique has been shown to find more critical bugs than the more traditional form of testing.

In addition, exploratory testing can stimulate the creativity and curiosity of the testers. Simply put, it’s more interesting to work with exploratory testing as there are no ready-made test cases before the testing begins.

In traditional testing, it’s extremely hard to write comprehensive test cases that give unambiguous results and the tester often has to conduct the testing based on the expected and actual outcomes. This is what makes exploratory testing so valuable, because the testers have to use a lot of their own experience and knowledge to assess whether the product behaviour is feasible. The open nature of the exploratory testing effort takes the testing quality up several notches. High quality testing means higher quality products and a flawless user experience.

The Origin and Definition of Exploratory Testing

In the early 1990s Cem Kaner and James Bach developed the concept of exploratory testing. Exploratory testing could be defined as a testing method where an experienced tester leverages her/his testing knowledge and simultaneously writes test cases and executes them.

We can further understand exploratory testing by comparing two methods of interviewing customers to gather requirements.

In a structured interview, a pre-determined set of questions is used. In a semi-structured interview, the questions are used more like a guideline to ensure the core topics are covered, while allowing for the questions to evolve. The semi-structured way of interviewing is much like exploratory testing and arguably a more effective approach.

In exploratory testing there are no pre-made test cases, in-fact the tests are run while the tester is still getting acquainted with the system. From my experience, I’ve seen exploratory testing help testers come up with test cases which neither the developer, nor a traditional tester could have come up with under normal circumstances.

For example, when a defect is found in a product, the traditional tester would first try to reproduce it by looking at the condition that may have caused it. An experienced exploratory tester would not only look at the known conditions that may have caused the defect, but he/she would also look at alternative conditions and scenarios that can cause the same defect to appear.

3 simple yet effective tricks to make exploratory testing effective

 #1 – Use RIMGEA

RIMGEA is a mnemonic which stands for Replicate, Isolate, Maximize, Generalize, Externalize and say it clearly and dispassionately. RIMGEA comes very handy while filling up bug reports.

Let’s understand each factor more clearly.

  1. Replicate it first – As a tester, if you cannot replicate the defect, you would have a hard time convincing the developer to fix it, so make sure you replicate the defect first.
  2. Isolate it – You want to get to the defect quick and easy. Cut down the number of steps needed to be able to reproduce the defect so that you can isolate it.
  3. Maximize it – If you are able to reproduce a defect, don’t just stop there. Run follow up tests to uncover conditions and scenarios that may reproduce the same defect or might lead you to discovering the root cause of the defect.
  4. Generalize it – Here the tester un-corners the edge cases and tries to find other ranges in which the defect can be reproduced.
  5. Externalize it – Look at the defect not only from a tester’s role but from various other stakeholder roles. Document the impact of this defect to the identified stakeholders.
  6. And, say it clearly and dispassionately – Be clear in your bug report and take away the attachment and passion towards the defect itself. Remember that a tester and developer are really a part of the same product team so be neutral and unbiased so as to write bug reports for the benefit of the overall product team.

#2 – Keep it Simple, yet Comprehensive

If you go slow and steady with your exploratory testing, there are higher chances that you will win the race. There is no need to start with the most complicated scenario; you could start simple. You could use the As Late As Possible (ALAP) technique and defer worrying about details to the end. While keeping it simple, make small variations to the tests to get deeper and better results.

#3 – Employ Cross-functional Pair Testing

Set aside some time to do exploratory testing with a non-tester, for e.g. Product Owner or Business Analyst. If you don’t have an agenda when you meet them, you may start by testing some known defects in pairs. Having someone from a different functional area test with you improves the chances of you discovering more defects or untapped test cases. Make sure you set expectations beforehand with the non-tester so that you both get the best out of the exercise.

What if exploratory testing is brand new to your organisation?

Exploratory testing may seem radical to some organisations, especially the ones which have a command and control culture, driven by bureaucracy from up the chain. Don’t sweat it. Start by taking baby steps.

If you’re in a senior or leadership testing role you could take one or two defects and do some exploratory testing on them. After the testing is done, you can document the results and present it to the rest of the testing team. Once you get the psychological buy-in from your team, half your job is done. Next, have experienced testers use the techniques and slowly make this part of testing process.

Recap

  1. Exploratory testing has shown to find more critical bugs than traditional forms of testing. It encourages creativity and curiosity to blossom in testers while doing their job hence it’s a win-win situation for both the tester and the product team.
  2. The concept of exploratory testing was developed in the early 1990s by Cem Kaner and James Bach. It is a non-traditional testing method in the sense that the test cases are written simultaneously as the tests are run.
  3. Use RIMGEA in your exploratory testing which is a mnemonic that stands for Replicate, Isolate, Maximize, Generalize, Externalize and say it clearly and dispassionately. Keep your testing simple, yet comprehensible and do cross-functional pair testing.
  4. If exploratory testing in new in your organisation, test it out on a few defects or scenarios first and then document and share it with the rest of the testers to get their support on using the method as a part of the standard testing process.

Without a doubt, exploratory testing brings out the creative side in the testers and is extremely effective in improving the quality of the product. As good as this exploratory testing method is, it is still imperative to maintain a healthy balance between the regular testing and exploratory testing.

Too much exploratory testing may result in too much time spent on discovering edge case scenarios and more time lost on regular testing. Make sure you maintain that healthy balance between the two!

Join the discussion 2 Comments

  • <em>In the early 1990s Cem Kaner and James Bach developed the concept of exploratory testing. Exploratory testing could be defined as a testing method where an experienced tester leverages her/his testing knowledge and simultaneously writes test cases and executes them.</em>

    Exploratory testing was not defined as a method. A method is a way of doing something. “Exploratory” is an adjective to describe an approach that can be applied to a method. In any case, the idea of “simultaneously” was replaced by “in parallel” about 10 years ago. Since then, we’ve refined the notion of exploratory testing in some way that you might find helpful.

    “Exploratory Testing 3.0” http://www.satisfice.com/blog/archives/1509

    For instance: to say “In exploratory testing, the test cases are written by the tester simultaneously…” tends to direct focus towards artifacts and towards writing. We believe—and have found it for more useful—to think in terms of <em>testing being performed</em>, rather that <em>test cases being written</em>.

    “Test Cases Are Not Testing: Toward a Culture of Test Performance” by James Bach & Aaron Hodder (in http://www.testingcircus.com/documents/TestingTrapeze-2014-February.pdf#page=31)

    <em>What if exploratory testing is brand new to your organisation?</em>

    It isn’t. Exploratory work is happening all the time; it’s just that someone hasn’t noticed it.

    “Exploratory Testing is All Around You” http://www.developsense.com/blog/2011/05/exploratory-testing-is-all-around-you/

    —Michael B.

    • Thank you very much for taking your time to clarify our blog post and add links for further reading.

      You are right, exploratory testing is not a method but an approach.

      I fully agree that speaking about test cases might lead to thinking of test cases as artefacts. The purpose of our blog post is to explain complicated concepts in a somewhat simplified and practical way. It is always a tough balance between correctness and understandability. Test cases are seldom used in exploratory testing, but it is something that every tester can relate to.

      Yes, you are right, all testing is exploratory at least to some extent. However, far from everyone I meet is familiar with the concepts, and they feel that they are not doing exploratory testing. This is why we try to explain the concepts.

      Our intention is the best – to spread information about testing concepts in an understandable way. Thanks to your clarifications the information just got better.

Leave a Reply