Anne-Marie Charrett delivered a beta version of her Testbash Manchester keynote at the Cambridge Tester meetup this week. Her core message was that quality and testing are not the same thing:
- there are non-testing aspects of software development that contribute to product quality
- there are non-product aspects of quality which should be considered in software development.
A theme of the talk was that customer benefit could be threatened by the second of these, by factors such as code hygiene, speed of delivery, and time to recover after a failure in production. Testers, and others in software development, were urged to reframe their view of quality to encompass these kinds of activities. A Venn diagram represented it like this:
Interesting, but it didn't quite hang together for me. I slept on it.
In the morning, I found myself thinking that what Anne-Marie was trying to visualise really had two notions of quality, and they were not the same. Perhaps she could move from a two-way to a three-way relationship between product quality (features, performance, usability and so on), production quality (for the non-product stuff around producing the software), and customer benefit. (Although I prefer business value rather than customer benefit because the business might prefer things that don't give value to the customer at some times.)
Here's how I've tried to sketch that:
But the tripartite division gives other potentially interesting intersections too. There's the traditional new feature which drives an increase in sales (product quality/business value) and then there's situations like moving from weekly to daily drops of a core component to internal teams which removes wasted time on their side (production quality/business value).
Anne-Marie asked for feedback on her talk so I pinged her a few notes along with a sketch of my idea and she incorporated some of it into the keynote.
Which is gratifying and all that but while my model might be considered an iterative improvement on hers, it's not short of its own quirks. The intersection I haven't mentioned yet (production quality/product quality) could be encountered when ancient build servers are replaced, enabling newer libraries to be used in the product, but adding (at least, at that time) no value.
The caveat, at that time, is interesting because it reflects the idea that there's a granularity effect at play. The example just given, at a certain temporal granularity, adds no value. But once new features that build on the new library are implemented, value is added. Zoom out to a wider time perspective and the action of updating the build server can sit in the sweet spot.
There's other ways in which this model is fuzzy: in a continuous deployment world, the boundary in the pipeline between the product and the production of the product becomes harder to define. Also, there's no good way to represent stuff that's actively detrimental to business value.
And there's ways in which our viewpoint (biased to the technical) can distort the relative importance of our interests too. Remember that business value can be generated without any involvement of the development staff: dropping the price of the product might drive sales and increase overall revenue.
Your perspective on the model alters the value of the model. Quality may not be whatever you think it is. Stay humble.
Images: Nick Pass and Dan Billing (via Twitter)
Edit: This post blew up a bit on Hacker News. The views expressed there on what quality is or isn't, the ease with which quality can be achieved, and the notions of quality as subjective or objective distinction are interesting to see. Anne-Marie used Weinberg's definition of quality in her talk and I recently wrestled with that in In Two Minds.
It's so helpful to me to see ways to visualize quality, and this captures so many aspects. Thank you for sharing it!
ReplyDeleteCheers, Lisa.
DeleteI've had a few goes at understanding what I think quality might be. (Or more accurately, understanding what I don't understand.)
Thanks to Lisa for the slides.
ReplyDeleteAnd thanks to James for the post. You are once again fueling my wilingness to write about basic things in testing :-).
Here is how I describe the things to "young testers". https://lazytesterua.blogspot.com/2017/10/expectations-requirements-reality.html
I don't think the quality vs testing meme is presented as in this blog post. Usually quality is pitted *against* testing, i.e., quality is better than testing. In fact, these aren't either or.
ReplyDeleteIn the software industry, Bach-Bolton type testing is almost unknown. The quality vs testing meme is used to justify that.
Discussions on quality vs testing would be welcome, *if* there was a strong understanding of testing. No good tester would argue against overall quality improvement. However, in most cases, quality is offered as a (better) choice. That is incorrect.