What Is Software Quality in Practice
Quality isn't just 'no bugs.' Explore the real definition, quality attributes, the cost of defects, and why quality is the whole team's responsibility.
Quality. Everyone wants it. Few can define it. And almost no one agrees on who’s responsible for it.
When you ask a developer what “quality software” means, they’ll say “it works and has no bugs.” Ask a business stakeholder and they’ll say “it meets user needs.” Ask a QA engineer and — if they’re honest — they’ll pause before answering.
That pause is important. It means they’ve actually thought about it.
In this post I want to give you a working definition of software quality that you can use in daily conversations, sprint planning, and architecture reviews — not just in theory, but in practice.
Two Views of Quality
There are two classic definitions of quality from manufacturing and product engineering, both of which apply surprisingly well to software.
Conformance to requirements (Philip Crosby): Quality means doing exactly what was specified. If the spec says the button should be blue, a blue button is quality. Red is a defect.
Fitness for purpose (Joseph Juran): Quality means the product does what the user actually needs. The spec might say “blue button” but if users can’t find it because it blends into the background, quality is poor — even though the spec is met.
Both views matter. I’ve seen production systems that were technically correct — every test passed, every requirement was met — but that real users found painful, confusing, or unreliable. And I’ve seen systems built on intuition that were full of unspecified but critical behaviors.
The professional view combines both: quality is fitness for purpose within agreed constraints.
The ISO/IEC 25010 Quality Model
If you want a more structured framework, ISO/IEC 25010 defines eight top-level quality characteristics:
- Functional suitability — Does it do what it’s supposed to do?
- Performance efficiency — Does it respond fast enough with reasonable resource usage?
- Compatibility — Does it work alongside other systems?
- Usability — Can users actually use it effectively?
- Reliability — Does it work consistently over time?
- Security — Does it protect data and resist attacks?
- Maintainability — Can developers modify it without breaking other things?
- Portability — Can it run in different environments?
Most teams focus on #1 and occasionally #2. The rest are called “non-functional requirements” — which in practice means “we know we should care but there are no tickets for it.”
Functional vs Non-Functional Quality Attributes
The distinction between functional and non-functional quality is one of the most misunderstood in software development.
Functional attributes answer: does it do the right thing?
- Correctness — the output is accurate for valid inputs
- Completeness — all required features are present
- Appropriateness — the features actually fit the intended use
Non-functional attributes answer: does it do the thing right?
- Performance — under what load, within what response time?
- Security — what attack vectors are mitigated?
- Usability — can a user succeed without assistance?
- Maintainability — how long to add a new feature without regressions?
- Reliability — what is the acceptable downtime?
Here’s the pattern I see repeatedly: non-functional requirements are rarely written down at project start. They emerge as complaints in production. “The page is too slow.” “The login is confusing.” “Adding a new developer takes three weeks to get up to speed.”
The fix requires discipline: write quality attribute scenarios before writing code.
Instead of “the API should be fast,” write: “The
/ordersendpoint returns results in under 200ms at P99 under 1000 concurrent users.” That’s testable. That can become a quality gate. That’s engineering.
The Cost of a Bug — Why Shift-Left Matters
There’s well-known research suggesting that a bug found in production can cost significantly more to fix than the same bug caught during requirements analysis. The exact multiplier varies, but the direction is consistent:
Phase: Requirements → Design → Development → Testing → Production
Relative cost: 1× 5× 10× 25× 100×Why such a difference? Because fixing a production bug means:
- A customer reported it (credibility damage)
- A developer must context-switch to understand old code
- A hotfix must go through the full deployment pipeline
- A post-mortem meeting takes place
- A regression test must be added to prevent recurrence
The same logical error caught in a design review takes 15 minutes to fix with a whiteboard.
Shift-left doesn’t mean “write more tests earlier.” It means: involve quality thinking earlier. Review requirements for ambiguity. Validate API contracts during design. Write acceptance criteria before sprint work starts.
This is the difference between checking for quality and building it in.
QA’s Role vs Whole-Team Quality
Here’s the uncomfortable truth: QA engineers cannot guarantee quality.
They can find defects. They can reduce risk. They can highlight gaps. But if defects are introduced faster than they can be found, the pipeline leaks — regardless of how skilled the QA team is.
The modern model distributes quality responsibility across the entire team:
| Role | Quality Responsibility |
|---|---|
| Developer | Unit tests, code reviews, TDD, clean code |
| Product Owner | Clear acceptance criteria, example mapping |
| DevOps / Platform | Quality gates in CI/CD, environment parity |
| QA Engineer | Test strategy, risk analysis, exploratory testing, coaching |
| Architect | Testability, observability, fault isolation |
QA’s modern role is closer to a quality coach than a gatekeeper. They ask “What could go wrong with this approach?” before the sprint starts. They don’t wait to find out.
A Real-World Example
A team built an e-commerce checkout feature. Every unit test passed. Every integration test passed. The manual test checklist was completed. The feature was shipped.
Three days later, dozens of customer support tickets arrived: on iOS 15 with certain payment providers, the “Confirm Order” button became unresponsive after the first tap.
What happened?
| Quality Attribute | Status |
|---|---|
| Functional correctness | ✅ The button submitted the order |
| Performance | ✅ Response time under 200ms |
| Compatibility | ❌ Not tested on affected iOS + payment combination |
| Usability | ❌ No visual feedback on first tap → users tapped again → double orders |
Both failures were non-functional. Neither appeared in any ticket. Neither was part of anyone’s definition of done.
Conclusion — Quality Is a Culture, Not a Checklist
You cannot test quality in. You have to build it in.
Every team has a quality culture — either an intentional one or an accidental one. The accidental kind produces “it passed QA” as an excuse and “we didn’t have time to test” as an explanation for incidents.
The intentional kind starts with shared definitions: What does quality mean for your product? Which quality attributes matter most? Who is responsible for each one?
One thing you can do this week: In your next sprint planning, ask: “What non-functional quality attributes should we consider for this feature?” The quality of the conversation that follows will tell you more about your team’s quality culture than any test report ever could.
This is the first post in the Series 1 — QA General series, a practical introduction to quality engineering for developers and QA professionals.