Recently I engaged in a fun exercise with a test team wherein each of us had to answer the following question: How do I describe my role? It’s always interesting to me to see how people answer this, particularly in the fields of testing and quality assurance. So here I’ll provide the answer I gave, along with a bit of context for it. A key point for me, in this exercise, was an implied corollary: How do I describe my role — such that what I do is seen as something others couldn’t do? At least not without the appropriate experience. I do think this is important for testers and quality assurance specialists, particularly in an industry that is often conflating those roles with others or attempting to remove such roles entirely. In my post about my future in testing, I mentioned that I want other roles to be looking at my role and saying: “I find you valuable because you’re doing a job I can’t do, at least not without putting in the effort you did to learn the discipline.” This would be as opposed to them saying something like this: “I find you valuable because you’re doing a job I could do but really don’t want to do.”

There Is Value; Then There is Unique Value

As an example, let’s say that, in describing their role, a tester says: “I find bugs.” Okay … but by itself, that might imply that if you are not finding bugs, you are not adding value. Further, developers can also find bugs. So can business analysts. So can product managers. So can customers. Thus this ability is not exactly unique. Granted, a specialist tester may be (and should be) better at finding bugs, particularly more subtle ones. And that is important. But it’s still not how I would choose to describe my role. What about this: “I help people make better decisions by presenting them with risks associated with project and product quality.” Pretty good, right? Certainly part of what testers do is surface problems. But, of course, the same could be said of other people on the team as well. It’s a value-add but it’s not a unique value-add. I want to be clear that I’m not dismissing either of these kinds of responses. Testing absolutely is, in part, about communicating actionable information to the right people at the earliest possible time so that important decisions can be made. As a specialist tester with a broad focus, you have to constantly learn new strategies and techniques to help find more — and more important — risks. As a specialist tester with a broad focus, you have to categorize what you do into new strategies to help train others to find and present risks. Okay, so what about this: “I help various teams answer the constantly shifting question of: how do we ensure a reasonably achievable level of quality with the given resources and constraints?” Again, not bad. And potentially very accurate, insofar as it goes. But, again, others could argue along very similar lines. After all, if you distill that statement to a business-metric approach, it becomes a question like this: “What am I doing to help the company make more money, help us spend less money, and help us protect the money we already have?” That said, the focus on the question being “constantly shifting” is important. When testing, as an activity, is democratized and it’s acting in service to a function that treats “quality” as a more-or-less shifting complex of viewpoints — and thus a distributed function among teams with those different viewpoints — you can constantly morph and shift in resources as and when they become relevant. Being able to do so flexibly is a skill. But this comes with what I believe is a key caveat: the function of quality assurance never stops being relevant for everyone, even for non-testers. The function of testing cannot avoid being present, even for non-testers. Much of what human beings do is a form of testing, even if they don’t label it as such. Much of what teams, collectively, are doing is a form of quality assurance. Granted, the vast majority of those people are not acting as specialist testers or specialists around the idea of quality assurance. But, still, it feels to me like these statements just aren’t unique enough.

So how did I answer?

Here’s what I said initially:

• I remove artifact crutches, reduce sources of truth, and document just enough, at the right levels of abstraction, to provide a truth-preserving mechanism around the project singularity.

Yes, there’s a lot to unpack with that statement, hence links to various places where I’ve talked about the ideas. But that’s okay. I want there to be a lot to unpack. I believe what I do is a specialist discipline that has many parts in common with other roles — but also some very distinct and unique components that I bring to the table. I don’t want people to read (or hear) my description of my role and walk away thinking they know what I do simply because of past experiences with testers or with quality assurance. I want a bit of cognitive fiction to occur when I describe my role. On the other hand, I can’t provide hyperlinks when I speak and I don’t want someone to have to read lengthy blog posts just to understand me. So here’s how I broke my initial statement down a bit:

• I help preserve truth across project, process, and team boundaries.

• I provide solutions to mitigate intransparency and prevent problems from being undetected.

• I focus on looking for and surfacing problems and risks that hide in human blind spots.

• I help others gain insights into capabilities, limitations, and sensitivities regarding our product and the business domain.

There is a constant need to reframe and re-situate these ideas due to shifting contexts. I become a communication and collaboration generalist and something of a knowledge engineer. This is a role that I have to do constantly, while staying abreast of the latest thinking in various disciplines, such as project management, business analysis, agile thinking and practice, development (with many languages), testing, test tooling (again, with many languages), and so on. But I’m not an expert in any of those. I simply know enough to harness the thinking behind them and then get others to harness the actual power of each discipline.

Are You Even a Tester?

When I describe some of this, some people do ask (justifiably): “Are you even describing testing any more? Or are you just bored with your career at this point and trying to redefine what you do?” It’s a fair point and a good question. I started an inadvertent “tweet storm” at one point when I posted about whether “Testing” was the right term any more for what specialists are doing. Realistically, of course, I’m not recommending abolishing the term and reframing the industry. I also don’t want to start becoming a semantic deconstructionist, like some long-time testers seem to be doing.

Are you a Specialist?

What I describe above is, to me, what being a Quality Specialist (for lack of a better term right now) is about. At its core is harnessing the human function of testing, but on a much broader scale than is sometimes traditionally considered. As just one example of what I mean by that, a lot of the test industry gets focused on the artifacts, like bug tickets or test cases or test plans or Gherkin-style feature files. And, to be sure, there are plenty of people that can write an artifact, but not as many that can turn these artifacts into a coordinated and/or orchestrated experience. That’s what a test is to me: an experience. A particular orchestrated way of doing and thinking. The focus on artifacts encourage “testing as a noun” rather than “testing as a verb.”

Testing Is a Broad Discipline

In my mind, a test intersects with thoughts, judgments, values, bias, perceptions, and skills. But a test is also various types of artifact. And that means testing, as an activity, straddles a line between a being technocratic and a social discipline. I plan to revisit this post after I do some more thinking on this, including on my responses. I’m also curious to what extent my thoughts now correlate with some of my thoughts when I talked about the soul of testing. This is also part of my continued focus to refine my thinking about my career and my discipline, when I ended last year on a note about my future in testing. I realize it takes a certain amount of hubris to assume any of this is even relevant to someone else besides myself. I do hope, however, that these kinds of posts spur the thinking of not just my fellow practitioners in QA and Testing, but also in other disciplines that we intersect with and that have to work with us.