从QC到QA

QC遇到了什么无法逾越的障碍

我们公司的主要业务是项目外包，一般的项目都在2-3个月的周期，采用瀑布模式。这种模式本身是相对简单，且十分成熟的模式。但是在实际的工作中，我们还是遇到了前所未有的挑战。

提测质量差

例如200-300人天的项目，提测bug数量基本在400-600左右，最高纪录应该是一个400人天的项目，我们总共提交了1200个bug。数据的冲击力可能没有那么大，那换个描述方法：几乎所有的功能都有bug。在项目提测时，仍然会伴有大量的严重和阻塞问题，从一个功能模块不可用，都一条业务流程跑不通。各种问题层出不穷。

无法设置准入准出标准

在面对较差的提测质量时，首先想到的是做准入准出标准，如提测后的冒烟测试不能有核心问题，严重问题小于2个等等。准入准出在业内属于比较普及的方法了，我见过很多公司在这方面执行的非常顺畅。但是在我们团队却无法落地——周期不允许。对于项目外包团队，周期就是成本，时间就是生命。如果我们严格的执行准入标准，那实际情况就是一轮一轮提测，一轮一轮被打回，周期会被拖的非常长。所以这个方案没有落地就被扼杀了。

测试周期不可控

当bug数量到达这个程度时，提bug-改bug-回归bug的工作量就显得非常可观了。庞大的bug基数，意味着改完这一遍相当于把整个项目的代码重新写了一遍，随之而来的就是新的麻烦——bug激活/新增。我们的bug新增/激活率基本维持在13%~21%这个区间，例如回归400个bug的项目，在回归之后可能要激活或者新增80个bug。整体的测试周期也被迫拉长，个别项目还会变的失控，比如1200个bug要测试四轮到五轮。

QA又翻过了哪些高山