It’s a matter of responsibility for quality

Often times, testers get blamed when a bug makes it to production.

“Who tested this? Who left this untested? How could this happen? Where was the QA?”

I’ve seen several cases in which a tester ends up being questioned if they tested something or not. Then, to defend him or herself, he or she generates a document with screenshots filled with evidence of when he or she tested, with what data, in what environment, etc. just to be able to say, “When I tested it, it worked. If it doesn’t work in production, then it’s on somebody else.” This turns into an expensive and futile endeavor that doesn’t add any value to the business or the user. When people within an organization have to spend time and energy defending themselves from internal threats, they will have less time and energy to focus on the user’s needs and important business opportunities.  

Quality is the team’s responsibility, this is part of the Agile philosophy.

The questions above aren’t aligned with the values nor with the principles of Agile. If we continue with the traditional software development mindset, which generates conflicts of interest between devs and testers (devs build and testers destroy what was built), we will not be able to take advantage of the real benefits of agile methodologies, which occur when a team acts as one and works in unison.

In a talk I gave last year with Gabriel Montero from Peregrinus, a partner of Abstracta, at the Argentesting conference, we discussed this topic and shared this picture below. Someone had told me it reminded them of a manager they once had who wore a similar expression, accusing them of not testing enough when a bug made it to the users.

What Does Software QA Mean?

So what does QA mean? As you know, it stands for quality assurance.

If we present ourselves as “the team’s QA,” we’re demonstrating that we believe we’re the ones that assure/ensure quality and we are going to own those mistakes.

One of the things that testers have to change in our area, to be aligned with an agile mentality, is to stop thinking of ourselves as “QA.”

We are not the ones to determine if the quality is satisfactory before moving forward with a release.

In a recent TechWell Interview, Michael Bolton, principal at DevelopSense and the co-creator of Rapid Software Testing, expresses his view on the matter as well, which is in line with our sentiment:

“It’s very strange, very strange that a tester, a tester, should sign off on the quality of a product. It’s like an investigative reporter signing off on the decision of the electoral college. That’s not how the distribution of responsibility should be in a business.”

We are testers. As testers, we do testing.

What is Software Testing?

Software testing is a process in which we provide information about the quality of a product, for someone who is interested and who is going to do something with that information—someone who is going to make a decision.

For example, we can provide the information to a manager, or to the CEO of the company who has to decide whether to put the latest version into production or not. Or, they may decide to postpone the launch to do more testing, or to take some time to fix the known bugs.

What does that person need to make a good decision? They need to know:

• What incidents were found,
• what was tested,
• and what was left untested.

Only in this way is it possible to make a decision based on risk.

I insist that we should stop calling the tester’s role “QA” as we should not take any responsibility that does not correspond to us. We should use a more “safe” language.

Instead of sending a report and saying, “The software has no bugs, it can be put into production,” try saying, “According to the tests carried out, we did not find anything that tells us that we should not go into production.”

We have to start the change with ourselves first, and then we can start asking the questions that really matter. Instead of searching for whom to place the blame, team leaders should organize a retrospective analysis to understand how things are currently being tested.

We Are Not a Software Quality Assurance Company

With all of this said, at Abstracta, we are not a software quality assurance company.

(As a disclaimer, we do have some marketing web pages that use this kind of language, because most people still view what we do as software QA. We’re on the mission to change that!)

We are a software quality engineering company.

Our software quality engineers (see this infographic about the term, QE) will be your dedicated software testers, working side by side with you. We will help you to improve the quality of your software, ship on time, and reduce risks and costs. But, we will never own the role of assuring the quality of your product.

There is no such this as bug-free software, but there is software that meets stakeholders’ expectations for its functionality, performance, security, etc.

What’s your take? Have you been in a situation where the title of being a QA negatively impacted you on the job?

Recommended for You

[Infographic] What is a QE?
How to Get Started with Outsourced Software Testing