4
  1. Is there any standard or pattern of doing Exploratory Testing?
  2. Do we still need to write test cases or not?
  3. Is there any flow to follow with this kind of testing?
  4. How Exploratory Testing related with ‘Recon Testing’?
Improve this question
3

1 Answer 1

Reset to default
4

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).

enter image description here

http://www.satisfice.com/blog/archives/1509

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:

  1. Timebox: Set a timebox (90min +-45min)
  2. Understand the product/feature: Create a mindmap and charters. (update them next loop)
  3. Design tests: Pick some heuristics to validate areas of the map or charters
  4. Execute tests: Execute a few tests. Log your steps and results.
  5. Analyse: Analyse your results. Use root-cause-analyses to go deeper. Defects-cluster
  6. Loop: Is your timebox finished? Yes: Goto step 7. No: goto step 2.
  7. 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.

Improve this answer
4
  • 1
    Too 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.
    – Niels van Reijmersdal
    Oct 13, 2017 at 13:23
  • Might add SBTM to give more context for 'the flow' ;-)
    – Ray Oei
    Oct 13, 2017 at 13:31
  • 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.
    – Niels van Reijmersdal
    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 Oei
    Oct 13, 2017 at 14:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.