The word “quality” can be rather subjective and probably means different things to each of us. To one it may mean that an application passes all of its tests, to another it may just mean that their code can simply be deployed. While to a business, it may be more a matter of customer and revenue impact that occurs when defects arise in production.
The thing is, most often we think of trying to measure the quality of software by focusing on the defects that affect customers in our software system’s released state. By thinking of quality merely from a defect perspective we are losing out on understanding the many areas which determine the usability of the software. And by having a broader view of what makes up “quality” software, you can better build software that is not just “free of bugs,” but meets the needs of the customers, business and so many other areas.
And as such, there is no one definition of quality. Even if you look for one online, you will find many different takes on software meeting its various functional and non-functional requirements.
But nothing that paints the full picture of what truly defines software quality.
Software quality can probably best be defined as software that achieves its purpose. However, what is that purpose? As its more than just meeting the initial requirements laid out by the business and needs to take into consideration the use and maintenance of a software product (even if it’s not fully understood at the time of conception) and also needs to tie into a company's revenue or growth stream. Or operate at an efficient cost if it’s not revenue impacting.
So given the true broad scope of what software requirements truly are and how quality is tied into that broader definition, I will attempt to detail factors that should be considered and incorporated into our measurement of software quality. Not all software is the same or has an equal purpose. So, my intention in this article is not to provide a definitive answer, but rather provide the attributes that constitute software quality. With the intention for teams and companies to then purpose fit these attributes into their context to shape what quality means to their organization.
What constitutes a software system?
However, in looking to define what quality is, we first need to understand what constitutes a software system. Even though we may be working on software projects with a finite scope that we are responsible for, no software system operates in isolation. And we can effectively measure the quality of software if we look at it from its entire system and not simply the code that was delivered.
Code under development
This is the code that is currently getting developed. When we are looking at any existing project, the aspect that will get the most attention is the code or new functionality/application that is getting created/modified, or fixed.
Code or applications that are integrated
Most code or applications won’t operate in isolation but be part of a greater software environment – either developed in-house or via third-party providers – that also shape the operation of the software. And, as such, when we’re thinking of software quality in a software system, we need to be thinking about the bigger connected operation of all parts. Not just the code we are intending to deliver.
Data
Software generally runs on data. Whether it’s a variety of databases, a blockchain system, or a variety of other data stores. How data is utilized and stored in a system forms an important part of its operation and needs to be factored into our understanding of the software system.
Host infrastructure
Code needs to run somewhere. Whether it be on physical servers or virtual machines sitting on different cloud providers. We need to think about the makeup of how these functions when thinking about how these aspects may impact our software.
Network
Software needs to speak to different components of the system or external users and all of this works through a network. A network is a combination of the internet, internal and third-party or cloud configurations that all need to talk to each other.
Having an understanding of the different aspects of the network and how they will impact the software is vital. And this includes such things as Load Balancers and Firewall services which have a massive impact on the operation of the software.
Test and automation framework
We want to test our software and have automation in place for continuous delivery and regression purposes. However, much like testing is sometimes wrongly considered as a separate function to development, we make the same mistake with the test frameworks themselves.
Even if test frameworks never get deployed to production with the rest of the code, they have a significant impact on the overall quality of the delivered code, and we need to consider the design and operation of these tests as an important part of our software design.
Deployment Tooling
We make use of tooling to move our code from different test environments to eventually deploy it into production. This tooling, and the different jobs and steps that it follows to perform these tasks form part of our overall software solution and we need to consider their operation and impact when designing, building, and testing our software.
Monitoring
We need to know what is going on with our software when it is in operation either in the production of a test environment and monitoring provides us with that useful information – in a variety of different forms.
All these different tools and processes are things we should consider as having an influence on our final software system.
Support Tooling
Sadly, software is not just a "deploy and leave alone" thing. We need to maintain and support it for a variety of reasons from patches, updates to just general maintenance. All the different tooling that enables this may not seem like an immediate part of your software system under consideration but considering the impact our software design and operation has on these aspects, it is something we need to consider.
People
And lastly, we have people. Software may be code but is built with humans and for humans in some way or another. Its operation and ease of use are all aspects of a software system that need to fall under consideration. Plus, we need to factor in the critical human cost in the development of it.
Having a broader understanding of what constitutes a software system helps to understand the real scope required to build quality software. Building software is often a bigger operation than we realize that involves all aspects of a business and it's all those aspects that have a bearing on the overall quality of software.