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.
- 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.
- 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.
- 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.
- Generalize it – Here the tester un-corners the edge cases and tries to find other ranges in which the defect can be reproduced.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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!