Quality Assurance vs. Software Testing

For a vast majority of my time in the Context-Driven community, I have loosely accepted many “truths” as presented. I have pushed back on some, argued with a few, and flat out rejected some others. The idea that Quality Assurance is an inferior title to something more appropriate such as Software Testing, Light Shiner, Information Gatherer, or Bug Master. Recently I have found that I have a loose agreement with this idea. This post is an attempt to come to a better understanding for myself, and hopefully others in the community.

So not long after my whole team took the RST course with Paul Holland, they decided as a team that the name of our team should be more representative of what we actually do. It was a unanimous decision to change the name from “Quality Assurance” to “R&D Testers”. This was indicative of the fact that we were first and foremost, members of the Research and Development team, and that the role we filled was testing, as opposed to “Assuring Quality”.

Great! I left our meeting that day thinking the team really listened to some of what was taught. I thought the process of changing the name of the team would be rather simple. Change a couple e-mail aliases, a couple quick conversations with the R&D team leadership, and we’d be done.

So I went to start those quick conversations, and it turned out that they weren’t as quick as I thought. Before I go on, I want it to be clear that these individuals I was talking to are engaged development leadership that really care about what we do, engage in community discussions on agile and kanban topics, and actually have my respect in some ways. This isn’t a “bash the ignorant” type of blog post. In that framework, I brought this idea to the R&D team leadership and was met with some resistance. In my side of the conversation, I parroted the arguments I have heard from others in the community, “testers don’t do anything to assure quality, we can’t be certain (or sure) of the quality of a product.”

This was not received as well as I thought it would be. I was under the impression that this was a self-evident truth. That others in the industry were simply too ignorant of what testing actually is to understand this, and all of this “QA” garbage that flies around are relics of manufacturing processes that get applied to software. Here I was talking to people that I share many beliefs about software development, and they disagreed with me. The main thrust of the argument was disagreement with the notion that testers do nothing to assure the quality of a product. In this person’s opinion every project and team they had been on, testers were very influential in increasing product quality and therefore the name QA wasn’t altogether misleading.

“But we don’t ‘ASSURE’ anything, impact perhaps, but not assure,” was my dutiful context-driven retort.

“Assurance doesn’t mean that the product is perfect, but QA people definitely bring a great value in improving quality,” was the response I got.

I was able to walk away from that conversation with a kind of do-whatever-you-want-to agreement from our team leadership, but I wasn’t satisfied. I went back to my desk to look up the definition of the word ‘assurance’ to prove that my point was right, we don’t assure anything as testers. In looking up this definition, this is where my agreement with CDT started to get a little looser.

The definitions of ‘assurance’ all pointed back to the root word ‘assure’. Miriam-Webster offered 4 definitions of ‘assure’. I pulled each one and started detailing why each of those definitions didn’t apply to what testers do (the outcome of that process can be seen here). I eventually came to a definition of assure that stopped me though: “to give confidence to”. For example, “The child was scared to go to the dentist, but her mother’s assuring words gave her the confidence to climb into the chair.”

This reminded me of a conversation I had with James Bach a few years ago. The first conversation that really pulled me into the CDT community was that they were the only people that seemed to agree with me on how testing is valuable. As James and I were talking he made the following comment, “I test because my clients are worried that something they don’t know about the product will hurt them.”

To me, that statement seems to agree that testing is done to build confidence in a product. At the end of testing, all wrapped up in appropriate safety language and carefully crafted words is a report about the level of confidence in a product, or at the very least information that is meant to affect some stake-holder’s confidence in a product.

The rest of the definitions of the word assurance I agree are misleading, even a bit scary. But the idea of Quality Assurance being a process of building confidence in a product, or gathering information for others to build that confidence, is one that I think I could get behind.

This isn’t to say that I dislike the term ‘testing’ or anything else that does a decent job of describing what a team does. What I am trying to do here is gain a better understanding of why the community is so opposed to the term “Quality Assurance”. Please let me know in the comments if you agree with how this is presented, or where I am way off.

My next post will be about the cultural impacts in an organization of changing the name of team from QA to Test. That is what this post was supposed to be, but I thought this was a better point to start the conversation.

January 9 2013 Update

So after letting this post simmer for a few months, I have decided that taking up the fight internally to officially change the name of the team wasn’t worth it. We refer to ourselves as testers. The rest of the development team understands that we are testers, but in terms of support, sales, marketing, etc. I didn’t find there to be any payoff to changing the team name. Heck, I don’t even have the energy/time at this point to write another full post about why I feel that way. That is why I am updating this post rather than writing a new one. I wanted to cover another topic in my next post, but didn’t want to leave this topic unsettled.

9 Responses to this post.

  1. Posted by Phil Kirkham on 19.09.13 at 8:06 pm

    ‘kay, I’l have a go:

    I take QA ( and so does Wikipedia) as being concerned with the processes and methods – so a QA person might suggest bringing in a skilled exploratory tester, suggest the devs do TDD etc etc
    Quality at your place is ‘improved’ because there is a QA process that means the s/w is tested and the bugs are fixed. If that’s what you and your guys are doing then call yourselves QA but that’s separate from the function of testing

    IMHO

    and do you want to act as a mother to your stakeholders and treat them as little children? Let them know the facts you have found out about the dentist – 100 patients have seen him and none have complained

    Wade Says: In the last couple gigs, as the “QA Manager” I have worked a ton with the development teams on processes, both related to testing and to how they do their work. I really like everyone on the team to be thinking about how they can be doing things in a better way, but I recognize that isn’t the same as that being the focus.

    Being the “QA Manager” though, I can also see how I would have “Testers” working for me.

  2. Posted by Paul Carvalho on 19.09.13 at 8:06 pm

    Nice piece, Wade. I have entered into this conversation a few times over the past decade at different companies.

    In one company I completely had the ability to change the name of the test team and in the end I recommended we stay/go with “QA” for the benefit of our clients who expected it. While our company’s leadership understood the point, I recognised that it would create less grief in the long run for our company to not have to explain it every time to our clients.

    While names sometimes matter, how you treat people matters more. Your team’s contributions and value-add can work past any labels or stigmas and earn the respect of your peers. On that day, you may find that no one cares about the titles anymore.

    Wade says: So are you saying that there is no difference between what a “Test” and “QA” team would do? Or are you saying that the words don’t matter as long as people understand? My goal with this post is to really have a firm understanding for myself and others as to what the terms mean, then my next post will be about whether or not it is worth changing the title organizationally.

  3. Posted by Phil Kirkham on 19.09.13 at 8:06 pm

    So I went back to my blog as this is one of the arguments that made my ‘testing cliches’ list

    http://expectedresults.blogspot.com/2008/09/testing-cliches.html

    check the date – 5 years ago

    and it references articles from 2006
    http://blogs.msdn.com/b/alanpa/archive/2006/02/14/532185.aspx

    2005
    http://blogs.msdn.com/b/steverowe/archive/2005/03/03/384637.aspx

    2004
    http://blogs.msdn.com/b/micahel/archive/2004/10/27/248564.aspx

    so is there anything new to be said?

    Wade says: I never said this was a new topic, just that this was my attempt at putting into words and wrestling with the idea a bit for myself, and hopefully the good of others.

  4. Posted by Alex Bantz on 19.09.13 at 8:06 pm

    Wade,

    I have been working to get our team to transition from the SQA group to the Software Testing Organization (STO) and now perhaps a compromise to be the Quality Engineering (QE) org and removing the Assurance term altogether.

    Along with your own interpretation of what assurance means, I think the bigger is the interpretation of the other parts of the business have for the term. They see Quality Assurance and tend to assume any issue post release is simply a problem in the “QA process” and thus puts focus on the testing team where they really are thinking of the development/release process as a whole.

    There was a nice discussion at CAST this year after one of the presentations on QA vs. testing in our titles, org names ,etc.

    I think the different naming set a different expectation from others on what your team can/cannot do for them.

    Wade says: So along with what Phil was saying, the meaning of “Quality Assurance” is more than the sum of the two words defined separately. “Quality Assurance” is a term all in itself that needs to be defined. Mirriam-Webster says:

    “a program for the systematic monitoring and evaluation of the various aspects of a project, service, or facility to ensure that standards of quality are being met”

    So, QA is the overal process or program that could include testing as a monitoring activity. Fantastic!

  5. Posted by Geoff Loken on 19.09.13 at 8:06 pm

    I think that framing and linguistics are extremely important in the world. The metaphors and models that we use to understand the world help shape it, and our job titles communicate our role to managers, developers, and everyone else we work with.

    With that said… I personally don’t care overly much. My title is QA, and in my organization that has a bit more weight than Testing would. The people situated to understand the difference don’t care about my job title and call me a tester anyway!

    I think it is a discussion that organizations like the AST should be fostering, and are, so I’m glad it’s happening. It is though probably part of a larger conversation, about what the role of testing is.

    Wade says: As an active member of AST, I feel this post is a part of that larger conversation. As people continue to comment and talk about it, the conversation gets larger and hopefully causes this conversation to have an actual impact on the real world.

    I am really curious what you mean by the title of “QA” carrying more weight. What do you mean by weight in that context? Do people give more credence to the information you provide? Are you allowed more freedom over how you obtain that information? Are you invited to the right meetings, or better parties? I can imagine lots of “weight” that the title QA could give you, but I’m curious how that applies in your situation.

  6. Posted by Alex Bantz on 19.09.13 at 8:06 pm

    I am not sure QA carries any more weight than Testing would or should. Of course it could carry more weight but what type of weight is it? More weight could be misplaced, misunderstood, etc. thinking in physical human form, the extra weight could be muscle of it could be fat.

    In my organization our titles are Software Quality Engineers so at least the Assurance part is out there, but the team is still the SQA team. I am not sure will get full support to move all the way to Software Testing Org (or some variation), but getting is rebranded to Quality Engineering would be a start and compromise I could live with.

    I think most in product development understand testing is what we actually do, but on the client side they see QA as the department and any issue a fault of the “Quality Assurance” team, not the Prod dev team/process as a whole. So can lead to team getting a negative reputation they may/may not deserve.

  7. Posted by The Confidence Thing | Tester Vs Computer on 19.09.13 at 8:06 pm

    […] a post about this topic, blogger and test manager Wade Wachs has this to say: …testing is done to build confidence in […]

  8. Posted by software quality assurance on 19.09.13 at 8:06 pm

    I think, Quality assurance is a way of preventing mistakes or problems in software testing. Very informative post. I am looking for software testing company which offer software quality assurance and outsourcing services with best solutions, related to software testing .

  9. Posted by nike free on 19.09.13 at 8:06 pm

    I think most in product development understand testing is what we actually do, but on the client side they see QA as the department and any issue a fault of the “Quality Assurance” team, not the Prod dev team/process as a whole. So can lead to team getting a negative reputation they may/may not deserve.

Respond to this post