首先,质量不可能由测试来提交,BUG也不是测试测试出来的。
其次,测试已经是整个项目生命周期的晚期,这个时候找出BUG,代价已经是很大了。

那么,最好的方式是尽早、尽早、再尽早地发现BUG,预防BUG.

如何操作呢?

一个很好的方法:评审。

简单有效。

一份需求文档,可能需要10个人(假设项目所有成员为10人)2个小时,你找出了10个BUG. 如果不评审呢? 可以10个BUG遗留到提交到测试部,可能引起的BUG至少有100个了,并且可能还有20多个无法发现,而遗漏到用户那里。那这个时候,修正这些BUG的成本是多少呢?

对于需求的不明确,设计的不正确而引起的BUG,其返工的费用就更无法估计了。

那为什么? 我们还不做评审呢? 因为项目忙吗?宁愿把时间留下来返工?
 
看了这个内容后,深有体会,我们在工作中就很重视评审,包括需求,开发设计文档,开发的公演,测试用例都有详细的会议评审,并记录详细的评审内容,施行后产品质量大大提高,测试组的测试工作量也有所减轻,因为在评审过程中发现很多问题,测试难重点也很明确了。