Comment:     by Charles Harper 8/5/2009 I am a latecomer to this discussion but a fanatic of Mr. Bach's SFDPO approach. It is a helpful guide while writing a test plan at the beginning of a project but also while doing a particular test case, as it reminds me of all the possible explorations I can make within the bounds of the particular test case. Speaking of "exploring", I am a bit confused by the relative weight Mr. Bach gives to a structured approach such as SFDPO versus exploratory testing. I was reading a blog entry today - http://blog.testlabs.com/2009/08/will-hosts-of-heaven-and-earth-pause.html - which seemed to denigrate the Exploratory testing approach.Read On Author's Response: 8/5/2009     I don't consider the authors you cited to be an expert on any aspect of testing, frankly, and they certainly do not understand what I do for a living. Some of the people who criticize my ideas actually propose fresh ideas of their own. I may criticize such people, but I have to respect them for trying to create something. But there are other people in this industry who rather than contributing merely comment without insight on the hard work and experimenting that others do. I think you encountered some of those. If you look at where he supposedly called me to task for claiming to have invented testing, you'll see that in the blog post in question, what I actually claimed to have done is "reinvented testing for myself." This is the equivalent of a car mechanic who takes apart a car and puts it together again, in the process learning how cars work and getting ideas about how to make better cars. It's hardly a controversial claim. In fact, I recommend that everyone reinvent testing for themselves. It's excellent education. As for your question, exploratory testing is not unstructured testing. There is almost no such thing as unstructured testing, actually. Show me something that is "unstructured" and I'll show you its structure! The question is what kinds of structure guide and inform testing. Guideword heuristics are particularly useful devices for guiding exploratory testing. Bear in mind that nearly all testing is exploratory to some degree. Don't fall into the trap of thinking that only undocumented, unplanned, spontaneous testing is "exploratory", any more than "exploring Rome" would mean not using a map and not having any sort of schedule or itinerary to work with. Yes, you can explore Rome with none of those things, but you can also explore it WITH those things.
	Comment:     by Tom Carroway 5/16/2001 Mr. Bach's comments and suggestions / ideas are a great framework to approach testing of a technical system, however, and my bias may be apparent here, depending on the application and type of system being tested, I would also suggest that Chris DiNardo is onto something else - you can always start by going back and reading through the requirements, and looking for use cases. A very practical way to minimize the possibility that you've just thoroughly tested a very technical solution and found it to meet 100% of the requirements technically, but that you may have not tested the system in scenarios or ways that will mimic or recreate how the...Read On
	Comment:     by James Bach 5/15/2001 Oh Yogita. Now I'm all self-conscious. I won't be able to write another column until I invent something totally new like psychic aura-based test coverage. The pressure to innovate in 750 words is too much to bear! Actually, I kinda thought that what I wrote is new, in the sense that I meet almost nobody who makes a determined used of mnemonics as test design aids. I have others: CRUPIC STMPL, CITBEPSTD, and HICCUPP (I didn't say I was *good* at making up mnemonics, but they work for me). Altogether, I find that by using these, I can think of more tests off the top of my head than anyone I know (except Cem Kaner) has the time or patience...Read On
	Comment:     by Chris DeNardis 5/14/2001 Good ideas to follow here. I believe many of us testers/ test managers have ideas similar to these, but not as organized as it is presented here. Some other ones that were not so touched on, and are at the root of testing are Requirements, and Background. Requirements probably could fall into the Funcationality section, but without those it becomes one developers idea to another, without a common ground. Background, if a tester is more experienced in the area under test, they are more likely to find items than a test who is a novice. That is why we as test managers need to be aware of our testers so as to provide them with enough...Read On
	Comment:     by yogita sahoo 5/14/2001 I must admit that the article was not very interesting, atleast for those who have read Mr. Bach's previous articles on Exploratory Testing. They were just the right kinds, one looks for on Stickyminds.At first I was very glad to see Mr. Bach's name for this week's column and was quite hopeful that I will read something substantial about ET. The article, no doubt, gives more tips to organize ET.But these tips are very common and don't talk about anything new. And we all know the author for his abilities to give meaning to un-conventional ideas (e.g. exploratory testing).With Mr.Bach,I've always associated something new. Though I still remain...Read On

Back to Top