Adventures in Tautology - What Makes a Tester a Tester?

The latest The Testing Show has been released. Some interesting thoughts and comments have been spinning through my head since we recorded this episode. For a number of organizations, the "tester" as we have long identified them, is going away. In this sense, I mean the dedicated person who focuses on testing as a specific discipline, who gets into the guts of an application, who spends the bulk of their time actually testing the product, independent of any other responsibility. For other organizations, testers are a huge part of their infrastructure, as essential and as non-replaceable as a plumber or an electrician. Why is there a disconnect? Is there a disconnect?

First, a little about my history. I can safely say I have worked for three companies that specifically needed to have dedicated testers. That's not to say the others didn't benefit from having testers, but I'm talking about how they were physically structured, staffed and what they made. Cisco was my first experience in the world of software development, but also hardware development and maintenance. That's where I saw first hand the different definitions of what a tester was.

First, there was the tester on the Engineering side of the house, those of us who worked on IOS (Internet Operating System, not to be confused with the much later appearing iOS from Apple), and on the microcode that resided on system boards. These teams had dedicated testers who spent a lot of time working with early automation frameworks or even just running commands via 'tip' to get access to the consoles of these devices to work with them. We also had quite a few of us who were involved with physically building up test labs, configuring the hardware, bringing in diagnostic tools and doing wide-ranging experiments. In short, we did things that the developers just plain did not have the time to do, at a level that provided a lot of feedback to further development and design, as well as to hunt down problems.

Aside from that, there was also the Manufacturing side of testing, which was a very different animal. For the first nine months that I worked with Cisco as a contractor, I was dotted-line associated with both Engineering and Manufacturing, and I sat in on meetings with both groups. It was here that I really saw the difference. Manufacturing testers were often times better described as "rework specialists", in that they tested, but they also rerouted and resoldered boards so that they could be re-deployed. I confess, I often felt out of my league with this group. It seemed they knew so much more about the bare metal issues than I ever could, and they also knew quality issues they had to address within seconds of looking at a particular board. I still smile when I think of going to talk to my friends Winnie, Jim or Azhar, among several others, and just their quick ability to look at something and say "oh, yeah, I can tell you what's up with that!" This was a skill, a craft, that I would say, honestly, only a handful of the software engineers possessed. This was a knack that was inspiring. I would ultimately work on the Engineering side of the company, and I would often suggest that, if we really wanted to augment our test teams, we really needed these people over in manufacturing to join us. Ultimately, several of them did, and yes, our test teams immensely benefitted from them being there.

The other two companies that required testers were Synaptics and Konami, for different reasons. Synaptics definitely because it was a blending of the software and the hardware (and truth be told, I think I found more issues with product tensile strength or composite construction than I did with software). Konami because of the factors that are so subjective when it comes to gameplay outside of "correct programming" (and the all important "physics tests", which, frankly, I don't wish on anybody). Oh, and in my case, they wanted to release a singing game, so they needed someone who could test and sing really well. Truly one of the most serendipitous jobs of my life :).

All of the other companies that I have worked for, I'd be hard pressed to say we essentially "required" dedicated testers, but again, I think we were well served to have them. Over time, though, as systems moved on to regular builds, incremental development and design, smaller and more frequent releases, and quicker answering to customer feedback, I can see why it would be easy to say "testing is a role and not a full-time profession, and we can do the testing with a smaller team or, even, with a single person" (which many times was me). Often, my testing role would be used, but I would be asked to do other things as well, such as provide second tier support, perform training, work on automation frameworks or, often, just look at the maintenance tasks within an organization. Side note, if you have not heard the Freakonomics episode about "In Praise of Maintenance", may I suggest you do so, as it has excellent commentary that is quite relevant to this discussion.

Since I've left Cisco, I have, generally, worked for smaller organizations. Those organizations have, at times, been subsidiaries to bigger companies, but usually, the group I work with is the entity that I interact with, so for all practical purposes, they are my company. That means I typically work with teams of around a dozen developers, rarely more, and most of the time, I've worked with me as a lone tester or, maybe, with one or two more testers. Most of the time, we are not just testers doing just testing. We cover a variety of other jobs and needs, and frankly, in smaller companies, that's to be expected. It's not uncommon for a tester to also become a de-facto systems administrator, or a triage support person, or a build master. We still test, of course, but also we encourage others to test as well. I'd say it's not so much that testers are going away, but that the role of testing is being seen as necessary in many places and not encompassed by a single person.

Ultimately, what we come to is that Testing as a discipline and as a craft is an essential part of software development. I still hold to the truism that training in testing discipline and philosophy is valuable, and those who do so will be uniquely positioned to benefit from doing that. I'm also saying "don't be surprised if you find that your job responsibilities are not just testing, or that you may even find you are not ultimately called a tester at the end of the day". At this point in time, my job title as defined by HR is "Senior Quality Assurance Engineer". Time agrees with the Senior part. Having to finagle and discover workarounds begrudgingly lets me consider myself an Engineer (I've never really been comfortable with that title because it means something specific in other industries that I have no chance of meeting requirements for), but Quality Assurance is my bag, even if the words are a little tortured. In short, I work in ways that help to encourage quality. I'm on board with that. I'm also on board with the fact that I often bring many other skills to the table that organizations can use, and that those skills can be leveraged to provide value for my company. Many of those skills have been informed by testing, but are not in and of themselves "testing".

To come back to the beginning, I think all of us test and all of us are testers, but there is a benefit to having a group who pays attention to the testing discipline more directly than others might. I'm happy to be part of that group, but I also understand that that alone will not make me valuable to an organization. Being a good tester is important, but if the desire is to work for smaller companies, do not be surprised if you are asked, "what else have you got?"