The winner takes it all (a 3-day workshop with Cem Kaner)

Last August I received a mail from a company called Immune-IT that promoted their upcoming “Cem Kaner week“. The concept: during the last week of october Cem Kaner would visit The Netherlands to lead a three day workshop and give a freely accessible presentation as well. Considering the cost of the workshop I settled for the free presentation, which I figured was also quite unique. Nieuwegein in The Netherlands is only a 160 km drive from my home (ok, you’d have to get past Antwerp, Breda and the Utrecht traffic jams, but still: worth the hassle). Later I heard that there was also a possibility to get a free workshop place by entering a contest on their website. Long story short: I participated, won the contest, checked the mail again (still said I won it) and jumped from joy. On October 26, I had a date with testing history.

I have always looked up to Cem Kaner, admired him for being one of the pioneers in the software testing field. He is a professor of computer sciences at Florida Institute of Technology and the (co-)author of truly great books like “Testing Computer Software” (alledgedly the best selling software testing book of all time) and “Lessons learned in Software Testing” (which inspired and influenced me big time). He founded the “context-driven school of software testing” (I’m on their side) and has all these excellent free courses available online for Black Box Software Testing. All this was rushing through my head while cruising through the lowlands. Later on, traffic came to a standstill, and this gave me even more time to get my imagination running… What if I don’t like him? What if he turns out to be a belligerent ghoul (gratuitous “The Smiths“-reference)? Well, none of all that. Cem is a nice person, almost humble in his ways. I like him. A friendly, human encyclopedia of black box software testing.

The size of the workshop was pretty small – only 12 people enrolled, which made it super-interactive. Immune IT had asked Cem to talk specifically about testing in difficult economic times. He did talk about that, briefly, but luckily he covered a whole range of other things as well. Some highlights:

• Exploratory checklists and a truly hilarious piece of scientific proof that following scripts is a best practise (yes, you heard it right, in some cases there *are* best practises) for brain-damaged rats. In 1977, Cem incidentally stumbled upon proof that normal lab rats use ‘checklists’ to drive their behaviour, while brain-damaged ones resort to following the same script over and over, no matter the context. More on this can be found here.
• Scripting and learning. Cem debunked some common myths surrounding scripted tests.
  #1. “Test scripts are ideal as ‘training wheels’ for new testers. After several months of following a wide range of scripts, the new tester will have learned by example a lot about the application domain, the program and how to test it”. So they say. But have you ever noticed what happens when you drive to a new place with a GPS that gives you a script like “Turn left at the next lights etc…?”. If you try to go there again, do you actually remember the route? You learn faster when exploring and discovering, rather than by ‘being told’.
  #2. “Test scripts specify all initial entry conditions”. But you cannot capture everything, there are so many variables that it becomes impossible (system state, program state, system config, system resources, other processes) to describe this upfront.
  #3.  “Test scripts specify the expected results”. But – same as above – scripts cannot specify all possible outcomes. There are simply too many variables involved. Our tests cannot address all possibilities.
  #4.  “Test scripts involve a comparison that machines or humans should make”. But what about confirmation bias? Or inattentional blindness? We ignore things based on their meaning, before we ever become aware of them.

• An extensive part about exploratory testing from the godfather himself, it doesn’t get any better than that. He explained the renewed definition of exploratory testing (which I endorse but find a bit too long – I liked the old one better).  *taking a big breath* here goes:

Exploratory Software Testing:
– is a style of software testing
– that emphasizes the personal freedom and responsibility
– of the individual tester
– to continually optimize the value of her work
– by treating
     * test-related learning,
     * test design,
     * test execution, and
     * test result interpretation
– as mutually supportive activities
– that run in parallel throughout the project

• An intriguing part on testing an investment modeling tool called VectorVest.
   
• “Exploratory Test Automation”. Slides available here. I specifically liked his experiences at a phone manufacturing company called Telenova.  They were able to track down a stack overflow bug in one of their telephone sets that had been undetected even though testing achieved 100% statement and branch coverage in the relevant parts of the code. In the field, this would require a long sequence of calls to a continuously-active phone. They succeeded in isolating it through “Exploratory Test Automation”: they created a simulator that generated long chains of random events, emulating input to the system’s 100 phones. That eventually exposed the bug (and several others as well).
• Cem is obviously not a great fan of automated tests, but he makes an exception for “Exploratory Test Automation” , “High-volume Test Automation” and “Extended Random Regression Testing”. Traditional test techniques tie us to a small number of tests. Extended random regression and long simulations exposes bugs the traditional techniques probably won’t find.

These three days were a real treat. I was able to talk and discuss with Cem Kaner personally – and learn from him, which was priceless.  I also met some other great people – passionate about testing and always prepared for an healthy argument. At the end Cem signed the copies of “Lessons learned in software testing” that we all got for free, which means I now got two of them. One to use and one to cherish.