02/24/2016
in Quality
Understanding Software Quality
Table of Contents
People often talk about high quality software products, but what is that? How can you measure or compare the quality of an application? Let’s take a closer look at this topic and discuss what quality is all about and how it can be improved.
What is Quality?
How can you claim that a software product has a high quality? Because the application has a high availability? Or because the users are highly satisfied with it? Is it because of the price? Or is a bug-free application the key to high quality? Everything could be right, or it could be a combination of all those aspects.
There are a lot of different aspects to take into consideration and everybody seems to have a different focus and an individual emphasis on criteria, therefore we can agree on the fact that quality is somehow intangible. However, since we want to deliver high quality products this is not enough, we need a clear definition of quality.
Let’s try to take a step back and look at the ISO definition of quality, because that might be a good starting point for our examination. “(Software) quality is the degree of conformance to explicit or implicit requirements and expectations.” This means that you have to compare the final product with the underlying requirements to determine its quality.
Requirements and expectations can be brought up by everyone who is interested in the project or product (i.e. all stakeholders). By talking to these people you can find out what they expect the product to be like. The challenge is to find out all requirements and expectations as early as possible and to write down their concrete characteristics. Only if they are written down it is possible to determine the conformance, quality, in retrospect. It’s not possible to determine quality in advance, you can only set goals that you want to achieve. To get a better understanding of the definition we’ll take a closer look at the different aspects.
Requirements vs. Expectations
Depending on the source, a demand can either be a requirement or an expectation. Normally requirements are driven by external influences like rules of an organization or technical prerequisites whereas expectations are personally driven. A demand could be that the application meets the corporate identity of the company. In addition to that there can be expectations towards the look and feel of the product. Therefore requirements are often more objective whereas expectations can vary slightly from person to person, which makes them harder to determine. The important thing about requirements and expectations is that they need to be measurable. It is not enough to demand a high availability. It is necessary to specify a value for the availability of the system (e.g. 99% per year). Otherwise it won’t be clear whether the demand is met if an analysis shows that the availability is at 98%.
Requirements and expectations can also be distinguished as functional (e.g. a special functionality like login/logout) or non-functional (e.g. the reaction time of the application). No matter what type the demand has, it is important to determine acceptance criteria in order to make it measurable.
Explicit vs. Implicit
The difference between explicit and implicit demands for an application is that explicit ones come from high level positions like organizational rules. For example “The application needs to handle authentication via SSL 3.0!”. Implicit demands on the other hand are implied in statements like “The application shouldn’t be too slow!”. Several stakeholders might say a similar sentence, but “slow” might have a different meaning for each of them. Therefore it is necessary to write those statements/requirements down and to add values (acceptance criteria) to it. This makes them measurable (e.g. “The application has to respond within 0.5 sec to new input.”). This measurable value will lead to a discussion between the stakeholders and in the end everyone will agree to a certain value and it will be possible to check the conformance of the application with the requirement. Often an implicit demand can lead to several acceptance criteria. Sometimes people don’t even know about all their demands at a certain time, because they think that the demand is obvious and it’s therefore not worth mentioning. It’s the big challenge to find out those demands since they will come up inevitably at the end of the project and then they will result in a last minute change (or in a low quality). In general, it is very likely that requirements are explicit and expectations are implicit.
Conformance
This is the core part of quality: the conformance of the resulting product with the initially determined requirements and expectations. Hence, it is essential to have measurable acceptance criteria to test the application against. Without measurable criteria it is extremely difficult to determine the quality. The criteria can be concrete numbers (e.g. 99% availability) or yes/no (e.g. login is possible). If it isn’t possible to define a concrete criteria it is important to describe the demand in as much detail as possible and to involve the customer as much as possible (e.g. the application has to respond to new input within 0.5 sec and the changes are being displayed within 1 second on the users screen. Assumed that the user has an average internet connection (16.000 Mbit/s).) With descriptions like this for acceptance criteria it is possible to proof that the specification is met.
Quality in software development
So what are the characteristics of quality? Is it the availability, number of bugs, price or performance of the product? Even after the examination of the definition of quality it is still a term that is very difficult to determine, because everyone has a slightly different understanding. To compare the quality of a product it is necessary to have measurable requirements. Otherwise a clear basis for the determination of a products quality is missing. Hence there are three things that you have to consider:
- Talk to stakeholders as early as possible to learn their requirement and expectations for the product.
- Write down the requirements.
- Find measurable acceptance criteria for the requirements.
When you do this you can always show that your product meets the specifications and the quality can be determined. On this basis we will give some examples of measures that can be taken to improve the quality in software development projects in the next post.
