April 30, 2007 12:52 am

Exploratory Testing and documentation…

Talking about Exploratory testing and the project management [link] a few weeks ago, Pradeep from Bangalore, had shared a fable about TestTrimming or shortcuts. It is a good story of what it takes to bake a cake and how shortcuts would not provide a quality outcome.

From the fable’s example, it is agreed that the 3hrs of effort is what it takes to bake a cake and no shortcuts. However, 3hrs is an estimate that was given by the baker and he/she knows it takes taht time to complete. So, back to my ad-hoc testing – considering we have provided a similar estimate and what I referred in previous paragraph as Mar 15 – what is the level of confidence to say, I can be done by then. OR, does it mean, I won’t know about it until I am done. This is something I heard from someone working on SCRUM project model.

I have also come across few articles [link1][link2] while learning about the technique / approach for ET, and i have noted that the documentation or heuristics can be used along with FTT (Features to be Tested) docs to learn about the product. I also remember reading on Satisfice or somewhere else that the last few minutes of the ET session should be kept for reporting the bugs / issues etc. I was having a similar conversation with someone recently. So our conversation was, though having the reference materials like mentioned before, how about keeping a log for what was exactly tested or at least the scenarios touched upon during the session. We had mixed thoughts, given the time constraints for the project, on

whether to be documented on those or not

if documented, then to what extent? I understand it is relative comparison. so my answer was, we need to document at a higher level to an extent of the scenarios touched upon, for others to understand the areas touched, helpful pointers as appropriate etc. And it doesn’t have to be detailed to include the sample data, outcome of that data (in case the software resulted as expected) [again “as expected” could be like from a spec]

why document that – because it ad-hoc and the bugs/issues will be reported anyway. –> it probably makes sense, but I probably have to disagree with this and I think it is always better to have some sort of documentation, even if it is a one liner as mentioned in #2 above – i understand there are chances of ambiguities if we start documenting things. Well again, we need to draw a line somewhere. I have also noticed a blog post by Pradeep on mixing Scripted and ET. This is another resource with good examples listed.

It looks like I am wandering around these thoughts on ET, agile, TDD, etc etc as I think about Agile project management.