I’m not a QA

I’m not a QA

Guardians of the Galaxy Vol. 2, Credit: Marvel Studios

I’m not Groot, I mean QA.

I have a problem when someone labels me as a QA (Quality assurance). First of all, try to decode the acronym and say what your role is out loud. “I’m a Quality assurance”. Are you Judge Dreed from 1995 or something, shouting “I’m the law”.

That’s why you need to tell people that you are QA + something (QA lead, QA engineer etc.) without it, your role sounds silly.

But the main issue is that when you say you are the QA then everyone thinks that you are a one-man army who has the power and can assure that everything will be fine and dandy when the client receives the final product.

Unfortunately, the reality is different. In my opinion, the only way the one person as QA could assure something is when they are their “master and commander”. What I mean is to be their own client, manager, developer, and tester. Hopefully, the issue being labelled as QA is not only my problem, Michael Bolton addressed this back in 2010 and this is still relevant to this date.

One can observe a change in some companies. They even call this acronym differently, because they know that one person or dedicated assurance team is a lie. Thanks to that we have such a role as “Quality Assistance” or “Quality Advocates”. I prefer this title than having an assurance person, but it does not solve my problem.

Without further ado, here is my list of issues with QA as a dedicated role.

Philip J Fry – Executive delivery boy issue

First of all, being a QA somehow gives an employee a crazy idea that he/she is doing something greater than testing. But let’s be honest with ourselves, even being labelled as an assurance role, we are still doing testing and it has nothing to do with assurance (not by its own).

Most job descriptions for QA and testers are the same. Requirements are mostly the same, responsibilities say the same thing, even the salary is not so much different. Is it really that important to have this title?

For me, to be promoted to the QA role is meaningless in most cases. Just to make people happy about themselves, saying that they are doing something better, just like in the Futurama episode about being promoted.

The burden of the crown

Being labelled as a QA in most projects has its own major downside, being the one to blame for poor results of the whole development department/team.

You are the one that is supposed to assure people that things have gone alright. So my questions are.

• Could you swear blindly that everything is fine after each new release?
• Could you gamble your life that there will be no bug encountered by the end user?
  

Most of the times you cannot do it (or shouldn’t). Like I said before, most of the time you are just doing testing or quality control work. Your development team is making new decisions, implementing new changes, reviews, and investigating the problems. Sometimes you are not even the part of the decision-making process or you simply could not be aware of these changes.

You don’t do quality assurance alone. You cannot assure the quality of software or the processes that drive this software alone. So why should you assure on your own? You don’t have the power to do it right now (no one will give it to you in the nearest future).

You shouldn’t carry a burden of being the one and only person responsible for the quality.

Assurance from the start.

Let’s assume why are you hired as a QA role in the new project. What are your responsibilities?

• Testing new features?
• Coaching development team?
• Managing people?
• Creating or updating a quality assurance process?
• Doing quality control?
• Creating or maintaining check automation?

I’m asking because we have a lot of different QA sub roles, like QA Manager, QA software Automator, QA tester and so on. If you want to ask me about a single definition of these roles, I can’t give you that because there are a lot of different job descriptions. Especially when you have different development life cycles and in each cycle, you can have a different mission or responsibility. Closer to the end of the cycle you are, then the problem of defining your role gets bigger.

I’m talking about this, because, you should build a quality assurance process as soon as it’s possible. The best scenario is to do it at the beginning of the development process. Because changing work culture in the existing development process may be impossible, even if the client is ready to spend money on it.

You could have a question right now. “Why should I change work culture in my project?”.

The answer is simple. You need all hands on deck to provide quality assurance. You cannot do it as a single Groot cough cough QA in your development team.

You can give some guidelines or coach about quality in the middle or at the end of the development project, but this will never be quality assurance.

The forementioned process requires work culture change from all parties involved in the development process (developers, testers, managers, clients).

If you want to find easily if you have quality assurance, ask any, of none testing roles in the project if we are ready to ship/release a new product version. If they are not sure, you will know that you are doing everything except assurance.

“We are” before “I am”

Guardians of the Galaxy, Credit: Marvel Studios

Like I’ve said before, you or your QA/testing team/person cannot assure quality alone.

Assurance is something that your whole development team and you need to work for. It requires a culture and a mindset change from everyone. Only a motivated team that sees the goal of change will move towards it. But it takes time and will.

Some forget the phrase “I am Groot” and start to say “We are Groot” if they want to assure something in the software development process.

The quality assurance should be divided between the whole team. Yes, you need a responsible person who takes care of the whole quality process in your team. But the team needs to take part in this process too. “Quality is everybody’s responsibility” right? But don’t call it QA.