QA: The Misnomer That Never Dies

Quality AssuranceOver the span of my testing career I don’t know how many times I’ve had this conversation, in its many forms and permutations. The good old conversation about testing vs. quality assurance. The conversation we (software testers) have about not being ‘quality assurance’ professionals. That we cannot assure anything, least of all quality. Testers can assure quality as much as a doctor can assure health. Imagine the conversation:

[Patient] So doc, now that I’ve done my yearly checkup, can you guarantee I am entirely healthy?
[Doctor] Well, you are healthy, and we checked for all of the most common sicknesses and diseases for someone your age, gender, background. However I cannot guarantee there is nothing else wrong somewhere we didn’t check.
[Patient] But you said you were doing a thorough checkup.
[Doctor] And I did.

You get the idea. The doctor takes what we testers may call a ‘risk-based’ approach to our yearly checkups. He takes into account our family history, background, gender, age, habits and makes a decision on which exams we need, as he couldn’t possibly ask us to do all the available medical exams out there. That could be seen as a waste of time and money.

The same goes for testing. Only that the conversation happens between the Software Tester and the Project Manager, or the Product Owner, or the Dev Lead, or whomever else. I believe that one reason that this still happens is because some testers still insist in calling themselves ‘Quality Assurance’ professionals. How can we possibly not assure quality if that is precisely what our job titles say? I’ve had this conversation countless times with ‘QA’ people everywhere. There is a feeling that being called a ‘tester’ is demeaning, or less important than a QA. A Quality Assurance Engineer once told me ‘but I do so much more than just test’. That may be true, but you still do NOT ensure quality. You just can’t. This is not a new topic, Michael Bolton wrote his popular blog post Testers Get Out of the Quality Assurance Business* over 5 years ago, and it was not a new topic then.

The fact that we, as a community, are still talking about this has to mean something. I’m not sure what yet, but it has to. It could mean that we are talking about this to the same people over and over, or if we are talking to new people about it, the message must not be getting across because by now we’d have made an impact. Maybe we have made an impact, but I just don’t feel it. Confirmation bias? Maybe.

So what can we do? How can we move on to bigger and better conversations? How can we impact the still large part of our industry that believes they can, and do ensure quality? How can we kill and bury this misnomer once and for all? I wish I had the answer to that, but I don’t. I do, however have some suggestions and some things I have been trying:

Keep talking about it

We need to continue talking about the foolishness of the term Quality Assurance when referring to Software Testers. It is not only inaccurate, it is irresponsible. A physician would never call themselves a ‘Health Assurance Professional’. One dictionary definition of ‘doctor’ is a qualified practitioner of medicine. As we are qualified practitioners of software testing, investigation, reporting and communication.

Understand what software testing is [and is not]

There are still so many testers out there that are unable to articulate what they do. I interview a lot of testers, and the answers to questions such as: ‘what is testing?’ or ‘what is the most important skill a tester can have?’ or ‘what does a tester do?’ range from unsatisfactory to completely pitiful. There are a sea of free information about testing out there, read it. And I’m not talking about LinkedIn forums, don’t go there. I’m talking about blogs such as Satisfice and Developsense. Start with this post, and beware, you will need to read it more than once. Read it until you understand it, until you internalize it. Then move on to read as many other blog posts on those sites as you can.

Talk to other Software Testing professionals

When I started to really understand what testers are supposed to do, when I began learning about the craft of software testing, I was all but confused. I was told by the courses and certifications I had done that I was put in a team to assure quality. One way to better understand and clarify such doubts is by having a conversation with experienced practitioners. Do your research first, then approach one of them. They have helped me [and still do to this day] to grow in understanding of our profession, helped me to be better at articulating concepts, theories and how to practice software testing as a professional. If you don’t know how or who to reach out to, contact me.

Do you find yourself having this conversation too? How to you tackle it? Any suggestions on how to stop this madness once and for all?

*BTW, if you haven’t read this post yet, drop everything you are doing and read it. Now. 

5 thoughts on “QA: The Misnomer That Never Dies

  1. Weinberg implies that if you can make changes to the source code of the program you are testing, then you CAN assure quality. So it is possible to be a QA engineer. Discussing what prevents many testers from seeing that would be a bigger and better conversation.

    1. Hi Andrew, being able to make changes to the source code is definitely one of the dimensions of being able to assure quality. However, even if testers are lucky enough to be able to change source code, they may not have the time or budget to do so. I haven’t yet worked on a project where the testers had control over all of the variables that impact quality. Again, I believe Michael Bolton’s post explains it beautifully and I couldn’t articulate it better: The role for us is not quality assurance; we don’t have control over the schedule, the budget, programmer staffing, product scope, the development model, customer relationships, and so forth. But when we’re doing our best work, we’re providing valuable, timely information about the actual state of the product and the project. We don’t own quality; we’re helping the people who are responsible for quality and the things that influence it. “Quality assistance; that’s what we do.”

      1. “Helping the people who are responsible for quality and the things that influence it” encompasses more than just testing, which makes “tester” the misnomer. If quality assistance is what we do, then we should call ourselves Quality Assistance Engineers (and QA for short).

        The ability to make code changes isn’t determined by luck. Getting the time and budget to do things is a normal part of any job. QA can influence schedules, budgets, staffing, scope etc. and as a result does have a degree of control over them. Don’t underestimate what the profession is capable of! Sure, providing useful information is an advancement over gatekeeping quality, but if progression ends there, so will the profession.

        Pulling those lagging behind in the profession up and pushing the profession forward are different things. The former is a job for trainers and consultants, like Bolton & Bach, who do it well. The latter is not a job for them. It’s for practitioners, like you. You said you couldn’t articulate it better than Bolton, but I reckon with some rigorous testing you can. That’s how we move to bigger and better conversations.

  2. Nice Ale. Definitely one for the ‘rat hole’.

    In my experience with Doctors the convo would go more like this…

    [Patient] So doc, now that I’ve done my yearly checkup, can you guarantee I am entirely healthy?
    [Doctor] Yep, you’re all set!

    The Doctor just wants you gone; wants the work to be over so another few dollars can be made. Unfortunately many Testers are very similar and end up saying “Yep, quality is good!”

    Try this… on your current program/project see if you can get a Quality Assurance Assessment done (like, a real one). Then in the kick off meeting ask the Quality Assurance professionals (like, the real ones) if they are doing an assessment on the QA of the program/project or the testing of the program/project. The conversation that follows is often very fun and multiple stakeholders come to the realization that QA and testing are, in fact, different. 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s