Software Quality Is More Than Just Lack Of Defects

My colleague Margo Visitacion and I are finishing up a new report, Seven Pragmatic Practices To Improve Software Quality, that will publish in a few weeks. We realized that not everyone has the same definition of quality. More often than not application development professionals define software quality as just meaning fewer bugs. But software quality means a whole lot more than just fewer bugs.

Forrester defines software quality as:

Software that meets business requirements, provides a satisfying user experience, and has fewer defects.

 

What It Means: Quality Is A Team Sport

Quality must move beyond the purview of just QA professionals and must become an integrated part of the entire software development life cycle (SDLC) to reduce schedule-killing rework when business requirements are misunderstood, improve user satisfaction, and reduce the risks of untested nonfunctional requirements such as security and performance.

Comments

Good Start

This is a good start. Although I have not read the full research yet, this is good. I think there is one box missing: technological dept. Software should have low technological debt. Software can have everything the three boxes indicated and still be a dud. RE: Standish Chaos Report, there is still a large amount of debt being created, often due to over-design. In business we say it is better to have 5 rules and religiously enforce those than it is to have a book full of regulations where you have almost no chance of regularly enforcing them.

It is similar with software and what I feel is often missing. The Standish report should have really driven more efficiencies. One can produce software that has 100% coverage, beautiful UI, works like a champ but then users only use a small percentage of functionality. Although not directly tied to quality per se, I think it is an important piece of the quality picture. Overall, are we producing just enough functionality to meet end user needs with all the characteristics you mention or are we producing code because we think we should?

I see everyday how technological debt is still burdening businesses. When I tie value to the debt (real, inventory, etc), leadership is typically shocked. In part this is intended; but the end goal is to drive efficiencies (note: not necessarily short term lower cost). Hopefully businesses will learn to be more value-based which sees quality has a critical component.

But, aren't "failure to meet

But, aren't "failure to meet business requirements" and "providing a crummy experience" defects?