You might have noticed that this blog never had a kickoff post that explains what this blog is about. Time has come to spend some words on the topic of software quality—as I see it—and how this blog covers some aspects of software quality.

First of all, I’d like to introduce the two most frequently considered software quality aspects:

Correctness

The software must produce correct results. There is no point in using software, which produces results that you need to verify before you can trust them.

Usability

If you know the task you want to perform, the software should make it easy to do so. Frequently used functions must be easily accessible and allow to complete the task in an efficient manner.

These two aspects belong to the functional cluster of software quality. Today’s software industry has a rather high awareness for these issues—I guess because users complain immediately otherwise.

The industrialization of those aspects becomes evident when looking at the supporting industries. As of writing, Google shows 8 sponsored links for “requirements engineering tools” and countless software testing tools. There are even education programs to certify software testers.

On the other hand there are also aspects that belong to the technical cluster of software quality.

Performance

On my business card, I use the following definitions:

Short response time for a given piece of work.

Low utilization of computing resources.

Please note that testers can observe the effects of the first definition. Sometime performance issues become that bad that they become a usability issue. There is a certain amount of industrial support for performance available.

Reliability

On my business card, I use the following definition:

The probability of failure free operation of a computer program in a specified environment for a specified time.

The majority of reliability issues are system crashes and system hangs. They are typically caused by memory leaks, deadlocks and race conditions.

At this point, industrial support becomes sparse. Reliability issues are usually very hard to reproduce and they often remain unsolved for a long time. The first signs are often regarded as one-time events that are not taken seriously. However, these are the opportunities to handle the problem before it becomes unmanageable. Unfortunately reliability issues are easier to debug once they occur more often.

Maintainability

On my business card, I use the following definition:

The ease with which a software product can be modified in order to correct defects and meet new requirements.

The users of a software product can not directly observe maintainability issues. There is, however, one sign that can be observed from the outside and might indicate maintainability issues: the time to market. If a software vendor can quickly adopt the product for new requirements, it is usually a good sign. The opposite conclusion doesn’t hold true because the vendor’s priorities might favor other issues at that time.

Although there are tools to automatically calculate maintainability metrics, I believe the most efficient way to improve maintainability is a review by knowing eyes.

Scalability

On my business card, I use the following definition:

The property of a system which indicates its ability to handle growing amounts of work in a graceful manner.

Scalability is related to performance. Many performance testing tools can be used to analyze the application’s scalability. The key difference—from my perspective—is that performance questions tend to focus on current load scenarios while scalability questions focus on future business development.

There are some more software quality topics. You probably noticed that there was not a single word about security. The reason I didn’t list security is that this area is way to wide to be properly covered by a one-man business like mine.

So, the four technical software quality aspects performance, reliability, maintainability and scalability are my primary area of interest and work—and therefore also the topic of this blog.