Look up some definitions on what âQualityâ is and share your own definition on The Club
At the risk of doing a shameless plug for MoT. I thought Iâd get the ball rolling by sharing how David Greenless defines quality in his recent article on Quality and testing:
âQuality is value to some person who matters at some point in timeâ.
I really like this because not only shows that Quality is subjective based on the end-user or business, but that it changes over time. For example, an Ad company quality criteria is that their ads are being directed at the right person, but once that is in place and working, their criteria may change more towards caring that the ads look nice.
Itâs a tricky thing to define quality and I expect there are going to be some interesting posts to discuss. P.S. If you want to ready more, check out the article here:
âMy notion of quality comes from Jerry Weinberg: âquality is value to some person(s)â (Quality Software Management, Vol. 1: Systems Thinking; also available as two e-books, âHow Software is Builtâ and âWhy Software Gets in Troubleâ). James Bach and I have added âwho mattersâ to make explicit some of the things that Jerry presents in the book. When you think of quality as âvalue to some person who mattersâ, it should be absolutely clear that evaluating the quality of something starts with a decision about whose values matter.â
I am with Luke on the idea that Quality is between a person and a thing. Though it could be between a person and a person/s also. So, it comes from everybody within, to strive for excellence in their work, and as a team.
Quality is in the eye of the beholder. The engineers who use our very basic looking engineering screens donât care Too much that the screens are not great. As long as they can get the job done and work around the bugs (that do get fixed eventually; just at a lower priority). Compared to the competition, that the engineering screens exist at all is considered a good thing :-/.
End user interfaces, on the other hand, have to be slick and as bug free as we make them.
âDevOps astonishingly enables us to simultaneously improve organizational performance, achieve the goals of all the various functional technology roles (e.g., Development, QA, IT Operations, Infosec), and improve the human condition.â
While I really like this, and variations of this, it gets difficult when I apply this definition to a context.
Take, for example, a rock. This is a nice round rock. It is not very heavy, I can pick it up with one hand. I am the owner of this rock, as I found it at the river. Itâs pretty (to me, I like rocks), so it would hold value as a decoration, or maybe a paperweight. But I really want to skip the rock across the river. So while the rock would hold value to me in some context, right now, it holds no value. Round rocks just donât skip very well.
This is where a lot of defnitions of quality fall short. The idea of quality can change from project to project, product to product, left to right, and on days ending with âyâ. In other words, as Luke saysâŠ
I believe quality is not a thing , itâs about the value that a product generates to itâs costumers and users.
You can have a product that meets all the requirements but it generates no value to anyone.
the standard of something as measured against other things of a similar kind; the degree of excellence of something.
I would also suggest that one can measure against things of dissimilar kind. And I love that it is relative. It fits nicely into the narrative that a bug is a disagreement between software behavior and stakeholder expectations.
The tricky part is âqualityâ is used informally to mean excellence or of good quality. I fight against this as Iâm trying to measure the quality - good, bad, ugly.
No, it most definitely does not. If quality meant a perfect product, it would be impossible to ever achieve, because perfection doesnât exist. Itâs only a theoretical goal, an ideal to strive to, not something you can actually achieve.
Quality on the other hand is achievable.
I do agree with everyone else that quality can be subjective/relative.
I especially liked how @pmichielsen put it, because quality is not always tangible, but something implicit or even intuitive.
That said, as a product team, you can absolutely create a list of criteria or attributes that define the level of quality your team is trying to achieve and maintain.
So while quality in general is not a list of attributes, it can made into one in specific cases.
But I tend to disagree that quality can change over time.
Itâs just the focus or object that changes. To take that example of the ad company:
Their quality criteria for ads being directed at the right person are still valid even after they switched their focus to the look of the ads. Because the level of quality of the former still needs to be maintained. Otherwise a âchange of qualityâ as proposed would mean their ads would start being directed to the wrong people while looking prettier than before.
Keep in mind that, once a desired quality of something has been reached or improved, it doesnât mean you can forget about it. That is - apart from improving quality, of course - the essence of quality assurance.
While developing new features, you always have to make sure the quality of existing ones doesnât drop. Because software is a complex system in which one part can directly or indirectly influence the other.
This is certainly an interesting topic/discussion!
And I really enjoyed that article, thanks @nilanjanb.
That whole concept of ânot qualityâ pretty much represents my experience. It might be difficult to define quality, but itâs pretty apparent and easy to point out the lack of it in a product.
So defining things around ânot qualityâ might actually be the better approach.
Iâve written a blog post with some of my ideas about what quality is.
Here are some definitions that I came up with:
Quality is perfection, which we must aspire to achieve when developing an application.
The level of quality is the progress that has already been achieved in our attempt to achieve quality. Our aim is to continually improve on the level of quality that has already been achieved.
A satisfactory level of quality is decided by the business, and based on the needs of the user.
Quality may not be achievable, but that doesn't mean we should not try and achieve it. We should keep moving closer to that level while there is still demand for it.
