在我司，我发现大家很擅长把一个东西到极致，但极致可能是过犹不及了，例如测试并不是发现越来越多的Bug就越好，如果把很多的时间消耗到一些不重要的点，反而不可取，软件只要你去测试，怎能发现一些Bug，如要面对这些就非常纠结。作一名开发，说这话肯定会被一批的测试人员拍砖死了。在此表达一下不同的观点，不一定正确，请轻拍。
在我司的各种度量工具很牛X，缺陷跟踪分析每个迭代阶段就会做，形成一些报告。对于软件质量来说，统计所有过去的Bugs是没有多大用的，相对来说，一些更实际的工作可能更重要，在Douglas Hubbard的《How to Measure Anything: Finding the Value of Intangibles in Business》(如何衡量任何事：寻找商业无形资产的价值)中，把这种现象解释成衡量倒置(Measurement Inversion)：衡量一个东西的经济价值与它通常所受到的关注度多少成反比。
一种较有说服力的观点是缺陷跟踪方便人们发现缺陷的趋势，对流程的改变很有一些效果，如提前做些缺陷预防。对于管理者来说，他们需要缺陷跟踪报告可能了解软件的质量状况。但可能实际却不是这样的，单单根据DI值来判断软件质量，这跟由湿度来判断天气是否好坏一样不太靠谱。
质量是什么，尤其是软件的质量是什么？是看软件的缺陷率吗？比如我现在比较喜欢荣耀手机，我会关注荣耀手机DTS中的单有多少吗？在消费者的眼中，质量就是对他有价值的东西。如果客户是快乐的，存在一些漏洞也是问题不大的。如果客户抱怨，跟有多少Bugs是无关的。
前几年在摧广敏捷时，提到做刚刚好的系统，也提到了零缺陷：符合已确定之要求，一次做对。第一次把正确的事情做正确，包含了三个层次：正确的事、正确地做事和第一次做正确，三个因素缺一不可：
- 正确的事：辨认出客户的真正需求，从而制定出相应的战略。
- 正确地做事：软件开发中所必需的全部活动都符合客户和市场的客观要求。
- 第一次做正确：防止不符合要求的成本产生，从而降低质量成本，提高效率。
什么是软件的缺陷，在软件程序中存在任何一种破坏正常运行能力的问题，都可能叫作缺陷，Bugs。但生产软件的最终目的是为了满足客户需求，如果以客户需求作为判断软件质量的标准，软件的缺陷可以包括如下几个因素：
- 软件未达到客户需求的功能与性能要求；
- 软件出现客户需求不能容忍的错误；
- 软件的使用未能符合客户的习惯或工作环境。
软件测试其实并不只是要发现问题，如果我们进行非常变态的测试，的的确确能发现很多的问题，但是有可能此类问题根本不可能出现，或是在软件生命周期内也永远不会出现，没有这么复杂的使用场景。在做异常测试，虽然一定要以发现缺陷的心态挖掘测试，但也不应该是一种无所欲为的测试。还好，公司已积累了不少的故障模式库供参考分析。但是像可服务性，可维护性，易用性应该做到什么样的程度却在实际项目操作中很难把握。任何缺陷的修改都是有成本的，一旦控制不好，可能把有限的精力都浪费在不重要的点了，这也是开篇所说的过犹不及。
测试人员认为某种情况是缺陷，但开发人员认为又不是，而现实就是所争议的情形在需求中也没有明确地描述。公说公有理，婆说婆有理，说不清，道不明的。开发与测试的争执由此开始，矛盾也由此产生，不和谐的气氛由此理下种子。出的原因可能有多种：
- 需求澄清不清，需求描述太过于简单，离最终的客户又远。
- 对于原始需求没有进行评审，整理，并书面化归档。其实需求文档也要测试验证的。
- 开发与测试存在理解上的偏差；
- 需求本身的定义存在二义性。
面对这种问题，无论开发与测试人员需要知道：
- 要知道任何的争论解决不了问题，争论不要存在个人感情色彩(其实这个很难做到)；
- 出现问题，首先从自身找问题，有时往往是因为我们的简单思维导致。
- 人非圣贤，有错就改，并不失面子。讨论对事不对人。
可能在很多的部门，把缺陷做为开发或测试的绩效指标，这种简单而粗暴管理，直接的结果就是让开发和测试从此不和谐，彼此斗角。要相信办法总是比问题多，每一个问题都有至少一个解决的办法，愿开发与测试都能朝同一个目标，把软件做到刚刚好，事成人爽。