Since many of my colleagues are non-swedish speakers I have decided to write in English from now on. Last week I went to Tallinn to give a class in Test design. I was invited by KnowIT, one of my business partners in Sweden as well. They arranged a class together with Webmedia - the largest IT-company in Estonia. In spite of business beeing somewhat slow there were nine people in the class.
All of them were young men with good experience and eagerness to learn so the class was really fun to teach. I think that Estonia is a good choice for outsourcing, they speak good English and Tallinn is only 45 minutes from Stockholm by plane. If you are interested in outsourcing to Estonia contact Kaspar.Loog at knowit.ee
Kaspar and Per took me to a nice Russian restaurant in the old town were we had blini and vodka for starter and a stew for main course. The stew was made in a clay pot with dough in top as a lid. It looked like a giant mushroom and was very tasty. 
A colleague of mine, David Barnholdt, who is boiling with creativity, created an exercise the other day. The goal was to explain the effects of having to much detail in requirements. I follow along the same lines and think the same applies to test cases. For SOME tests there may be a reason to have a lot of detail in the test specification but for MANY other tests detail can be counter productive. The main reason for this is that lots of details means that the creatvity of the tester will be choked and the performance of tha testers executing tests will be inefficient. Following a detailed script will often result in a worse performance than having a more open ended description. This is exactly what James Bach and Michael Bolton and many others have tried to explain for many years.
I found David´s exercise very interesting and decided to copy it. This means that we can also compare results.
I divided the class in two groups (consisting of 4 people each) and told them that they in this exercise would do a drawing , following a requirement I would hand out. The would only have one minute to complete the drawing. I provided them with a number pencils in red, green and blue and one big piece of paper each. Then I handed out one paper with the requirements to each group and started a visible timer counting down 60 seconds. (I searched for timer on the web and shoed it via the projector)
One of the groups got the following requirement:
Draw a beutiful summer meadow with blue and red flowers in green grass, some cows and birds under a shining sun.
The other group got the following requirement:
Draw a beutiful summer meadow with
- 10 blue flowers with 5 petals each
- 5 blue flowers with 6 petals each
- 13 red flowers with 6 petals each
- 2 cows with 3 black spots
- 1 cow with 5 black spots
- 2 cows with 4 black spots
- 2 birds to reside in the upper left corner
- 3 birds in the middle
- one sun to the right with 5 sun beams
Here are the results from the exercise.
So the leftmost drawing, made by the group given the detailed requrement, had a lot of details but lacked the coherence of the right drawing - made by the group given a more open ended requirement. I feel the exact same thing happens when testers get too detailed test cases. They follow them in detail but miss the big picture. We had a discussion in class on how detailed requirements and test cases should be and I think that all participants will think twice befire creating highly detailed scripts in the future. We of course agreed that there MAY be situations where we want to have a lot of detail but that is OK as long as we realise the consequences. So thanks again David for creating this great exercise!
Well , it is Saturday night so I am going to be a bit social...