The new QA: the Quality Advocate

“Quality is not an act, it is a habit.”
~ Aristotle

When I was recently writing about Quality Guardians/Gatekeepers for Pride and Paradev, I asked myself what does the term Quality Assurance actually mean?

In the world of software testing, there’s a lot of contention over the use of the term QA instead of testing. Often testers consider themselves to be Quality Assurance (QA) even though they don’t ensure quality, they just test it.

It actually makes more sense to call independent software testing after development Quality Control (QC) as it is simply verifying quality rather than ensuring it.

As previously stated, I believe that is is no longer sufficient to test quality in; agile software delivery teams need to build it in. A person performing a Quality Assurance role in an agile team can work closely with the team to strive to build quality in, but still can’t ensure quality actually exists (programmers can still check in bad code).

So, I propose we rename QA to mean Quality Advocate.

A Quality Advocate (QA) in an agile team advocates quality. Whilst their responsibilities include testing, they aren’t limited to just that. They work closely with other team members to build quality in, whether that be though clear, consistent acceptance criteria, ensuring adequate automated test coverage at the unit/integration level, asking for dev box walkthrough, or encouraging collaboration/discussion about doing better testing within the team.

Whilst the Quality Advocate promotes quality as part of their role: quality is everyone’s responsibility.

The benefit of doing this is that testing becomes more efficient for the Quality Advocate and a better product is produced overall as quality has been built in from the beginning.

“Quality means doing it right when no one is looking.”
~ Henry Ford

Addendum: Whilst writing this post, a colleague of mine suggested I use the term Quality Activist instead of Advocate. Whilst I like the sound of it, I think it’s a little too extreme: I want to promote quality, just not tie myself to office furniture over it.

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

10 thoughts on “The new QA: the Quality Advocate”

  1. I prefer Quality Advocate to Quality Assurance, since most of us testers are NOT doing QA. And I get the difficulties with the term “tester”. Because in the past, people without much passion about their jobs did manual scripted testing that didn’t require much skill gave “tester” a bad name. And my definition of “tester” does include important contributions others may not associate with testers, such as helping customers come up with examples of desired and undesired behavior to clarify requirements/desirements.

    So I agree with the point that “tester” may not convey the right value. But quality should be a team responsibility, and IME when someone gets the title of “Quality something-or-another”, it can cause people in other roles, such as coders, to think, “Well, I don’t have to worry about quality, because Jill over there is the Quality Advocate and she’ll take care of that.”

    Also, though we should encourage our teams to take responsibility for quality, and for testing activities (since testing is an integral part of s/w development, along with coding), when I’ve tried to do that by evangelizing, I got no results. It has worked much better for me to get the whole team together, and bring up testing issues, and ask for help. Coders and others on the team DO care about quality, and if they’re given freedom to do things besides slam out production code the whole team can identify issues that impact quality, and try experiments to improve a little bit every day.

    I think it would be great to come up with a term for “tester” that encompasses everything we do. What other ideas to people have?


  2. It’s an interesting point of discussion. I was involved in a re-branding exercise that involved changing a “QA Team” to a “Test Team”; this served a dual purpose in allowing us to reset the expectations people had (or didn’t have) for our testers – and it also helped rid the use of horribly mangled grammar, like “let’s get the QA’s to QA it on the QA environment”.

    I agree there is also a strong case for using something different. (True) QA and Testing are generally thought (consciously or otherwise) to be at opposite ends of the spectrum when it comes to software delivery. “QA” is (or at least should be) about the entire delivery process; what language have we chosen to deliver this software in? what framework(s) will we work in? what are the ‘gate’ processes (if any) that we should use? What database should it sit on top of? How is this being built? How does all this relate to the fundamental requirements of the user? What are the long term implications of this approach? etc, etc. “Testing” on the other hand tends to focus mainly around the end product (or features) and how it relates to user requirements and any other systems it has to integrate with.

    What “testers” actually do is probably a mixture of both; they will perform a lot of analysis up-front in order to understand what the user wants, how the systems is going to be built, what the integration points look like, what dependencies exist, what scope there is for automating, etc. This helps to maximise the understanding how to go about testing the system. They will also do a lot of analysis on-the-fly; if something appears amiss, there is more to raising a bug/defect (another debate right there!) than taking a screenshot. Investigation in to the cause – or at least eliminating potential causes – is vital in order to enable developers make an effective repair, rather than applying a fix that may lead to further problems.

    So, taking all the above in to account, if I were to try and describe the role now, it feels more like something akin to a Software Analyst – although according to Wikipedia this is what the BA used to be called – as it’s more than “just” testing but (as Lisa points out) Quality should be everyone’s business. [Other suggestions: Development Analyst, Delivery Analyst].


    1. Love that you re-branded your QA team! That use of “QA” as noun, verb, adjective drives me nuts too.

      My first job in software was “programmer/analyst”. That was back in 1982 before we even knew there could be a role of tester – there was, but we didn’t know. We also didn’t know about business analysts. We were expected to sit down with the customer, figure out what they wanted, iterate until they were happy, and put it in production.

      Changing the name to something completely different could be a good idea!


  3. Quality Advocate still puts the (false) burden of quality on the tester. What we need is something that combines the aspects of expertise in multiple areas, interaction with the entire team, and passion found in a good tester. The best I have found is a title that Gojko Adzic called himself during one presentation I saw: Strategic Delivery Consultant. Now that is a title that says it all.


  4. Nice post! Any chance you could elaborate on these activities in a subsequent post? I’d like to learn more about how you approach these non-testing QA activities.

    “They work closely with other team members to build quality in, whether that be though clear, consistent acceptance criteria, ensuring adequate automated test coverage at the unit/integration level, asking for dev box walkthrough, or encouraging collaboration/discussion about doing better testing within the team.”



Comments are closed.