质量在软件开发中意味着什么？对于现在业界使用的‘质量’一词，Mike Bria 认为：我们用之强调的是“没有缺陷”，而不是日常生活中约定俗成的“有价值”。

　　他接着建议：

　　“质量”应该被用来衡量交付给客户的功能上和美学上的实用性，而不是衡量软件的缺陷数目。没有缺陷是理所应当的，而且这也是作为专业人士所应该做到的。

　　因此：我建议身为软件专业人士和业务人士的我们，请不要将“质量”定义为“对缺陷数目的衡量”。

　　Mike 认为如果我们把质量更多的视为对客户要求的满足程度，而不只是较少的缺陷数，人们编写的脆弱代码就会更少一些。他也认为如果软件宣称的高质量只是缺陷数比较少，那么就很少有客户会认可该软件为一款高质量的软件。而这（缺陷数比较少）只是软件的最低验收标准。

　　Lisa Crispin，《Agile Testing: A Practical Guide for Testers and Agile Teams》一书的合著者，评论道“我从来都不喜欢量化缺陷，所以很难想出一个合适的名词来称呼”。

　　Christian Vest Hansen 引用了 Robert Glass的回复，认为“质量”是：

　　...一组属性的集合：移植性、可靠性、高效性、易用性、可测试性、易理解性与易修改性。

　　这些属性中的各项在不同的项目里面都会体现出不同的重要性，但是单独的各项却不能构成为质量。有些项目可能根本不用关心移植性，但是，只考虑可靠性、不顾其他属性的产品并不能算是高质量的产品。

　　James Bach认为对质量的传统看法——“产品的质量是由它的开发团队构建出来的。开发团队通过在代码编写过程中严格遵循工程实践来构建质量，这样产品才能满足用户的所有需求。”，其实是一个与软件开发并不相吻合的比喻。他提出了一个新的比喻作为替代：

　　产品是动态调整得到的结果，如同花园受到各种因素的影响。要得到高质量的产品，就需要随着时间流逝，进行维护和除草等工作。与真正的园丁一样，在耕种我们的“庄稼”的时候，我们做不到全知全能。在工作的同时，我们会去检查产品的情况和状态。我们试着去预测问题，然后解决发生的问题。我们试着去弄清楚我们的技能可以做到的与不能做到的，然后相应地调整客户的期望。我们知道我们的产品总会腐烂的，而客户的喜好千差万别。而且，我们知道即使是最好的庄稼也可能被拙劣的厨师糟蹋了。在很大程度上，质量并不是我们所能掌控的。

　　多少年过去，看过很多成功和失败的产品，也看过先成功后失败的产品，在我看来，质量倏忽即逝。 有时产品的质量足够好，甚至可能非常好。只可惜都耐不住时光荏苒，终究是无可奈何花落去。

　　最后，JB Rainsberger 提醒大家：“当我们停止追求客观的、可度量的质量，我们就会回过头来满足某些特定的人的需要，我认为那样（客观的可度量的质量）更能帮助我们交付更适合的、更有益的软件。”

　　对于质量是什么，大家并没有清晰的共识。但是，大家都赞同质量不是对缺陷数目的衡量。作者们也都认为我们需要实事求是，必须承认一旦有了缺陷就不能再奢论质量。