When we say 'software quality' or simply ‘quality,’ we think that everyone understands what we mean by it. The problem is that if you ask a bunch of different people in a software development team (including stakeholders) what software quality is, you would likely get a few different answers.
So, what actually is it then? Software quality, in my humble opinion, is about a product's fitness for purpose. But that can be very context-dependent on how you define both fitness and purpose. Some say it is the extent to which a software product meets the needs of its users and stakeholders or delivers value. This can include a host of things, such as reliability, or just making sure people can actually use it without getting frustrated or confused.
The big one for quite a few people is the absence of bugs: those pesky little things that stop our software from working as it should. But we have all seen priority 4 bugs. They don’t affect the software performing its job, and they tend to sit on a backlog for years, never to be addressed. Do those mean the software is of poor quality?
Ultimately, quality is not just about the code itself, but about the entire user experience, the business value it creates, and how well it solves the problems it was designed to address in the first place. Assuming, of course, we have correctly identified the problem(?). Quality is a holistic view that combines many different perspectives so we can recognise something that is truly useful and well-built.
Well, defining quality was easy. We are all done. Or are we?
You see, while that definition covers a fair bit of ground, it is far from the whole story. Software quality is a wonderfully complex beast, with many facets and interpretations depending on who you ask and what their particular interest is. A product manager might define quality as 'meeting market needs and achieving high user adoption.' A user might define it as 'it works for me and solves my problem.' A developer who is writing the code would have a greater interest in its internal structure and the maintainability of the code. All these perspectives are valid and contribute to what we call software quality. It is about balancing all these viewpoints to create a product that not only functions well but also brings genuine value and joy to those who use it.
Some other definitions of software quality
Let’s look at the definitions already out there in the world and see if anyone else has cracked the problem of defining software quality in a simple and unambiguous way.
Institute of Electrical and Electronics Engineers (IEEE)
Software quality refers to the degree to which software conforms to its requirements and meets the needs of its users. It is formally defined as 'the capability of a software product to satisfy stated and implied needs when used under specified conditions.'
Another IEEE definition states that software quality depends on 'the degree to which those established requirements accurately represent stakeholder needs, wants, and expectations.' High-quality software meets its requirements, which in turn should accurately reflect stakeholder needs. Quality is about aligning the software with both its formal requirements and true user needs.
Wikipedia
In the context of software engineering, software quality refers to two related but distinct notions:
- Software's functional quality reflects how well it complies with or conforms to a given design, based on functional requirements or specifications. That attribute can also be described as the fitness for the purpose of a piece of software or how it compares to competitors in the marketplace as a worthwhile product. It is the degree to which the correct software was produced.
- Software's structural quality refers to how it meets non-functional requirements that support the delivery of the functional requirements, such as robustness or maintainability. It has a lot more to do with the degree to which the software works as needed.
ISO / IEC 25010 (International Standards Organisation)
The quality model is the cornerstone of a product quality evaluation system. The quality model determines which quality characteristics will be taken into account when evaluating the properties of a software product.
The quality of a system is the degree to which the system satisfies the stated and implied needs of its various stakeholders, and thus provides value. Those stakeholders' needs (functionality, performance, security, maintainability, and so on) are precisely what is represented in the quality model, which categorizes the product quality into characteristics and sub-characteristics.
The product quality model defined in ISO / IEC 25010 comprises the nine quality characteristics shown in the following image. You can learn more through the link in the For More Information section at the end of this article.
Ady Stokes: Some random bloke’s MoT Glossary submission (other definitions are available)
Quality, or in our case, 'software quality,' is one of those words that everyone uses. Its meaning is rarely questioned in the moment, but it can mean so many different things.
Suman Bala, quality engineering architect and author, uses a great example of a royal throne and a school chair to explain why context is so important when thinking about quality. The costs of these objects are exponentially different. Their materials, complexity and design are miles apart. Yet, for their purposes, in their own contexts, their quality can be argued as comparable. The soft and plush throne, with its many adornments, used only a few times, can be perfect for the context in which it is used. The hard and basic metal and plastic chair, used tens of thousands of times, can also be perfect in a school environment where it needs to be cheap, hard-wearing and even stackable. The objects are vastly different, yet equally valuable.
In software, quality can depend on such a variety of factors that having a single definition can be more of a hindrance than a help. A developer might see quality as clean code with no 'smells.' A tester might look at a wide spectrum of attributes, from alignment with requirements or acceptance criteria to accessibility and usability. An end user might simply want something that works.
Gerald Weinberg
Gerald was an American computer scientist, engineer, author, and software development influencer who focused on the human aspects of building software. He described quality as 'value to someone,' a definition which has been augmented over time with phrases like 'who matters' and 'at some time.' Even with context, quality is not always a fixed measure but something shaped by people and purpose. What matters to one group may not matter to another, and that is why software quality always needs an ongoing conversation.
Stuart Crocker
Stuart is a software engineer with a focus on testing and quality. He advocates for whole-team testing and open-source initiatives. In a 2024 LinkedIn post, he defined software testing as 'the exploration and discovery of intended and unintended behaviours in the software we build and their impact on product value—for both customers and the business.' He then defined quality as 'the absence of unnecessary friction' and went on to write that 'these two definitions, working together, help me make quick, useful decisions on what to test and from that testing, what is necessary to improve.' That view captures how feelings can be a primary indicator of quality (to someone).
Dan Ashby
Dan is a software quality leader with over 20 years of experience who has a strong commitment to sharing knowledge. He created the 'continuous testing in DevOps' model. In a 2019 blog post, he examined Philip Crosby's four absolutes of quality in a software context. Crosby's first absolute was 'quality is defined as conformance to requirements,' and since Crosby was a quality leader in manufacturing, conformance to requirements is fundamental. Dan saw that software requires a broader definition, and restated Crosby's first absolute as 'quality is defined as correctness and goodness in relation to stakeholder value.'
Defining software quality for once and for all: are we there yet?
In the end, what software quality means in your context is not something I or anyone else can tell you. It is context-dependent, shaped by many things like purpose, constraints, time, and the people involved. There is no universal checklist.
The key is understanding what quality means in your situation, how it will be measured, and to whom it truly matters. Some people who evaluate quality find customer feedback essential, while others monitor and observe software performance first and foremost. And many quality evaluators look to develop quantitative measures. They ask, 'How long does it take to learn and understand a new feature?' or 'Which scales or meters can we employ to measure a value of quality?
How you describe or measure software quality will depend on the factors you have. Have fun doing it.
Perfect, we’ve done it! Or have we? Maybe not. Let’s continue.
Understanding the difference between software quality and technical quality
So far, we have seen that defining quality may not be that simple. So let’s make it even harder. When we talk about quality, we have to look at the big picture: how well it works, what the user sees, the performance, and whether there are any pesky bugs. For example, if you are using an online banking app, its software quality would be judged on whether you can easily transfer money, check your balance quickly, and feel confident that your transactions are secure.
Technical quality delves deeper into the software's inner workings. It is about the code, the design, and how easy it is for other developers to understand what’s going on and how it all works. Think of it like this. A car can have great software quality if it gives you the right information when you need it, gets you from A to B reliably, and has all the features you need while travelling. But its technical quality would relate to the engineering under the bonnet: how well the engine is designed, the strength of the chassis, and the efficiency of its components. Even if you are comfy, listening to a perfectly balanced stereo, but all the while the car is broken down at the side of the road, your first thought probably wouldn’t be ‘this is a quality car.’ I’ve broken down a few times, in lorries too, and let me tell you, none of the choice words used in those situations was anything like 'quality'…
You could have a product with high technical quality but low software quality. Imagine a piece of software built with near-perfect code (if there is such a thing), beautifully designed architecture, and comprehensive unit testing. Yet if it doesn’t solve the user's problem, is hard or confusing to use, or fails to deliver its core functionality, then its overall software quality is low, even if the underlying code is a work of art. Or, you might have a product that is incredibly popular and solves a huge problem for users (high software quality), but its internal code is a tangled mess, full of technical debt, making it a nightmare for developers (low technical quality). Both are important, and ideally, we want to strive for the right amount of quality in both areas.
New ideas: Continuous Quality and Quality Coaching
The idea of quality has evolved. It is no longer seen as something you 'check for' at the end of the development cycle. We are now embracing continuous quality. This means building in quality from the initial idea right through to deployment and beyond. It is about creating a culture where everyone, not just a dedicated team, is thinking about and contributing to quality all the way through development.
This is where quality coaching comes in. A quality coach doesn’t stand between the team and the release. They don’t sit there waiting to catch bugs at the end. Their job is to work alongside the team so quality thinking shows up earlier and more often. They empower teams to understand quality better, identify potential problems earlier, and build robust solutions from the start. Imagine a team building a new feature. A quality coach might run a session to explore how users might interact with it, helping the team consider edge cases and potential bugs before any code is written. They might introduce new testing techniques, help set up better feedback loops, or guide the team in improving their automation. The goal is to uplift the entire team's capability and mindset towards quality, making it an inherent part of how they work every day.
Evolving from Quality Assurance to Quality Engineering
Recently, there's been a shift from testers as the gatekeepers to full team responsibility for quality. This shift feels like a big one, reflecting the progression we have seen in the software world. Historically, 'quality assurance' or 'QA' often implied a function that primarily focused on verifying that the software met requirements, often time crunched at the end of a project. Often, testers were put into a department entirely separate from developers, and their job was to try to find bugs after the developers had finished their work. All the while, they were pressured as the release's deadline (often artificial) approached. Any potential issues found could create disputes as the developers had ‘moved on’ to new work.
While there was always value in software testing, no matter the form, the "test last" approach often created silos, delayed releases, and contributed to an 'us (testers) versus them (developers)' mentality. You may have heard the term ‘thrown over the fence’ to indicate software given to testers with no details or collaboration. But the truth is that delivering great software has always been everyone's goal.
Today, we are seeing more and more companies move towards a quality engineering mindset. This term signifies a more proactive and integrated approach to quality. Quality engineers don't simply find bugs. Instead, they are heavily involved in preventing them. They work in cross-functional product teams, collaborating with designers, product managers, and developers. Their skills help to shape the product's design, influence the architecture, and ensure that quality is considered at every stage. A key indicator is MoT's recent discovery that 80 percent of people like us (testers) identify as quality engineers.
The change in approach is driven by several factors. Teams are increasingly adopting 'shift left testing,' meaning that quality-centred activities start much earlier. Quality engineers are involved in writing user stories, defining acceptance criteria, and setting up solid feedback loops and collaboration opportunities. This means that bugs are more likely to be caught earlier, when they are cheaper and easier to fix. It is about building in quality from the start. It is a shift from a reactive mindset to a proactive, engineering-focused mindset, where everyone takes shared ownership of delivering a high-quality product.
To sum up
Software quality is far more than just the absence of identified bugs. It is a very broad concept that encompasses everything from technical perfection to user joy. While technical quality focuses on the robustness of the inner workings, software quality takes a holistic view, considering the entire user experience and business impact.
To some people, quality is not an act or a thing. It is a habit built into not only what we produce, but also how we work together to produce it. We know that, just as with digital accessibility and security, we need to think about it from the start, as it is much more costly to add it later.
The industry's pivot towards continuous quality, championed by quality coaching, and the movement away from quality assurance to quality engineering, highlight a fundamental shift. We are moving towards a proactive, embedded, and shared responsibility for quality throughout the entire software development lifecycle (SDLC), ensuring we build not just functional software but valuable products that work for everyone.
From Software Testing Essentials Certificate, module 5, lesson 6: To summarise, quality can be elusive and mean completely different things to different people. It is important that we gain a shared understanding of what quality means in the context of our testing and for the project.
You can find many quotes and theories on quality, but here are a few things to bear in mind when discussing quality.
- Quality is subjective and requires context to be understood in each case
- Quality is the whole team's responsibility, not just the tester's
- Quality within a team can mean many different things
- Build the right thing: ensure it delivers value to the company and users
- Build the thing right: continuously improve your ways of working through retrospectives and interactive improvements
- Quality can be measured by customer engagement and feedback. Happy customers mean a quality product
What do YOU think?
Got comments or thoughts? Share them in the comments box below. If you like, use the questions below as starting points for reflection and discussion.
- Do you have your own definition of software quality, or do you feel an affinity to a specific definition?
- Have you seen or experienced the meaning of quality being seen very differently from two or more perspectives?
- What are your thoughts and takeaways from the article?
For more information
- What is software testing (MoT), Ady Stokes
- Drawing Parallels Of Software Quality With Other Fields (MoT), Atmaram Naik
- Software Quality and Developer Experience: Why testers should care about it (MoT), Fernando Teixeira
- Software testing, MoT Glossary
- What is software quality? Institute of Electrical and Electronics Engineers (IEEE)
- Software quality, Wikipedia
- ISO 25010: Software product quality, International Standards Organisation
- Stuart Crocker's LinkedIn post on his definition of software testing
- Continuous testing in DevOps, Dan Ashby
