Software quality control seems like a self-explanatory term at first. However, you cannot control what you cannot measure.
“You cannot control what you cannot measure” is a Tom DeMarco quote, a famous author on the topic of software development. It perfectly encapsulates the core principles of software quality control. It’s one thing to say that code runs well but trying to determine why is a completely different ball game. How do you establish what constitutes the quality of a program? Let’s take a closer look.
As we have covered in our separate article on the topic, software quality is the totality of functionality and features of a software product that bear on its ability to satisfy stated or implied needs. It’s a rather vague definition that basically boils down to what the piece software does and how well it does it. Since quality is in a way subjective there have been established three subsets of software quality which are:
Functional quality is responsible for end-user experience and usability. Structural covers the code itself and how well it is written. Last but not least the process quality is evaluating the process of development itself.
Once again we face the issue of subjectivity. What is a “well-written” code? How can the development process be efficient? Can it be more efficient? Is there such a thing as an efficiency scale? This is where metrics come in. They can shine the light of objectivity into the murkiness of the term “quality”.
If you check Wikipedia for a list of qualities you’ll see a page containing a whopping 84 quality attributes and even that is not extensive. Let’s look at a few examples:
As you can see, you can’t really point at one and that it’s not important and doesn’t affect the quality of the product. So what, you must measure every single one of them? It does indeed look like a daunting task. It goes without saying that a software project must meet the standards in all of these indicators. What you need to do first is to establish a system of priorities.
For example, a software project should absolutely be scalable. However, you must first make sure that the code you will be scaling up is doing its job perfectly. You don’t want bugs multiplying in a geometric progression. The same way if a component already resource-hungry, optimize it before scaling up and completely overloading your system.
While they don’t perfectly overlap with the three subsets of software quality mentioned before, we can group up and divide most of the metrics into three groups:
Product metrics describe the characteristics of the software project itself. Some metrics can be easily tracked like size or performance (loading and response times, for example). Others require a reference point such as complexity. For example, customer satisfaction can be measured via regular surveys and reflected in a percentage statistic. These metrics can describe aspects of both functional and structural quality.
Process metrics describe the characteristics of the development process. These include the response time of the bug fixing process, the effectiveness of bug removal, and so on. For example, defect density or number of errors per 1000 lines of code is a metric that can help analyze and optimize the development process. Since the creation of software is, in essence, a system, improvements in one area can result in improvements across the board. If there are fewer bugs to fix, the software quality analyst team and developers need less time to fix them, which increases the delivery times. And that’s just one example. These metrics can describe aspects of both structural and process quality.
Project metrics describe the characteristics of the project. These can include the size of the development team, the schedule of the project, and the budget. The way these metrics reflect on the quality of the project should be obvious. If there are more people allocated to a project it will most likely have more features and/or be ready for release sooner. A bigger budget also allows the developers to invest in higher-grade development tools, for instance. These metrics almost exclusively describe aspects of the process quality.
If you can measure these attributes, you can assess the quality of the software. The project manager will help you to use these metrics correctly.
While there is no question about the importance of process and project metrics, it’s often the product ones that people pay the most attention to. Certainly, the code churn and amount of man-hours per task are important to both the development team and the client. But the product metrics have the most effect on the user as well as the aforementioned parties. So, let’s look at seven essential metrics that we think every software development team should keep track of:
Functionality shows whether a project performs the specified functions. During the planning stage of the software development process, the client states the required feature list. It can be modified during the following stages, however, at the point of release, high-quality software should perform 100% of its tasks. This doesn’t include the WIP alpha and beta versions since they imply that the product isn’t finished yet.
Maintainability illustrates how easy it is to maintain the code, modify it and add new elements. It’s often defined as a ratio of the project’s functionality over the average intrinsic effort to modify the code.
Performance comes through as the speed at which the software project operates as well as it’s stability. Load times, the number of bugs and crashes are all a part of the performance and they should be logged.
Portability shows how easy a software project is to install, replace, and adapt to new environments and platforms. High-portability software would be something you can launch anywhere without installation like a progressive web application.
Reliability means that the software must work under any conditions. For example, if you lose the connection to the internet a reliable software should still be operable and update all of the databases with new data as soon as the connection is reestablished.
Security implies that all information that a software project processes must be protected. It may come in the form of encryption to protect it from malicious attacks. Risk prevention, risk reduction, defect discovery, and even policy compliance can be used to measure software security.
Usability is a prerequisite for a good UX. The software must be easy to use, intuitively accessible and provide the functionality a user seeks. Every tool has a purpose and that includes software. Don’t make the user figure out what it is, make it clear and make it easy.
Being familiar with software quality control is crucial even for people who aren’t involved in software creation directly. For example, if you as a client have had a bad experience working with remote teams, you may now want to control every aspect of development yourself. Unfortunately, this takes a lot of time and resources. You will have to trust your new team. From time to time, you can check the summary report of all testing activities. You will know what is actually going on with the project. Using the described software metrics, and monitoring your team’s workflow, you can improve it and better manage the development process.