Interpreting ‘quality’ in more than one way helps me uncover issues
Each project has different requirements, and each set of requirements makes its own demands on ‘quality’. On every project I work on, I find it useful to interpret ‘quality’ in more than one way.
Interpreting quality is more helpful than defining it. A definition is definitive whereas you can have many interpretations. It is useful to see things from more than one angle. Using more than one interpretation of ‘quality’ helps diversify how I test each project.
“How one interprets the word ‘quality’ is important”[1]. How I interpret ‘quality’ affects how I test because when I am testing I look for issues covered by that interpretation of ‘quality’. I use more than one interpretation of ‘quality’ to help me test the project I am working on. Each interpretation pushes me to test differently and so uncover different issues.
“There is little agreement on what constitutes quality”[2]. Many senior figures, who have had significant careers, have had quite different interpretations of ‘quality’.
The table below contains various interpretations of quality and how they affect my testing:
| Interpretation of quality | How does this interpretation affect my testing? |
| “Quality can be defined only in terms of the agent.” Out of the Crisis by W. Edwards Deming (1986, p168) | This helps me think about who is using the application I am testing. They are agents so they have agency and I can think about who is using the application, and how and why they are using it. This interpretation helps me understand that quality is subjective because each agent will view quality differently. Thinking about the agents helps me to test from the perspective of different users of the application under test. |
| “A thing has qualities, not a quality” Economic control of quality of manufactured product by Walter Shewhart (1931, p56) | That an application has qualities, not a quality enables me to break down what quality is into quality attributes for the application under test. This helps me review what I have tested and find new areas to test. |
| “Quality is the loss a product causes to society after being shipped, other than any losses caused by its intrinsic functions” Introduction to Quality Engineering by Genichi Taguchi (1986, p2) | If, when I test, I consider the cost of product failures to others, I am considering the impact of product failures on society. An example of the loss to society would be the cost of customers’ time due to an outage. To help prioritise my testing I can consider which failures would affect customers, the company I work for, or wider society. |
| “An article with good quality performs its intended functions without variability” Introduction to Quality Engineering by Genichi Taguchi (1986, p2) | If there is variation in quality the customer will experience bad quality, for example, if page load time varies sometimes the load time will be too slow, This interpretation of quality helps me think about which aspects of product quality, I can measure to understand quality, an example would be performance. |
| “We must define quality as ‘conformance to requirements’” Quality is Free by Philip B. Crosby (1979, p8) | If I used this definition of quality to help me test, I would miss issues not covered in the requirements. This interpretation of quality is a reminder to test more than ‘conformance to requirements’. In addition to testing the known requirements, my testing should help to discover overlooked and emergent requirements[3]. |
| To achieve quality at speed you need: Excellent, rapid feedback Superb, detailed discipline Implementing Lean Software Development by Mary and Tom Poppendieck (2007, Chapter 8 Quality) | This interpretation of quality makes me think about my and my team’s work. I need to give good feedback and so does my team. Also, my team and I need to be focused and disciplined in how we work. |
References
[1] What is Total Quality Control – The Japanese Way by Kaoru Ishikawa (1985, p45)
[2] Kaizen: The Key to Japan’s Competitive Sucess by Masaaki Imai (1986, pxxiii)
[3] Agile Requirements Gathering: Three Types of Requirements by Mike Cohn (2020)