Zero Defect 迷思

Zero Defect 迷思_第1张图片

最近一直跟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往往会使得这个目标越来越远

你可能感兴趣的:(Zero Defect 迷思)