- Is there any standard or pattern of doing Exploratory Testing?
- Do we still need to write test cases or not?
- Is there any flow to follow with this kind of testing?
- How Exploratory Testing related with ‘Recon Testing’?
-
2I think 4. should be a separate question, could you also give a bit more background where you heard/read this term 'Recon Testing'– Niels van ReijmersdalOct 13, 2017 at 12:45
-
Related: sqa.stackexchange.com/q/28453/21973– beatngu13Oct 13, 2017 at 14:21
-
@Niels van Reijmersdal Please find the link that I found regarding this and which made me unclear about the relationship between exploratory testing and recontesting. stephenjanaway.co.uk/stephenjanaway/tag/james-bach– ShadowTKOct 17, 2017 at 5:47
1 Answer
No, there is not a defined industry standard pattern.
There is not a set definition for exploratory testing. I would read the Exploratory Testing 3.0 blog of James Bach though, as it explains the continuum going from totally free-style-exploring to exploratory-scripted.
The exploratory-scripted continuum. This is a sliding bar on which testing ranges from completely exploratory to completely scripted. All testing work falls somewhere on this scale. Having recognized this, we stopped speaking of exploratory testing as a technique, but rather as an approach that applies to techniques (or as Cem likes to say, a “style” of testing).
Your second question:
Do we still need to write test cases or not?
Yes ofcourse, but maybe not as a part of formal documentation.
Often I throw away my test-cases after an exploratory testing session. If we find defects we write a new automated test for it anyways.
We mostly use exploratory testing to find gaps in our test automation, as I describe in the Lookout part in my Test-EiffelTower blog, but also for a usability sanity check of-course. It clearly depends on the needs and the charters we define. Also what we test depends on where we are in the project.
Your third question:
Is there any flow to follow with this kind of testing?
When I teach exploratory testing methods I tend to let newbies start with the following format:
- Timebox: Set a timebox (90min +-45min)
- Understand the product/feature: Create a mindmap and charters. (update them next loop)
- Design tests: Pick some heuristics to validate areas of the map or charters
- Execute tests: Execute a few tests. Log your steps and results.
- Analyse: Analyse your results. Use root-cause-analyses to go deeper. Defects-cluster
- Loop: Is your timebox finished? Yes: Goto step 7. No: goto step 2.
- Stop: Stop testing and share your results with the team. Decide what the next actions will be. (Could also be another exploratory testing cycle.)
After practising this a couple of times feel free to go more scripted or more free-style. Depending on industry, project or personal-style.
-
1Too all please comment if you disagree or see it differently. I would love to chat or discuss this topic. Maybe even over a Skype like call. Oct 13, 2017 at 13:23
-
-
Interesting, maybe you could add SBTM as a full answer. Looks like a form of formalisation of Exploratory Testing. I have read it in the past, but personally I did not like it. Seems more like overhead that traditional test managers would love. Stuff like "Number of sessions completed" seems a total waste. A good Agile team should recognize the other metrics and adapt accordingly with retrospective if you ask me. For example "Percentage of session time spent setting up for testing" is something you should tackle after you struggled the first time setting it up or keep signaling each iteration. Oct 13, 2017 at 13:39
-
What you describe is SBTM in my book ;-) The original article originated from the need to formalize it a bit so organisations would like it, I guess. The whole idea behind CDT is to be 'agile' and flexible about it: no rigid rules.– Ray OeiOct 13, 2017 at 14:24