Testers and programmers are much more alike than some people think they are. Many of us work in organizations, some of them large. There are several dynamics in these larger systems that have an impact on our habits, shape our culture, and influence our private lives.

There is something to say about professionalism, and the practices of our craft. Where and when should we learn about such stuff? Let me tell you my personal story. Though I will refer to software testing, pretty much the same also holds for programming, and most programmers I have seen in the organizations out there.


Personally, I have studied back from 1999 to 2005 in university. I learned a bunch of stuff. How to do programming in Haskell, how to program a 6-limbic robotic arm, and how to do offline and online training of computer systems. I learned about face detection algorithms, and we wrote one on our own. We adapted that stuff for office materials like a keyboard, a rubber band, and so on. My diploma thesis was about hand gesture detection applying similar approaches. I am still amazed that most smartphones nowadays can do the stuff we researched back then.

I interviewed for my first position in 2006. I was interviewed for a position of a software tester. I had heard about software testing twice in university. Once during a course on software engineering when it dealt with the V-model. There was a 15 minutes lecture on it. The other time was during the Software-Praktikum, a combination of programming, and some lectures. There was this professor who told us about those freaking folks doing extreme Programming. They were doing test-driven development. No one cold explain to us what it was in 2000.

So, I sat there the first few days into my new job, and needed to learn a bunch of stuff. Besides the unfamiliar domain, and the unfamiliar approaches to automatically executing tests on a Solaris machine, I needed to learn about software testing. That was my profession now.

I didn’t learn much about the domain I was working in back in university – no wonder. I slightly learned something about shell-scripting that I could use in my job. But I certainly didn’t learn anything about my profession – neither software testing, nor software development. So, I had to learn that somehow and somewhen differently.


What I had learned in university about learning was to get a bunch of books on the topic, and get going. So, I ordered a book about software testing. It was a classic book, written in German. It had some decent amazon reviews, so I decided to get me a copy.

It was awful.

I couldn’t read it for longer than five minutes. All those terms didn’t give me a clue. It was worse. They were confusing me. Equivalence classes, white-box, black-box, you name it.

So, I still sat there, and couldn’t find out what to do. So, I took a different approach.


I started to ask questions to some of our senior testers. We were in the middle of a project, and were closing up on release 0.4 for an upcoming product. We had weekly meetings with our project manager that asked for status.

I had taken on some tests for use cases that I could understand two months into a new job. I was able to add customers, addresses, modify them, maybe I was able to create an account with those address data as well. That was it – mostly.

So, I took on some of the tasks related to customers, addresses, and maybe accounts. For me, those were easy. I merely created the tests that I felt were necessary. I worked with colleagues to have a look over my documents, and provide me feedback where I needed it.

I was able to learn from my colleagues back then more than I was able to learn from books, or rely on the knowledge that I had gained from university.

Training classes

One and a half year into my first job after university, I attended an in-house course on software testing from an outside consultancy. At that time, that guy spoke about all the stuff that was in the book that I had bought a couple of years ago on software testing.

At that time, I knew which test practices I would need. At that time, I didn’t see any benefits of the stuff that guy was offering. I never needed it again.

Due to lack of official training classes, I had decided to jump in and learn as much as I could to do a decent job on my own. I knew how to get to the sources that were relevant for my job. I had bought books which resonated with me, and were easy to read. The training class came to late, and it was merely justifying what I already knew.


What I had learned back in university was how to learn. University didn’t teach me lots of stuff that I would use again when I joined the corporate live, and worked for The Man. I had to re-invent my knowledge to fit the job that I was hired for. I knew how to do that thanks to university.

The training class that I attended eventually came too late. At that point I already had done a decent job as a tester, and was asked whether I wanted to become a group leader for a particular testing group. I already had learned what I needed to learn to do a decent job of software testing. If I had waited for the training class to kick in, I would have provided a dis-service to my employer. I could learn that faster than that.

There are good and bad books out there. But how can you differentiate the two as a beginner? You can’t. I jumped to the first, and really got disappointed. I was lucky enough to be able to follow my passion and my instincts, and could compensate a lot of missing knowledge by that. Over the years, I have read several testing related books. Now I think that I merely started with one of the worst ones. Bad luck. Maybe I should have looked for more alternatives first. Who knows. Peer recognition can be helpful with that.

But most of the stuff I needed to know I learned from my colleagues. They were able to help me on the job, and answer my most-pressuring questions. They were able to help me, to coach me, and to mentor me. They could help me with the pressing questions at the task I was given. They provided some answers to me, and eventually those helped me shape my mind.

Learning on the job with feedback from your peers is probably the biggest learning channel that you have access to. Use it whenever you can. Few other methods can provide you the same learning depth.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks