What Does QA Mean?

If you were to plug the question, “What does QA mean?” into your favorite search tool, you would get about 7,980,000 results. However, we need to define what Q.A. is an acronym for before we can start talking about the true definition of it. I want to take a step back to reset our foundation when we talk about QA. So let’s get into it; what does QA really mean?

To level-set, the Q means Quality; a loaded word in its own right because books have been written around the questions, “What does Quality mean?” and “Who gets to define it?” Lately, I think of my role as the person who’s looking to reduce risk on the projects I support vs the one who ensures quality, but that’s another blog post.

The “A” is where things get tricky. That “A” can mean Assurance, Acceptance, or Assistance. All three will give their unique change to what we mean when we say “QA.” I need to call out that I’ve been heavily influenced by the Modern Testing Principles (MTP) document, which will be referenced below…a lot.

In my role at Aries, I use the most common “A” in my title – Assurance – mostly because it needs the least explanation of the three possibilities when it comes to software projects. Assurance in software projects typically means that the software meets the requirements; usually given to QA in the form of requirement specifications or user stories which are then turned into test cases. However, this approach has always been weak because the requirement or user story may not match what the customer wants or meet the customer’s definition of quality. So what then? That’s where we see the shift to the second “A” – Acceptance.

Acceptance depends on two agreements:

1. We are testing to see if the software is acceptable for business use.
2. We know the person or group who will decide if the software is acceptable for business use.

Notice that I didn’t say the tester is the one deciding if this is acceptable for business use. The reason why comes down to who gets to live with the software day in and day out; they are the ones who will know the level of quality. This stems from number five of the MTP; “We believe that the customer is the only one capable to judge and evaluate the quality of our product.” 

The testing role here is more like a detective. We look for all the things that can cause the software to fall short and provide that evidence to the team so as a group we can decide if the software is acceptable. (Shout out to Ingo Philipp for the tester-as-detective analogy!) However, the final acceptance has to come from the people who will be working with the software, not the people testing it. This is when we see the third and final “A” appear – Assistance.

The use of Assistance is new to QA. Number four of the MTP states, “We care deeply about the quality culture of our team, and we coach, lead, and nurture each other towards a more mature quality culture.” Notice the word “test” is not in that statement. Nowhere in the MTP does the word “test” appear except in its title. But if you’re like me, I’d still ask, “Who’s going to test this?”

It was Atlassian’s Penny Wyatt who had one of the more interesting answers to this question in her “Quality at Speed” talk at the 2015 Atlassian Summit: have everyone on the team test!

Here are the two core agreements any software team should have:

• The team owns Quality – not one person or group called “QA.”
• The team knows who decides if the quality software is acceptable for business use.

But how will the team know what or even how to test? Penny’s “Quality at Speed” deck coined the term Quality Assistance – a role on the team that helps identify the various areas the team needs to focus on and the activities they need to do to help improve the software’s quality and fitness for business use. It can also incorporate user interviews, documentation (both internal and external), issue tracking, and, yes, testing, but with the whole team involved in testing not just the coach. I was skeptical about this approach at first, but now it’s one I push for whenever I can.

Whichever of the A’s you put next to the Q, the key is to be clear and consistent with the choice. As a QA person, part of my role is to be flexible enough to use any of the three A’s while also ensuring that the main goal never wavers from number one of the MTP, “Our priority is improving the business.”

Find out how Aries Solutions can improve your business with composable commerce!