Sequel: Software Quality Assurance for the PTV xServer (2)

What exactly do we mean by quality?

There are many answers to this question, unfortunately all very different. The naïve answer is “the product has practically no faults“. This answer is wrong, or at best incomplete. An empty program is probably as faultless as any program can be, but of very little use. Many successful software products have lots of bugs, but that did not prevent them from becoming a success.

Since a no-fault state is not the answer, let’s try “offers the functionality that I need” for size. Well, that is not the full truth either: a slow program is often just as inacceptable, as is a program that does not run in the customer’s environment, or is hard to use.

Okay, here’s another attempt: “quality is when the customer returns and the product doesn’t“. Taking the perspective of the customer is indeed a smart idea. However, it is notoriously difficult for engineers, who build products they do not use regularly themselves and really cannot use the way customers would since they make wrong assumptions about their use. Fortunately, matters are a bit easier in the case of our developer components products, as engineers know fairly well what other engineers would expect and like, what they can tolerate, and what is a no-go.

One thing that engineers really like are helpful standards, and one of them tries to answer our question in a very constructive way, namely the ISO 25010 Software Product Quality Model. It covers all the criteria we have already met, such as functional completeness, functional correctness, functional appropriateness, as well as all those we might wish for, such as performance, compatibility, usability, reliability, and so on. But not all these criteria are equally important for every type of product, and some of them may even conflict.

Frequently observed conflicts typically include: We need feature X. Okay, let’s integrate it. But that would reduce overall performance. So let’s introduce a switch to turn it off. But that would bloat the interface. Okay then, let’s make the switch optional and activated by default. But turning it on by default would violate compatibility with the old client code.

In the end, we face a choice: in this case between functionality, efficiency, simplicity and compatibility. These kinds of choices can be hard, but are necessary. Good product quality comes from good choices.

Don’t miss the next article on “How do we achieve quality?” which will be posted next week. Enjoy reading!

Further parts of our new series of articles: