Mommy, What is Software Quality?
Viktor Clerc
on 19 July 2021
So, what is software quality anyways? Let’s shed some light on some schools of thought.
Conformance to specifications
Suppose we have a predefined list of requirements for a product, and all of these requirements are verified and validated throughout the process of constructing that product. When we are approaching a release, we can simply demonstrate the green check marks as the results of the verification and validation activities and be happy. We see this happening all over the place in certification-oriented businesses, but also e.g. in road construction works. It has to do with regulations and with compliance. This is the way space shuttles are built.
Conformance to specifications is often perceived as ‘it just works’. The product does what it is supposed to do, so no high praises: we are not discussing the fact that the A1 highway to Amsterdam ‘did it again’. Or that my MacBook didn’t have any hanging programs this morning. Products simply should be built right. And that should be verifiable.
Innate quality
A product is of innate quality if its qualities are overly apparent. If you take a look at a Formula 1 car, everyone without any technological knowledge sees or feels that that car can go fast. Like that cool design of a new car, or the ‘unboxing’ event of a new must-have gadget.
Quality in use
The ease of use, simplicity, user friendliness, a not-so-polluted user interface; all kinds of indicators of products that whet the appetite of users, they want to use it. It is appealing. It is about the promoter score, the stuff you talk about at your friends’ birthday party.
Different stakeholders typically have different perspectives on quality. When the expected quality differs from the perceived quality, problems may occur. Suppose that the new must-have gadget is of a brittle fabric or not too responsive: looks great, works ‘meh’. So the perceived quality is lower than the expected quality. The result? Dissatisfied users. If the perceived quality is higher than the expected quality, the promoter score of that product or of that service is higher, users are satisfied because the experience is unexpectedly good.
Let’s take another look at that Formula 1 car; pretty nice that it can go fast. But it is also up to the driver, the technicians, the accuracy of the pit stops, let alone the team’s strategy to determine whether you will be the Formula 1 champion or just a runner-up. At the same time, the quality of the design and thought process that is put into the Formula 1 car is of high importance before the car gets made.
For software products, this is different: the quality of the design and thought process is important from the very start (conception of an idea and its corresponding requirements) until the time the application is decommissioned.
We need to have software correctly designed, correctly built, and efficiently maintained:
Aside from measuring the technical quality using technical indicators and metrics such as code duplication or complexity, software quality entails a good process and an extraordinary bunch of people. It demands a holistic approach. In subsequent blog posts, we will dive into this holistic approach by further discussing the teams, the delivery process, and the technologies used.