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

  • Forty days in

    Calendar math says I’m a few hours into the 39th day since I started at Unity. I’m still well within the honeymoon window, but my optimism and excitement about working here continue to grow. It’s just a pretty damn cool place to work. I’ve met most of my team face to face, and will spend more…

  • Five for Friday – January 25, 2019

    A little late today, but still worth sharing… I’m currently re-reading (for at least the fifth time) Jerry Weinberg’s Secret of Consulting. It remains one of the best books I’ve read on leadership. A nice summary of what it means to take ownership in software. Ownership explained for Engineers and Managers From the “hits too…

  • Settling on Quality?

    Oh my – another quality post. I’m afraid I’m starting a trend for myself, but I have a story to share. As all gainfully employed workers in the tech field will tell you, we all have side jobs as tech support for all members of our immediate and extended families. This weekend, my mother-in-law opened…

  • Writing About Testing

    I’m leaving early tomorrow morning for the Writing About Testing conference. I wasn’t able to attend WAT last year, but I’m looking forward to the trip, the meeting and talking with a group of great testers (who all enjoy writing about what we do). I don’t think there was ever a point when I thought,…

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 to James Cancel 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.