In opposition to my idea that software testing should be a role, and not just a task, I am sometimes told that True Agile does not permit this. Why? Because, in Agile, “quality is everyone’s responsibility.” This statement is sometimes issued as if it were a moral truism that is beyond argument. Or sometimes as a moral achievement that, unique to Agilists, as if it had never occurred to earlier generations of software developers to help each other build nice things.

Either way, it doesn’t make sense to me.

The first response that comes to my mind is “I’m talking about testing, not quality. Why are you dragging quality into this?” Testers do not assure quality. Testers CANNOT assure quality. Testers do not now and never have “owned quality” in any way.

But even if we set that aside, quality should not be considered “everyone’s responsibility.” Here is why I’m concerned about that phrase:

Chain Analogy

What does it mean for everyone to be responsible for the same thing, such as quality of a product? Consider a chain. If any link in the chain breaks, then the whole chain is broken. Furthermore, each link has the same exact job. Therefore, each and every link in the chain has equal responsibility, in a sense, for the integrity and performance of the entire chain. But, crucially, in a chain, no one link can answer for any other link. In a chain, the links do not talk to each other (other than to exert a force on its immediate neighbors) and no link makes another link any stronger.

Applying this to a software project, the chain interpretation would mean that each person answers only for the quality of their own work and not for the quality of anyone else’s work. In this scenario, no one even looks at the quality of the product as a whole. That is a weak system for obtaining a quality product.

By the chain analogy, anyone can be responsible for some sort of quality problem, but not everyone will be responsible to the absence of that problem. Those most you can say would be that everyone contributed to the quality of the final product.

Total Redundancy

Maybe the phrase means that any single person on the team embodies all of the know-how and effort to obtain a quality product. Each person on the team redundantly backs up each other person in terms of any quality creation, analysis, and remediation process. Each team member tests the entire product and reaches an independent opinion, which is then compared with each other team member until a full consensus is achieved.

In such a process, if you tapped anyone one person on the shoulder and asked for an explanation and defense of the entire test process for the whole product, they could tell you everything confidently and without hesitation. If you were to tap any other shoulder and get their answers, the answers would be reasonably consistent. Furthermore, each team member would have the same depth of answer and express a similar quality standard.

I once spoke to a colleague who had served on a submarine. He said every single crewman was trained to react to fires immediately and to take full responsibility for putting them out. That kind of sounds like a total redundancy system, in that respect.

In software projects, it’s possible, and even feasible to achieve this kind of responsibility for quality in a two or three person team of close-knit co-workers. Michael Bolton and I operate this way in terms of our testing classes that we both teach. But, I don’t think it can work beyond that. I certainly have not ever seen quality assurance and testing handled that way in a medium to large team.

Herd Responsibility

One interpretation I have seen in real projects is that “everyone is responsible” means no one person ever has to do anything or answer for any quality related thing. Instead, all questions are referred to “the team.” Quality issues may only be debated among the entire assembled team.

This is a perfect inversion of responsibility. Under this theory, no one ever has to think about quality, because no one will ever be blamed for bad quality. The team can be the scapegoat, because nobody on the team is the team.

This it my fear, and explains the defensive and magical way the phrase is deployed (similar to “Expecto Patroneus!”) when I have occasionally challenged someone on the testing practices used in their project.

Weak Redundancy

I’m guessing that good people who claim that everyone is responsible for quality aren’t talking about responsibility at all. They are talking about shared aspiration: We all agree to aspire toward goodness. We all try to do good work. We all help each other do good work. Anyone who sees a problem tries to solve it or get it solved.

This is the chain analogy, but with the different links somewhat supporting each other, too. Sounds good. Aspirations always sound good! But there is no real commitment to quality. Here’s why:

To have a true commitment to quality:

1. Everyone must have the same quality standard. You can’t have people pulling in different ways. This can only be achieved through diligent discussion, debate, and share culture. That’s hard, time consuming, socially risky work.
2. Everyone must have sufficient knowledge of quality. That means either everyone must test everything, or some people test some things and share that knowledge effectively with the others. The problem with this is that good testing is hard. Some people have more enthusiasm for it than others.
3. Everyone must have control over product quality. Without control, commitment is meaningless. What happens when team members come into conflict over control? The only way they will avoid conflict is by having the same skills and judgements (which is hard), or by separating into different spheres of work within the team, which means no one has control of everything (therefore everyone is not equally responsible for quality).

One way that teams get around the problem of testing without testers is to have an unspoken agreement to pursue only shallow testing. They write and automate simple test procedures, then simply decide that passing those simple checks means that the product is good.

My Recommendation: Abandon Collectivism. Embrace Personal Responsibility. Establish Clear Roles.

If you want excellent quality, then you must localize and personalize responsibility. You must do this in a way that minimizes conflicts of interest. Testing (dedicated to finding trouble) conflicts with the development (dedicated to ending trouble).

• Each of us must know our own job and do it well.
• Each of us must know what our team expects from us.
• Each of us must know our role within the project.
• Any difficult or unpopular activity must be matched to a defined role (or else it simply won’t be done well).
• Software product quality as a whole should be considered the responsibility of the people who control the software project.
• Quality of any given piece of a product should be the responsibility of the person who builds it.
• Systematic software testing should be the responsibility of people dedicated to that challenging process.
• Each person on the team is responsible for providing reasonable support to all other members of the team.