Is document a dirty word in Exploratory Testing?

Is document a dirty word in Exploratory Testing?

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.