Zero Defects 迷思
最近一直跟bug较劲，听某人总把 ”零缺陷“挂在嘴边说事，有些观点真是不吐不快。
是什么：
零缺陷 （https://en.wikipedia.org/wiki/Zero_Defects），起源与上世纪60年代，望文生义容易把人直接带到沟里。其首先肯定的一种管理态度，强调整个组织对“防患于未然”的重视，而并非"零缺陷“的结果。 对立的观点是 ”质量把关“（好软件是测出来） /”千层饼叠加模式“（层层撒网减少漏网之鱼）。
简单来讲就是，一个组织做什么能够实现零缺陷? 有些观点会说：多加QA，加大力度测试让bug无处遁形，ZeroDefect提出预防才是根源。
解决的问题：
1） 瀑布流中的责任推诿问题， 譬如开发止于于编译，然后丢给QA抓八阿哥，出问题后互相推卸责任，听起来是不是耳熟
2） 质量总体成本过高问题，一个bug的后期付出非常惨痛
采用的方法：
- 认知水平上的一致，完美是我们的追求，zero defect是可实现的
- 防患于未然，所有人都要把事情从起点做对，从流水线上的第一个环节开始抓质量
- 严格问责，比如出了问题问5 why
操作中容易犯的错误：
- 当成一个口号，拿去忽悠客户和自己人
- 简单理解成一个结果，质量把关部门不切实际的提高标准，比如一个bug都不能有
- 层层设防，每个环节建立自己的Entry Criteria，第一时间抵制上游的次品
- 资源分配的误区， 企图不改变资源分配来提高质量，比如QA部门强调自己的重要性，而不愿意介入前期的预防工作
- 作为一个不计代价的“单目标优化”问题
实施要点：
- 了解现状，搞清楚质量差的真正原因，然后重新分配资源
（比如：bug太多，QA测试不过来， 是设立入门门槛，还是分QA提早介入做白盒测试？）
- 对质量标准（现实）达成一致：怎么定义Defect，要不要分严重性/severity，...
- 设计合理的评价体系，让上下游拧成一条绳，一荣俱荣，一损俱损
- 专职而强势的QA往往会使得这个目标越来越远