The Challenge of Defining Quality
For years, I struggled to pin down what “quality” means in software development. As a tester, my early attempts often led to rigid metric targets—like bug counts or test coverage—that felt overly prescriptive, or vague notions like “you’ll know it when you see it.” These definitions were valid but incomplete, shaped by my narrow perspective. Quality, I realized, is bigger than testing alone.
Evolving My View
As I grew as a software professional, I began asking deeper questions: Why does quality matter? Through a tester’s lens, the answer was straightforward—fewer bugs, happier users. But that wasn’t the full picture. Quality impacts everyone: developers, product managers, and customers. Poor quality risks losing users, damaging reputations, or even sinking companies. For example, a buggy mobile app might drive customers to a competitor, while a polished one builds loyalty.
This led me to a simpler, broader question: What does quality achieve? The answer: happy customers, engaged teams, and a thriving business. Quality isn’t just about catching bugs—it’s about delivering value.
Quality: Doing the Right Things Right
After years of reflection, I landed on a working definition: Quality is doing the right things right.
- Right things: Building products or features customers actually want, like a feature that solves a real pain point.
- Doing them right: Delivering those products with reliability, usability, and polish, like a bug-free interface or fast performance.
Take a ride-sharing app: a “right thing” might be a one-tap booking feature customers love; “doing it right” means ensuring it works seamlessly across devices. Many teams focus on the latter—perfecting processes like testing or CI/CD—but neglect the former. A perfectly built feature nobody wants (like a car with square wheels) is still a failure.
Why “Right Things” Come First
Building the right thing is often harder—and more critical—than building it right. A study by Standish Group found that 45% of software features are never used, often because they miss customer needs. Methodologies like Six Sigma or CMMi emphasize process excellence, but they’re only half the equation. If you’re building the wrong thing, no amount of polish saves you.
That said, both are essential. A great idea delivered poorly frustrates users just as much. The key is balance: start by validating what customers want, then ensure it’s built well.
Making Quality Actionable
So, how do you apply this? Here are two steps to start:
- Validate customer needs: Before building, talk to users or analyze data to confirm a feature solves a real problem. For example, run a quick survey or prototype to test demand.
- Review past projects: Look at your last release—what worked, what didn’t? Did you build something customers loved, or just something that passed tests?
Your Path to Quality
Quality is simple to understand—do the right things right—but hard to achieve. Every team’s journey is unique, shaped by its products and customers. Start small: pick one feature and ask, “Is this the right thing, and are we doing it right?” That question can transform how you build software.
What’s one “right thing” your team could focus on today?
Leave a Reply