How to effectively document exploratory testing sessions for future re-use without slowing down?



  • Background: On using exploratory testing heavily complimenting automated testing , where every tester documents his/her observations in individual personal ways in fast timebox sessions which is working out well in finding crucial bugs.

    Question:How to effectively document exploratory testing sessions observations for future re- use by other team members in the form of formal test cases?

    Management Perspective: The idea is in long term, a big subset of those test cases can be good candidates for automation as well.

    Concern: One big concern received from QA group is if they start documenting these sessions output in formal test cases , they will loose the advantage of speed because documenting each test case step by step takes time. Sometime more time than the testing session itself.



  • Concern: One big concern received from QA group is if they start documenting these sessions output in formal test cases , they will loose the advantage of speed because documenting each test case step by step takes time. Sometime more time than the testing session itself.

    Support via tool: We got similar situation in our case. Hence we searched for a tool which fits our needs regarding exploratory testing. So we didn't decide for a tool like HP ALM, we decided for a tool called QASymhpony because it fits our needs, when executing test cases it directly created test cases. So there was no need to create test cases - because this is done during test execution (sure we had to make some adaptions but it was running smoothly). So I think exploratory testing depends also on the test tool which you have.

    Mob testing / pair testing: Furthermore you can do some kind of mob testing which is nearly same than pair testing. We got in contact with our Product Owner and/or developer and tested together on application. So we just didn't documented anything because the tool was already documenting the test steps. If you don't have the tool you can easily write notes and pin them up the board which we also did for collecting ideas how we can proceed with testing. And in case that we found defects or bugs THEN we created test cases just to make sure that we don't repeat the same defect. So you can reduce your relevant test cases. More about pair testing you can find in Lisa Crispins page, whichs is very helpful and delivers some input! Paaring for learning

    Invite business department to reduce test cases: Furthermore we invited the business department for testing. We were very astonished how they tested. Because we tested mainly based from the user story and the business department checked other things from the customers perspective (somehow like this: Catalogue examples of exploratory testing. So I think inviting business department for testing (or even potential customers) can be a good advice for creating test cases. Of course we didn't created for each person from business department test cases, only in case that a bug has been detected. This helped us to reduce the amount of test cases (which we actually wanted to create).



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2