Exploratory Testing innovation template test consultant

Is document a dirty word in Exploratory Testing?

I want to perform exploratory testing, but do I really have to give up on all my documents? I went to a rapid software testing course to find out…

I went on James Bach’s Rapid Software Testing (RST) course because some of the concepts and ideas that I had read about exploratory testing and RST appealed to me.   I liked the idea that central to testing is a critical and context-driven approach and I also wanted to put intelligence back into testing.

I was curious though, as on some blogs I read it appeared that exploratory testing and traditional testing were mutually exclusive. You are either a champion of traditional testing techniques and provided multiple test documents or you’re in the maverick camp which threw out all documentation and just ‘tested’.

I was relieved to learn that for rapid software testing, this is just not true. I was relieved because I LIKE DOCUMENTS.  I like them because in certain circumstances I find them helpful.

Because I have to confess, sometimes I forget to test parts of an application. Even worse, sometimes I don’t want to test the hard areas.  

A document gets me to test all areas and to test the parts that I really don’t want to test. It helps me remember the results of what I’ve tested because sometimes I need to know that information.

What James Bach reminded me, was that the ultimate goal of testing is very simple. It’s to test an application with intelligence and thoughtfulness. The goal is not to create endless documents on testing.  Instead, documents can sometimes be handy tools to assist you in testing.

I don’t think I will ever totally give up on my documents. They are my friends. However, I will make sure that in future, these friends can stand the test of relevance, accuracy and brevity. 

6 replies on “Is document a dirty word in Exploratory Testing?”

I have found when switching to exploratory testing that you still need documentation. What I personally find best is when you have the test case open as you go, and document what you have just done, as opposed to what you have to do.
After all results of exploratory testing still needs captured and recorded against requirements. Few customers are ever happy with “it’s tested, you just have to trust me that it is.”


I don’t think so. But the focus of Exploratory Testing is to explore the software application as if like an end user and see if there are any issues in that context.
The application must be intelligent enough to guide and navigate the user. Afterall most of the users won’t be going through the complete user manuals to work with them.


Thanks for your comment Venkat, though I believe that the context of what you’re testing is not just limited to the end user but depends on what your stakeholder’s are looking for.For example, the context of the testing may be its compliance to a standard etc.

I recently wrote an article on documentation, and as I was writing it I found that I do more documentation then I thought I did. As also realize that my current testing team does WAY more high-value documentation in the form of charters and session notes than I’ve seen at most companies I’ve worked at. My current team writes up a lot, but it’s all new information (very little opportunity for copy and paste) and it’s all focused on solving problems or creating opportunities for tester feedback.

Leave a Reply

Your email address will not be published. Required fields are marked *