Mission:
Test the regression test calculator for any flaws you can find. You might gain bonus points, if you can find out how the calculation is done. Another set of bonus points if you can come up with a better approach.

At the beginning of November I attended a conference together with my boss Henning Wolf. While flying back to Hamburg, waiting for our plane, we talked about things, and I mentioned some lessons from a book that I was reading at that time. “Say, how many books do you read within a year?” he asked. I couldn’t answer that question directly, as keeping in mind that this was my seventeenth book would distract me from reading the content. So, I looked it up, and was amazed.

I am sure, I do not exceed the number of books that for example Michael Larsen read this year, but I was still amazed about the number – having estimated it at about ten or twelve. I decided to visit back the books I read, and see which lessons stayed current even after having read them. This list is based upon my notes over at Library Thing, where I looked up which books I finished this year. Some of them I started back in 2010. Some of them are also in German. some have an English translation, others don’t. Maybe time learning some German for some of my readers. :)

At the recent meeting of Hamburg’s Softwerkskammer – the German Software Craftsmanship movement – we worked through a Coding Dojo on the Roman Numeral Kata. Michael Norton wrote today about one piece that worried me as well. I think Michael did a fantastic job on tackling a different approach. But he reminded me that I wanted to put up some of the thoughts from the Coding Dojo.

We had about 12 participants in the dojo. After explaining some pieces about the format and the kata, we started the dojo. As the kata started, we had one participant asking questions up to the degree that the pair in front of the keyboard stopped doing anything.

Eventually we got the team back up to continue working on the problem. The claim of the interrupter was that we didn’t yet understand the problem well enough to design the solution. Another claim was that TDD was not a design technique. Let’s take a closer look at both of these.

This is the fourth part of a series of blog entries on a gift I got from Matt Heusser. Today, I’m heading for multiplayer games with our 11 year-old who has just same basic knowledge about English words.

A while back I received a gift from Matt Heusser, my early mentor in the Miagi-Do school. It asked me to test it. So, I decided to make a series of blog entries over the holidays out of it. Today we will start with the most obvious thing: unpacking.

In the past week Ulrich Freyer-Hirtz on the Agile Testing mailing list asked about different testing levels in an Agile project. He found the definition of unit, component, and acceptance tests appropriate based on several books. This discussion reminded me about the ambiguity that we face today in terms of testing. There have been several renaming attempts in the past few years. For example Dale Emery refers to a blog entry from 2004. Gojko Adzic made a similar renaming attempt. Let’s take a step back, and see what all those names really want to tell us. Afterwards we will be able to make a more informed decision about names.

I received quite some feedback on my last blog entry on certification. One of the feedbacks made me wonder what an alternative to certification is. This question struck me hard enough to write a follow-up on that. I think this question can be answered solely in a certain context. I’ll try to answer it under several contexts, one by one.