Anna Baik took my recent blog posts and made a reflection on her swimming lessons in a blog post. In short, she stated that up until the age of 11 years she was not taught how to swim properly. Though her teacher insisted on some exam, she wasn’t able to take the test. In the end she did not learn swimming at school, but much later decided to learn how to swim with some advice from a friend. In retrospection I am going to introduce three different models for learning and education and discuss them in some depth.

Thrown into cold waters

This story reminded me on two things. First, my father used to tell on how he learned to swim. Back in the 1950s, 1960s he went to the outdoor swimming pool. In order to get taught how to swim, the bath attendant threw the kids into the water in order for them to learn how to swim. So, this is a the case for the drowning model of education. The same exists(ed) for teaching software testing. I remember four years ago I had just finished my German diploma. Thus far I did not have any experience with regards to software testing. There were some university lectures that scratched the topic, but those are uninteresting when you’re studying. So, I got my first position as a software tester and got little introduction. Most of the background I learned from interactions with colleagues and in home lecture sessions when conducting some books for self education. Personally I would like to call this model the “throw the newbee in the cold water” model, since it’s just what most new software testers seem to get. Little supervision, little guidance, but maximum output.

Excessive exercise

In the second model that I will introduce, there is some guidance given. Let me introduce it by a tale I heard from a senior swimming colleague. She stated in one of the trainer courses that she got taught how to swim well and fast by massive exercising. The trainer told the kids to swim 100 times 100 meters, day-in, day-out. This is the style of trainership that got known as counting tilings (I hope I got the translation right, German: “Kacheln zählen”). When you run these stupid training lessons over and over, the kids may get demotivated for seeing every time the same patterns. There is no variation, and it should be obvious that swimming those 10 kilometers will get rather boring.

In software testing the situation of boring test plan executed training sessions is comparable. By simply telling people what to do in such a great detail that they will stop to think about the task at hand in a wider scope, highly educated people will get demotivated and maybe counter-productive. As Mary Poppendieck pointed out

Telling highly educated people what to do is a problem.

Her phrase holds for software development as well as for software testing. If you don’t understand this, then please think again on your situation. When was the last time someone told you what to do? How did you feel about it? Which conclusion did you make in regard for the job you were doing? Do you want to work in such a situation for a longer period of time?

Excessive exercise may work in some situations, but over time it seems to degenerate people working in these environments leaving them to leave as long as they’re smart enough to do so.

Variation

In the late 1990s there was a sport professor called Gunter Frank who worked with the kids in a different manner. He taught the kids to swim in manifold manners. He taught them how to swim and even how not to swim, combining several techniques to new techniques, etc. etc. His claim was to teach the kids before they got into puberty as many movement patterns as possible. When the kids entered puberty, they could more easily adapt to the changed proportions of their body. This school of thought was radically different to the remaining models, and it seemed to have work.

Transporting this model to software testing it’s the tool-set building mentality. A good software tester has a rich set of tools in his belt. He has used every single one of his tools in his belt several times. So he’s familiar with the benefits as well as the drawbacks on each particular technique that he knows about. Thus knows when to use which technique for the good of the project. But in order to learn a rich enough variation of techniques, you need several preconditions. First of all, you need a safe environment to try the techniques out. You need to make up your mind by reflecting over the course of the application of the particular technique you used. And you need the commitment to adapt to the situation with a yet new technique and let go of the one you just tried out. Of course, this needs experience and this needs failures from time to time. The richer the variation in your tool-belt, the richer the tackling of your software testing.

Pick your favorite

Now, as I have discussed (yet again) three models for learning new things, you may want to reflect in which of the three proposed environments you may want to learn new things. Simply have yourself thrown into the cold water and find out yourself how to survive, or just attend excessive training sessions and learn by doing lots of testing repeatedly, or by learning a rich variation of techniques in a safe environment (i.e. before getting into puberty), so you can adapt when the situation asks for it.

Oh, and a final note, I’d be delighted to here about new models for learning environments and set-ups of learning sessions, so I can add them to my variation repository. So, if you think there are more than the three or a combination of two of them might yield a better set-up, please let me know in the comments. I’m eager to learn something new these days.