The Mis-Education and Re-Education of a Software Tester

Some of you may have noticed by now that today's title is the sub-text for TESTHEAD. I had a conversation recently about that very sub-text. One of the comments was that ”[…] the name of your blog ‘The Mis-Education and Re-Education of a Software Tester’ sounds rather negative”. I hadn’t considered that might be the interpretation, so today I’m going to explain exactly what I actually mean with that sub-text.


For starters, it helps to understand what got me into testing in the first place. I didn’t go to school to learn how to program computers or to test software. As a matter of fact, I went to college my first time around as a way to do something while I waited for my “real career” to take off. From 1985 until 1992, I spent a lot of my time, talent and energy trying to make a go as a musician in the San Francisco music scene. That was my passion, my reason for living at that point in my life. It was a lot of fun, and I had a great time doing it, but it never really made me a living.


In 1991, I had an opportunity to work with a temporary agency, and my first job sent me to Cisco Systems down in Menlo Park (back when they had 300 employees). While I was there I worked with the Engineering and Manufacturing groups, and that temp job turned into a full time job where I administered the Engineering test labs. Because of my time in the test labs and setting up machines and keeping a large lab environment up and running, I came to the attention of the test group, who thought I might make a good tester. So there it is, my meandering route from musician to tester.


Once I was in the testing group, I learned what I could from other testers and developers. There was no formal learning process or training program for testers. I took some classes on UNIX Shell scripting and on how to program in C and C++, but I never took any classes about how to test or what worked best in a test environment. Along with the rest of the test team, I was given a copy of John Ousterhaut’s book “Tcl and the Tk Toolkit” and told “learn this, as our automation tests are all based on this”. During my entire time at Cisco, I owned exactly two books on testing; “Testing Computer Software” by Kaner, Falk and Nguyen, and later on, “Software Test Automation” by Mark Fewster and Dorothy Graham.


Over the years, I have mostly functioned in what I call “firefight mode”. This has been an approach to “learn what I need to so I can get done what I have to get done”. Some might call it a “Street smart” method of learning, where experience teaches what to keep and what to discard. The problem with this approach, in hindsight, is that, while it’s a great practical way of dealing with issues, and can be lean and mean some of the time, it doesn’t afford a very critical view of what or how the process develops over time. Additionally, to borrow a bit from the “street smarts” attitude, the vernacular rarely rises above the level of the street. This problem becomes even more of an issue when the tester in question is more of as lone resource or is focused in a specific area, which has been my reality for much of my career. In these cases, I often used whatever mechanism was in place for creating documentation, writing issue reports, and testing systems. To borrow from Steven Covey, I was so focused on making sure that we were climbing the ladder, I rarely had time of inclination to ask myself “is the ladder leaning up against the correct wall?”


It’s only been the last few years that I've decided to take a broader view, and to really determine if that is indeed the case. To this end, I made a commitment that it was time to learn what I really knew, and discover what I really didn’t. This meant doing some vocabulary checks, and expanding my vocabulary. This meant reaching outside of my little cocoon and finding out what other testers were doing. It meant opening myself up to the fact that I might find that I was sorely lacking in key areas (something I always knew deep down, but it was less threatening when it was a fuzzy and amorphous lacking). It meant facing up to the fact that there were aspects to testing I just didn’t know anything about, and also to realize that these aspects were thing I just might not be any good at, at least not at that time.


This is the re-education part that I have been talking about, a way to get a better handle on areas that I knew about but couldn’t explain or quantify well, and delve into areas that I knew nothing or very little about. To that end, I made a commitment to read every testing book I could find. Some are great, some are lacking, and some take different views of concepts and are passionately argued by proponents and opponents. Taking the time to sift through these areas and apply them ourselves is critical.


We only learn what we actually apply, and then what we can effectively communicate to others. I decided that I didn’t want to continue on with half truths and lore that got handed down and were only partially applied due to necessity. That doesn’t mean my goal is to become some uber-academic that masters all nuance of “test speak”. Quite the opposite, I want to see what I can do to better understand the discipline that is testing and determine how to carry those ideas forward, and better apply the techniques. My ultimate goal is to become better at testing and to learn better ways of applying those skills.