One down two to go!

And no, I will not link the King Diamond song here (even tho it’s cool). This blog post is about my experiences from the first (my second first day) at the Rapid Software Testing course by James Bach. I seem to be one of the lucky few who actually are able to have two goes at this amazing adventure to the deep dungeons of an exploratory testing mind.

Like I tweeted earlier, I fell into traps; the most obvious traps that can be set for a tester. I know I can do better so here’s a quick analysis on what happened and what could I have done better:

http://morningandotherstories.wordpress.com/2011/12/

Context: When I was confronted with a testing problem without a context, the first thing to do is to determine the context. Right? Here’s what I did: I thought I might sound too clever on asking and challenging, so I answered the question without determining the context. This lead into questioning my answer and making me realize that “we’re shooting live ammo here”. So I decided to sharpen up.

• I could have done what I (try to) do every time I’m facing a problem: Understand the context, the people involved, the background, the current status, the mission, etc; communicate with the client, stakeholders, testers, etc. That could have brought the whole problem into a new light. I fell into a clever-trap. 

Pattern and mental models: I had the advantage/disadvantage to see the formula for a pattern beforehand. The task was to determine what the pattern was. Those that have taken the RST course will remember this, right? I remember the point of this exercise being to break the assumption and to focus and defocus. Again, my previous knowledge bias struck in: I completely ignored testing the product and did some of the procedures I had seen done in previous classes. The pattern was the same, however, so basically I didn't lose anything…

• …EXCEPT FOR EXPERIENCE! I could have spent the time testing in ways I had not tested before. Now I had the time to do something different. Instead I tried to look good by using Excel (like James Whitaker, I think) and I made a simple script to produce test data. I didn't even bother to check the logs, as I had checked them numerous times before. Should they have changed the behavior even a bit, I wouldn't have been able to identify the pattern. I fell into a showman-trap.

http://members.multimania.co.uk/mrmal13/saints/amardas.htm

Documenting: The task was simple: Write tests and justify all of them. James specifically asked everybody whether they had made a justification for ALL the test they were going to run. An exploratory tester documenting test cases and justifying them all with specific, detailed texts? Can you picture that? I could hear myself saying within my head “Yes, James” without even questioning my so obvious bias. I tried to be a good boy and wrote them cases and then feel pride.

• The exercise was about justifying the testing but in a different way. My doing inexpensive testing and discovering something worth discovering, one can justify a more expensive testing. Like James said: “The cheap tests pave the way for the more expensive ones. They are the scouts that look for a good spot to place the artillery.” That comment alone is worth its own blog post. But instead of being inquisitive, exploratory tester, I became a test designer that is going to get fired. I fell to the guru-awe-trap.

So my first day was a success: more learning than I hoped for. I also thought that I had some form of advantage of knowing the stuff from previous, but it seems that I had misunderstood (or belittled) some basic principles of Rapid Testing. I felt some of the stuff explained more comprehensively, with sidetracks to bulk up the areas where I thought the content was thin (namely the modeling and project elements of Rapid Testing). I do wish James would have covered the modeling heuristics with more depth, but I will leave room for other areas for the next two days.

What I’m looking forward is the process of Rapid Testing itself. I somehow missed a whole lot on that subject when Michael Bolton was teaching the course. Also to hear more about the oracles would be nice. We scratched the surface today but we’re still to cover some of the mnemonics that I frequently use, like CIDTESTD, HICCUPPS, etc., but it was nice to see an update to SFDPOT with the Interface addition. I will be using that when I reinvigorate the workshop in near future.

The importance of the context

So as I’m heading home, I will share this one particularly funny event that happened in the beginning of the class. Here’s the story without context:

James Bach spit on Aleksis Tulonen.

If you add context, here’s what really happened: Some poor fellow was getting given the “Socrates treatment” by James and he had an act prepared for the response the guy was going to give. He asked a question and set a trap onto that question. He knew the answer would be something “horrifying”. So he took a sip of water after asking the question. When the poor fellow answered James theatrically spit the water from his mouth as if being so stupefied by the answer that he just couldn't bare it. Unfortunately the aim of the jet of water was a bit off. Aleksis, who happened to sit in the front row next to me, was a victim of the poor aim. Aleksis’ phone and computer got some droplets on them as collateral victim of this splendid act. Hopefully tomorrow’s newspaper doesn't have a title “A testing consultant got spit on by a guru”.