|
|
| You are here: Home > About Us > Quality > Measuring Quality |
Measuring Quality…
by Mushthaque Ahmed, JIN Quality Assurance
How do we measure the quality of software? How do we devise an acceptable "ruler-scale" that measures this critical
aspect of software?
To come up with an answer, we need to go back to examining the reason why any software
development happens at all. Assuming that a need is urgent enough to warrant the production of software, it should
follow that the principal focus of any software quality definition should be the users needs or conformance to user
requirements. How does one distinguish between user requirements, needs and wants and ensure a consistent
measure of quality? To measure the quality of software, one must recognize its hierarchical nature. The key then
is: who are the users and what is important to them?
First, a software product must provide functions of a type and at a time when the user needs them. If it
does not, nothing else matters. Second, the product must work. If it has so many defects that it does not perform
with reasonable consistency, users will not use it regardless of its other attributes.
If a minimum defect level has
not been achieved, nothing else matters. Beyond this quality threshold, however, the relative importance of defects as
well as of usability, compatibility, and functionality depends on the user, the application, and the environment. Apart
from this, parameters of satisfaction deal with the product’s Ease of use, Understandability, reliability,
error-tolerance, operational efficiency and convenience. In a broad sense, the users' views of quality must deal with
questions like "Will it run on this platform” or "Will it run the planned applications, and handle the required files"?
To a typical user, issues like convenience, navigation ease, and access to help are very important. The product’s
level of (consistent) responsiveness and ability to provide non-intrusive security are often more important than just
raw speed. While priorities will vary among users, quality has many layers, and no universal definition will apply
in every case. If your software does not measure up in any single area that is important to your users, they will not
judge your product to be of high quality.
When the quality of the parts of a software system is poor, the development
process becomes fixated on finding and fixing defects. The magnitude of this fix process is often a surprise. As a result, the
entire project becomes so preoccupied with defect repair that more important user concerns are ignored. When a project
is struggling to fix defects in system-test, it is usually in schedule trouble as well. The pressures to deliver become so
intense that all other concerns are forgotten in the drive to fix the last defects. When the system tests finally run,
everyone is so relieved that they ship the product.
However, by fixing these critical system test defects, the product
has reached only a bare minimum quality threshold. We only know that the product is minimally usable or installable.
In today’s fast-paced software development environment, there is a critical need to perform testing more thoroughly
and quickly than ever before. Because the project's development team has been so fixated on fixing defects, it has
not had the time or resources to address the issues that will ultimately be of greater concern to the users. Performance,
flexibility and functionality have to be identified and cross-verified against pre-defined user-metrics.
The quality of the
product and the process thus go hand in hand. When a product is (prematurely) tested without having gone through the
rigour of a disciplined design and development process, it generally means the development process could not be
completed on schedule or within the committed costs. Conversely, a poor-quality process will generally produce
a poor-quality product.
|
|
