Robert C. Martin brought up a blog entry yesterday called The Polyglot Tester. He argues about the Behavior-driven development style of automated tests the table style encouraged from FIT, Slim, RobotFramework and others. While I’m not going to jump into the discussion which of the existing tools is better, worse or more suitable to do some job, here are some references to patterns for test automation, which I came across.

Nearly everything in software involves some humans doing the job. Today I got a phone call:

Caller: Do you have some resources for me?
Me: Sorry, I don’t have resources for you here. Just people.

Reflecting back on my university years it’s interesting to notice, that we teach computers to learn just like humans, in order to replace humans by computers. But, while we’re doing so, we treat people like things. In addition most of the time people in the software get treated as resources, who can be sent to some course, get a degree or a certification, come back and know everything – inwards and outwards. Sure, this is how it works, of course. Maybe they will be inventing some injections in the near future. Then people – sorry – resources can be as productive all the time without the need to send them to trainings. Now THAT would be an improvement.

This is not how it’s going to work. Let me try to transport this concept to teaching swimming – one of my leisure activities I need in order to gain work-life balance. When setting up a swimming course like most of the projects I’ve been in to, this would look somehow like the following. In Germany the first certification is the “Seepferdchen” (tiny seahorse). By the time the kids know one to two techniques, are able to swim 25 meters (we use metrics here!) continuously and can jump from the edge of the pool right into the water. They can dive and fetch some rings from 1.2 meters depth (metrics!). That’s it.

Now, this is the basic certification a swimming student needs. By then he has the knowledge how to swim through the pool. Ok, let’s put her on a project – a swimming contest. She made her grade with an A, so we better have her sent to the national swimming competition. Of course she knows how to train for the event. Ready, steady go…. What do you think will happen?

Right, when battling the 100 meters against Michael Phelps or Alexander Poppov or Mark Spitz your kid will drown. Why? Because it lacks practice. It does not know how to swim properly with the resistance from the water. The experience of the water pressure is known to her, but not how to use it for her advantage. In addition the muscles has not been built properly to beat with world class swimmers like the ones I mentioned.

There is a pattern we observe each holiday season. Parents sent their kids to our swimming course, because they are going for two weeks to the sea and the kids need to be able to swim by then. Of course, six weeks are enough for anyone to learn to swim. After telling the parents that we have a waiting list for new kids, they take it disappointed to have to wait for a free place. In the end when the kid gets their certification (remember the seahorse), they take the kid with them for their holidays. Why is this dangerous? The kid has just practiced in a safe environment without waves and without streams. The kid knows how to hold their face above the water for some time, but without having the right condition to do it over time when the waves take them out far to the sea. Basically all that certification says, that the kid is able to do basic swimming without saying anything about the abilities.

I hope I raised the point for practicing far enough by now. In order to survive the waves of the software development projects to come, you need to practice your abilities. You need to train and have your programming and testing muscles being built up right in shape in order to survive the streams of the tar pit (see Brooks’ The Mythical Man Month) of software development projects.

But keep in mind that there is no pattern or schedule for people learning. In fact some kids take more than a year to learn enough to get the seahorse certification, others may be able to do the practices for it in just ten weeks. There is no way to have them scheduled on a certain date, because each kid has their own pre-requisite of moving behavior and familarity with water. Compare two kids. The first one has taken baby-swimming courses right after birth and is very comfortable with the element. The other one has nearly survived a fall into the local pond at age of three. The first one is likely to take a shorter period of time for learning how to swim. The second is more likely to have fears against the element that need to be removed before the kid can get trained on the techniques. So, it’s likely to take a longer period. My considerations are not guarantee, though. (On another note I would be happy if I got told about certain fears before starting to work with the kids sometimes.)

I hope it’s obvious to see the similarity to people learning how to test software or how to develop software. People differ in learning styles and learning speeds, but people learn. The difference is to get the hook on the past experiences of the people good enough for them to take the step beyond that gap to the new models you’re providing. Therefore a good learning approach is to settle for multiple models of your teachings in order to get as many people as possible and make them able to refer to your model as well.

As a swimming trainer I was taught that I reach some of my students with some exercises, some of my students with some tactile impulses while some others need to be taught the model by showing them my movements. Keeping in mind that “correct” is an interpretation from some human, I don’t think there is one and only one correct path to teach anyone anything. People vary in their ways of getting the hook on something.

That said I don’t believe in the single solution of a training model. I believe that we need multiple ways in our toolset to teach people what we’re actually doing. People perceive some of the lessons we teach them by one or more of the following:

• formal training classes
• reading a book
• failure on the job
• failure in some save environment like a training session
• watching an experienced professional doing some work
• (positive) on-the-job experience

Though we don’t make much use of tactile experiences in the software world as I may need as a swimming trainer, there are multiple facets of learning. Based on cultural aspects and diverse background from people there is multiple responsiveness to certain aspect on software development education. This also holds from my perspective for software testers – and I believe for nearly all jobs.

Over the course of this year I got to learn about Coding Dojos. The arrangement there is to have people from the audience brought in to some time-boxed hands-on experience in a save environment. The second aspect is watching two experienced developers developing code. This arrangement sets up people for various learning facets. The more ways we try to set up the learning, the broader our learning audience will be.

The interesting part here is that people can gain experience while they are work. They can be taught what they may need tomorrow. Since the learning is based on a broad set of tools enabling learning, we make sure to include more people – more people that may need more diverse techniques for learning. The concept behind Coding Dojos is very impressive, and it works.

The question that struck me nearly all year is, “May we use this idea also for training testers?” For quite some time I knew there is some way, but I didn’t know my model about. Then something happened that made it very clear for me. More on this in the next blog entry in this series on learning and education.