Who is responsible for quality? Is it the tester, or the team?

I have been reading John A. Dues’ new book Win-Win W. Edwards Deming, the System of Profound Knowledge, and the Science of Improving Schools with the Deming Profound Book Club. John Dues uses an equation to describe who is responsible for student performance[1]. This equation works as a useful analogy to describe who is responsible for quality.

There are development teams in which the tester is held responsible for quality. The tester is responsible for their work, which will affect quality, but quality results from the output of more than one individual’s skills and efforts. The factors that affect quality can be described in the equation below:

A + B+ C + D+ E + F = quality

If F represents the tester’s contribution to quality, what is the value of F? (what is the contribution of the tester?) We can’t give a value to F until we know the values of A, B, C, D and E.  Factors that affect quality, are not controlled by the tester that could be represented by A, B, C, D and E include:

• The quality of the documentation of the feature being tested
• The time available for testing
• Which team the tester is a member of 
• The choice of which feature is being worked on 
• Unit test coverage
• Annual reviews system

Should the development team be responsible for quality if the tester does not control all the factors determining quality? The team controls more factors than the tester. This could be described in the equation below:

G + H + I + J + K + L = quality

If L represents the team’s contribution to quality, what is the value of L? (what is the contribution of the team?) We can’t give a value to L until we know the values for G, H, I, J, and K. Factors not controlled by the team that affect quality that could be represented by G, H, I, J and K include:

• Team structure, such as does the team have a designer or product owner.
• The team’s training budget
• Deadlines for the release of the feature
• The company’s ‘social circuitry’, that is its ‘overlay of the processes, procedures, routines and norms’. [2]
• How the team’s performance will be evaluated

Neither the tester nor the team controls all the factors that affect quality so we should not blame a person or development team for an issue with the quality of the application under development. However, for a problem with product quality to be addressed constructively, the tester and the team should act responsibly. They should work together using a technique, such as the Five Whys, Ishikawa diagrams or a blameless post-mortem, to learn from the issue related to quality without blaming a person or team so that they can prevent the problem from re-occurring.

Thank you to Rob Park and the Deming Profound Book Club for helping me organise my thoughts.

References

[1] Win-Win W. Edwards Deming, the System of Profound Knowledge, and the Science of Improving Schools by John A. Dues (2023, p304)

[2] Wiring the Winning Organization by Gene Kim and Steven Spear (2024, p29) by Gene Kim and Steven Spear (2024, p29)