Clear Checks

Over the last two days I took the opportunity of silence at work to be able to work focused. Since I’m currently reading Growing Object-Oriented Software, Guided by Tests from Steve Freeman and Nat Pryce I tried out their approach while retrofitting some unit tests to some of my test classes.

It took me between one and two hours after lunch to get the first class under test. Implement a unit test, bring in the necessary support code, run the test, make it pass after dealing with some stupidities on my own, then go on. In the end when I felt I was done and couldn’t think of yet another test (I also had checks for exceptions in place by that time), I started a code coverage build to see, which passages of the code I was missing. I got surprised to see that all the tests passed and I had brought in 100% code coverage. 100% line coverage, 100% branch coverage, there wasn’t anything left for the unit testing on that class. Since we also used the class for quite a while I knew it was functioning in our test harness, so I was done with it. I checked in the new unit test and drove home happily. That feeling of pride after polishing up your Technical Debt was a great moment. It felt (and still feels) great.

One thing actually stroke me: My tests were very clear and readable. I was tempted to show them everyone. Since the offices are rather empty during this time of the year, there was no one I could annoy with my pride. I got reminded on Enrique Comba-Riepenhausen on the Software Craftsmanship conference in London in February. He stated during Adewale Oshineyes session, that his customer were on-site to the degree, that they were able to actually read the production code. I felt that I had just a piece of code that my customer would be able to read. (I don’t think so, in retrospection.)

The essence of writing maintainable automated checks lies in writing them clear. Indeed, you should write your test code more clearly than your production code to keep them vital and in shape to serve you during your further development efforts. Unfortunately, teams underestimate the value their test automation brings them when written and maintained properly. There is not much magic about it. But you better take care for your test automation code, or you’ll get trapped in the automation pitfall.

Educational models in historic retrospection

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.
Continue reading Educational models in historic retrospection

Where is your context?

Just finished reading through the rumble of the year between Matt Heusser and Alan Page on code metrics. Marlena Compton seems to have facilitated the session very well, since I haven’t heard of any casualties. One striking phrase from Alan Page led me to this blog entry:

In my world, code coverage measurement is another tool in the testers toolbox. We use different “tools” depending on what we’re investigating and where we want to guide our discovery process. We always need to use the right tool in the right context.

Thus far I haven’t thought consciously about context. Alan in the above mentioned quotation made me realize that there are multiple contexts to apply context to.

Continue reading Where is your context?

So…what tester are you?

A while ago Rob Lambert wrote down a list of tester types. The Software Testing Club has now published the tester types as an eBook for free. Make sure to get your copy of it. In the case you’re asking me what type of tester I am, I think I am a mix-up of the Automator, the Expert, the Intellectual, the Boss and the Drafter. I hope I made you curious what this means, so better check out the tester types. Thank you Rob and Rosie for sharing these with us.

Patterns for Test Automation

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.

Continue reading Patterns for Test Automation

People Learning

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.

Multiple facets

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.

On Education

Last Friday I visited my old university where I studied up until just four years from now. The place where I learned how to learn. It was amazing how little changed beside the fact that students nowadays get charged a whole lot more money for their education. In Germany currently there is a rough discussion about these fees and that the universities do not take care for the educational side properly. The graduation celebration I visited last Friday was accompanied with a talk from a previous mentor of mine. He had some data on how education had changed over the last decade and made a comparison between the old Diplom courses and the new Bachelor and Master system. Reflecting over the past years and that talk, I came to the realization that there seems to be a gap in our industry currently.

What did I see or hear that leads me to this conclusion? Reflecting back four years from now I knew nothing about software testing. Over the last years of my study I concentrated on pattern recognition, like face-detection in images, and my diploma thesis handled about hand gesture detection in human-robot interaction scenarios. Back in April 2006 I joined a team of great testers and needed to learn software testing. Thus far I had not participated in a course on software testing. The team I was working in was doing a whole bunch of software test automation using shell-scripts. Over the course of the next few years I did learn how to teach myself what software testing is about. I learned that software test automation is software development, I learned that exploratory and sapient tests are very worth the effort, when accompanied with the right organizational methods, and I learned a whole bunch about Craftsmanship and Cooperative learning sessions.

In general I would conclude that I learned almost eighty percent of the stuff I need on a daily basis right after leaving the university, while the material I learned in university is not that relevant for me any more. As a software tester I don’t need to know how a wrenches for robot hand motorics work, since I don’t need them. Multi-layer perceptrons are not an option for me. Learning algorithms like AdaBoost and online and offline algorithms are not needed in order to test software. Well, I wouldn’t claim that the rough six years I spend at the university were wasted, but I feel that I dd not learn the right things there.

Recently I noticed that there seem to be others who feel just like me. The Software Craftsmanship conducts coding dojos and programming katas to teach the apprentices what the universities are not teaching them. Design Principles like SOLID and Design Patterns are taught on a on-the-job training between Journeyman and Apprentices. For software testers there are similar things happening, i.e. James Bach and Michael Bolton created a Rapid Software Testing class, Cem Kaner has also great courses. Yet, besides Cem Kaner and other distinct persons we do not seem to have reached the universities with our efforts. When I took a course named “Software Praktikum” back in the year 2000, people were talking about test-driven development and that new movement called eXtreme Programming, but no one really taught us something about it.

When I took a look on the course material nowadays I found out that the situation had been improved over the last few years. Nowadays students get offered test-driven development courses, some Design Patterns and maybe some Refactoring. Unfortunately I did not run across a testing course at my university.

Therefore I concluded that I would like to do something on this as part of a New Year’s resolution. Personally I want to help people understand software testing, help them grow into the craft and hopefully get a better tester than I am. There are a lot of movements currently going on, and I think based on my past I can be a contribution to these movements. This is all I want to say for now. If I made you curious about more, you may want to subscribe to my feed, as I will be digging deeper here shortly.