As Ben suggests, it might be helpful to your readers to provide some insight into the contexts in which you’ve experienced and practiced exploratory testing.

You might be interested in a couple of blog posts intended to clear up some misunderstandings about exploratory testing, and that suggest how to do it in a more responsible way.

http://www.developsense.com/blog/2010/03/coding-qa-podcast-on-exploratory-testing/

http://www.developsense.com/blog/2010/04/coding-qa-podcast-on-exploratory-testing-part-2/

In my own experience as a tester in commercial software, big retail, financial services, both Agile and not, I’ve never heard “We do not need test scenarios, unit tests, test automation, etc.! We have skilled testers!” More often I hear the opposite. “We have test scenarios, unit tests, and test automation” and “We don’t need skilled testers”. The trouble with this, of course, is that creating truly excellent test scenarios requires both skill and exploration; to create really great unit tests requires the critical thinking skill that is central to excellent testing; that TDD is an exploratory approach to software development; that test automation without testing skill is blind to problems that people will have; and that test automation is incapable of learning. The people who do test automation are capable of learning, of course; and learning is both essential to and a product of excellent testing work.

To me, exploratory testing is like an interview (http://www.developsense.com/blog/2010/04/exploratory-testing-and-interviews/) or a conversation. I hope that you feel included in the conversation, and that you continue to engage us.

—Michael B.

A couple of questions. First, you point me to the E.T. Manifesto? If someone has come out with one, I’d be interested in reading it. I’ve catalogued and produced a bunch of writing on exploratory testing (the catalog is here, but I’ve never seen a Manifesto. Perhaps you’re thinking of something else that might be interesting or valuable.

More significantly, could you help me understand what you think of as a “thug”?

Just to be clear, I do have my own notions of what a thug might be. For example, a thug could be “someone who throws unsupportable claims from behind a mask of anonymity”.

—Michael B. (brave enough to sign)

It’s sad, but your post is spot on, it’s a philosophy, and you tried to outline the good and the bad and you were attacked and then accused of being a troll – in which you defended your remarks.

sad

I’ve updated the post with a little explanation at the start.

Thanks for active keeping hand on the pulse

You have given us no indication as to what your experience of ET is or how you’ve used it, we simply see a number of things that you assert based on what that experience is. You haven’t juxtaposed that with the experience of other testers, so what you have are conclusions drawn from an undescribed experiment with a sample size of one.

Where you say it frightens you to treat ET as the only approach – do you have experience with someone advocating ET describing it as the only way? I do not.

If you want to have a discussion about your experiences with ET, I suggest that in future you present your material as exactly that. I would also suggest that you compare your experiences with experienced advocates of ET to see where your experience differs, so at the very least you can say ‘this person says X. In my experience I have seen Y’.

I didn’t comment here for the sake of having a discussion. I commented in order to correct what I see as misinformation about exploratory testing.

There is already enough online garbage to wade through when learn about testing. Please strive to be a voice of reason, learning and teaching. This piece is not that.

Well, we have lift off that a substantive discussion :)

First: Usability is not a ET goal ! My experience shows that many errors reported during these tests is related to usability. ET helps us to improve usability but somehow in the second thread :)

Second: Lack of docs and temporary salvation :) I have several accidents when I had to do some kind of fast checking third party component or application and I that case ET was a salvation. When the docs and reqs are not clear or not complete, testers can not check whether current solution have issues, idea is wrong or documentation is not complete. Again, that are my experiences :)

Third: “We do not need test scenarios…” – I see that I was not understood :) This sentence have false assumptions, who say it do not understand the role of ET or use only those tests and do not know about others!

In conclusion, I would say that the thesis contained in this post are theses which were to trigger a discussion. I am a fan of ET but it frightens me to treat them as a sufficient or only approach. There are many misunderstandings in this area. The good and bad sides mentioned here are no objections to a methodology or technique, talk about perception of ET in different way (not right way).

Many thanks for the comment. Writing this post I hope to start a little discussion.

You have right that ET itself is not a methodology, but many quality departments are based on it as a whole. They build some kind of methodology on ET concept.

ET alone is not enough ! When you need, in example tool to automate the tests, you download 10 items then you run ET on each of them. We do ET all the time and, in my opinion, it is sufficient for 0 step checking.

Of course you’re right, badly run ET may lead to tester routine. I wrote this post to prepare readers for such events :)