Who Owns Quality?

On request from Adam Goucher – another excerpt from How We Test Software at Microsoft.  BTW – Adam wrote a review of HWTSAM here – although Linda Wilkinson beat him to the clever title.

This is from a section on quality in chapter 16. It’s something I believe strongly in and would love to hear your comments.

Many years ago when I would ask the question, “who owns quality,” the answer would nearly always be “The test team owns quality.” Today, when I ask this question, the answer is customarily “Everyone owns quality.” While this may be a better answer to some, W. Mark Manduke of SEI has written: “When quality is declared to be everyone’s responsibility, no one is truly designated to be responsible for it, and quality issues fade into the chaos of the crisis du jour.” He concluded that “…when management truly commits to a quality culture, everyone will, indeed, be responsible for quality.”[1] A system where everyone truly owns quality requires a culture of quality. Without such a culture, all teams will make sacrifices against quality. Development teams may skip code reviews to save time, program management may cut corners on a specification, or fudge a definition of “done”, and test teams may change their goals on test pass or coverage rates deep in the product cycle. Despite many efforts to put quality assurance processes into place, it is a common practice among engineering teams to make exceptions in quality practices to meet deadlines or other goals. While it’s certainly important to be flexible in order to meet ship dates or other deadlines, quality often suffers because of a lack of a true quality owner.

Entire test teams may own facets of quality assurance, but they are rarely in the best position to champion or influence the adoption of a quality culture. Senior managers could be the quality champion, but their focus is justly on the business of managing the team, shipping the product, and running a successful business. While they may have quality goals in mind, they are rarely the champion for a culture of quality. Management leadership teams (typically the organization leaders of Development, Test, and Program Management) bear the weight of quality ownership for most teams. These leaders own and drive the engineering processes for the team, and are in the prime organizational position for evaluating, assessing, and implementing quality based engineering practices. Unfortunately, it seems that quality software and quality software engineering practices are rarely their chief concerns throughout any product engineering cycle.

Senior management support for a quality culture isn’t entirely enough. In a quality culture, every employee can have an impact on quality. Many of the most important quality improvements in manufacturing have come from suggestions by the workers. In the auto industry, for example, the average Japanese autoworker provides 28 suggestions per year, and 80% of those suggestions are implemented[2].

Ideally within Microsoft engineers from all disciplines are making suggestions to improve quality. Where a team does not have a culture of quality, the suggestions are few and precious few of those suggestions are implemented. Cultural apathy for quality will then lead to other challenges with passion and commitment among team members.


[1] STQE Magazine. Nov/Dec 2003 (Vol. 5, Issue 6)

[2] The Visionary Leader, Wall, Solum, and Sobul

Similar Posts

  • Learning is Dead

    Inspiration for my blog posts often comes from whatever’s evoking emotion in my life (annoyances, victories, gripes, etc.). Three things happened today that ensured that I’d write this post. Here’s the story of a question from a seven year old, a phone call, and an email. The first incident was a common one. My son…

  • This week’s conference

    Every year, Microsoft’s Engineering Excellence group holds an internal conference – five days of talks, panels, booths and receptions (in other words, it’s just like any other conference, except only Microsoftees are invited). This is the first year since 2004 where I’ve been at the conference and not in the EE group. You’d think that…

  • Me.Next()

    I’m back at the job after a long break (including a month vacationing in Australia – trip report coming). I spent a chunk of time after the Xbox One ship figuring out what the next step in my software career was going to be. In the days up to the Xbox One launch, I hinted…

  • Test Innovation at QASIG

    Last week, I spent my Wednesday evening talking with the folks at QASIG about test innovation. This is a variation on the talk I gave in November at Eurostar – changed enough so I didn’t get bored, and with some bonus chatter that can only come from a small friendly audience. The recording is here…

  • Test Responsibility

    I apologize in advance for yet another exploration of what testers do. More and more, I feel that Brent is right, and Test is a 4 Letter Word, but I feel we (whatever we want to call ourselves) can advance through discussion of our roles and responsibilities. A few weeks ago, I was talking to…

One Comment

  1. I am trying to promote the “Quality Triad” where I work.

    Dev is “Quality Creation”

    Test is “Quality Evaluation”

    Program management is “Quality Control”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.