Testers don’t prevent problems, but maybe they can

A couple of weeks ago, I read Michael Bolton’s post that argued “Testers don’t prevent problems.” (http://www.developsense.com/blog/2016/05/testers-dont-prevent-problems/, and it got me thinking. To give you a bit of context, I was lucky enough to have a few conversations with him when I lived in Toronto. The fact that his blog post got me thinking is no great surprise; he has a talent for getting people thinking. I’ve often referred back to his 2010 post “Testers: Get out of the Quality Assurance business” as a useful guide.

I generally agree with the premise in his post about testers not preventing problems, with the following caveat: you must assume that the tester’s role is focused on creating, executing, and reporting on, tests. Certainly, it seems like some companies expect their testers to perform in this role, and little-to-no others. At the same time, I do think that the tester CAN help avoid issues from occurring in the first place, if the tester takes on a broader role in the project.

They can do what I think testers should do – ask questions. By asking probing questions, we can prompt those who do build/make things (programmers, designers, graphic artists, etc.) to think about things that they might not have considered, or may previously have taken for granted. I’ve been thinking lately, that “QA” maybe doesn’t need to go away, but rather we need to replace “Assurance” with “Advocacy”. A person practicing Quality Advocacy could reasonably be expected to participate in a project from the very beginnings, all the way through to end-of-life. Testing might be part of that role, as could be participating in design, marketing, sales, training, and virtually every other aspect of the project. Their purpose would be to use the same kind of approach and mindset we use to test software, but to test all parts of the project.

I’ve noticed that I’m not the first person to suggest the “Advocacy” word replacement; I’ve also noticed that most of the proposals for such a role are limited to the development process. On the surface, this might make sense – after all, why wouldn’t the tester stay within the bounds of the technical part of the project? I think that the answer to that is that, at least for someone who is context-driven, more than just the technical parts of the project matter. A Quality Advocate should strive to understand the entire context of the project.

Some might argue that such a role already exists; whether the title is Business Analyst, or Product Manager, or Project Manager, these roles usually have a similarly holistic view of a project. However, their end goal isn’t just quality; they also have other demands on them. Whether it’s minimizing costs in order to maximize profits, or meeting a promised deadline, they simply cannot focus only on quality. So, why not give them a person who can understand the project with that same holistic view, but without the competing expectations? Not to say that a Quality Advocate wouldn’t be aware of those factors; instead, they would endevour to provide ways in which the team can try to meet some of those expectations, or minimally violate them, without making quality a subordinate concern.