Testing is not necessarily a team responsibility

Nowadays, it is more and more common to agree that quality is a team responsibility. Something I don’t argue with at all.

As a consequence, we might also concur that quality assurance must be a team responsibility. So far, so good.

Thus, it looks like testing too has to be a team responsibility, doesn’t it?
No, not necessarily.

First of all, because testing is not quality assurance.

Secondly, because, considering that not everybody is skilled at coding, likewise not everybody is skilled at testing.

Last but not least, because, as obvious as it gets, testing falls under testers’ responsibilities.

Let’s go a little deeper into these points.

testing is not quality assurance

Let’s assume we are talking about an Agile team which is working within a Scrum framework, for example.
To me, in this case, the concept of quality assurance has definitely more to do with the team’s definition of done than with their testing activities (if any).

After all, what the team can assure is, for example, that they have performed code reviews and they have followed the standards they agreed upon, that all the requirements are linked to test cases —nevertheless, I wouldn’t rely too much on a traceability matrix—, and, at most, that all their (likely automated) checks (that is, the mechanism the team has in place to demonstrate that the product they are building does what it is expected to do) pass and the corresponding acceptance criteria are fulfilled.

As brilliantly pointed out by Michael Bolton, “the trouble is that people often assume that demonstration is all there is to testing; that checking and testing are the same thing. They’re not.”

In fact, (automated) checks have nothing to do with real testing, that is, the act of exploring a system to learn how it actually works and under which circumstances it might fail.

Which leads to the second point under discussion…

not everybody is skilled at testing

According to my experience, the average programmer is usually more skilled at and focused on proving that their code does what it is intended to do, than on investigating how it might not work and on making sure that it doesn’t do what is shouldn’t do.

In other words, should a team only be composed of programmers, they might not be performing any (real) testing at all.

So, how could testing ever be a team responsibility?

Which leads to my last point…

testing falls under testers’ responsibilities

If you agree that programming falls under programmers’ responsibilities, it shouldn’t be hard to understand why the same rationale is to be applied to testing.

The problem is most people still confuse testing with quality assurance, to such an extent that they wrongly call testers QA.

The funny thing is that, at the end of the day, quality assurance has more to do with programming and management than with testing.
So, if anybody should be named QA, they should rather be the programmers or the managers*.

By the way, I find it interesting that, when thinking about quality assurance, the first person who comes to mind is never the one who sets the quality standards.
None among project managers, product owners or delivery managers seem to take the hint either. How come?

All in all, how about making concepts and responsibilities clear for everybody and letting testers do their job?

#ThisIsASeriousLackOfTestingMindset

(*) Please, the next time someone talks about a QA or, more specifically, about hiring a QA, try to envision a programmer or a manager fulfilling that need. I can assure you that it might be fun…