从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又翻过了哪些高山

年初的时候公司引入了企业管理内训，带着我们重新理解了PDCA的循环。在这个过程中我们分析了以往工作和项目中的问题，发现过程管控是我们很薄弱的环节。方案的最初的方向是测试前置，在考虑了历史项目的经验和查阅了大量资料之后，决定将方向定位设立QA职能。

QA方案从最初的设想到最终在项目中落地，前后历时近两个月，过程中经历诸多的问题。

选模型

首先在网上查阅了很多的资料，其中生产型企业的QA模型比较多，不知道怎么往IT行嫁接。后来又与业内的小伙伴们交流了很多，有像幽灵一样处处盯着的，也有技术大牛review代码的，基本不符合我们的现状和诉求。其实这个时候我们犯了一个比较常见的错误——拿来主义。一心想着能有一套特别适合公司现状的模型，可以直接拿过来用。每一套流程都只适用它当时所处的环境，不是说不可复制，而是需要针对性的进行裁剪。在意识到这个问题之后，我们把这些裁剪成了我们心里想像的样子：

1 QA参与项目全流程工作，对过程和结果进行数据收集和监督；
2 收集全路程文档，记录，数据信息，并汇总整理，做数据储备；
3 组织各个环节负责人，对项目过程的每个环节制定工作标准，如代码规范，bug规范，需求规范等；
4 综合数据分析，对各类型项目设置安全阈值，对触发阈值的过程点及时干预；
5 对项目过程中的各个环节，提供改进意见，并反馈至总监和项目负责人；
6 跟进项目组成员实时填写的风险列表，推进关键风险及时解决；
7 以事实数据为依托，对项目过程和结果进行质量评估。

当然，这个不是最终执行的内容，因为下面还有好多坑。

定标准

 

既然是检查监督，肯定是需要有参考标准，就是这个标准可把我们给愁坏了。历史工作保留下来的数据少之又少，想从数据分析上得出结论已经不可能了，就只剩下拍脑门了。最后一拍脑门，将标准一分为二：
一部分是流程标准，即规范流程内容。包括制定了任务创建规范，详细描述了任务创建的格式和标准，引入了“结果定义五明确”，规定了任务的检查及流转规则；规范了计划模板的格式及修订更新规则等。
另一部分是质量标准，引入CI/CD机制，规范了扫描问题的数量标准以及处理规则。

专业能力

 

针对QA人员的转能技能，有两个比较突出的问题：1 是否有能力深入检查需求和开发的工作内容，比如review代码等；2 对项目风险的识别是否准确。
这两个问题的答案很简单，当前团队人员在综合素质达不到这个要求，而且也不是短期可实现的。于是我们决定将重点放在方案的流程上，努力做到不依赖于个人能力就可以完成这项工作。

利益平衡

 

推动项目流程的变革，势必会对损害既得利益者，这个似乎是所有的调整都会遇到的问题。对于如何识别和处理相关方，就是见仁见智的事了，无非就是做好向上，向下和横向沟通。我们针对这个问题的处理原则就是，尽量把影响降到最低。就像医院看病，能吃药就不打针，能打针就不输液，能微创就不开刀，都是一个道理。最钟也是因为领导的加持，这个问题没有特别凸显。

如何授权

 

QA到底在项目中处于什么样的角色，应该授予什么样的权利？这个问题在最初是有过争议的，有两点分歧：1 职权过大是否会干扰到项目经理的工作，产生不必要的争端或其他负面问题；2 职权过小是否起不到监督的效果，项目经理完全不理怎么办。
   
我的最初设想是，让QA像产线的质检QA一样，在问题超过控制线后有拉闸叫停生产线的权利。比如在过程中发现项目部分流程严重不合规，可以随时发起专题会议，警示和纠正相关方的工作。但是考虑到项目运行过程中可能会因此产生矛盾，于是放弃了这个想法。在解决如何避免项目经理不理会的问题时，我们引入了第一版的三方监督机制，即把总监、项目经理和QA三方绑定监督，QA监督项目经理，总监监督QA，总监监督项目经理，避免利益共同体的形成。后来证明这个三方监督的机制有一个致命的bug，后面会提到。
   
终于，关于授权的问题也有了初步的方案。

评分

 

最初版本中，有针对项目团队成员的评分制度，后来被砍掉了。原因是QA监督的这些维度，不能客观的反应团队成员的整体贡献度。例如，针对任务延期的考评，无法判断是否成员个人的原因造成还是项目经理临时安排了其他工作；任务提前完成有可能是项目经理调整了任务优先级，但是没有更新计划等等。如果要做到非常可观，又需要增加很多的流程规范，并不利于项目的执行。于是在权衡之后决定砍掉了评分制度，等到体系更成熟的时候再加回来。

稳定运行

 

任何流程制度，能持续的运行才算是好的制度。工作中遇到了太多的走着走着就散了的事，数不胜数。和小伙伴们交流的时候，也发现了类似的情况，要么就形成了利益共同体，要么就是不了了之。所以，我们在做方案时优先考虑了可持续性的问题。为此引入了上文提到的三方监督机制。前面也提到了，这个方案有个bug，就是当总监没时间检查的时候，项目经理就不管了。运行的时候就变成了总监有空，项目经理就会处理，总监没空，项目经理就不管。后来我们修复了这个bug，将QA接入到了我们现有的一套三方检查机制（质询会）中。简单的说就是每周一次管理层例会，大家相互提出各种待办事项并承诺完成时间，这些事项会计入质询单中，由助理每日推荐和检查，未完成的水果基金伺候。
   
还是这个观点，能持续运行的制度才是好的制度。

持续改进

 

在运行的过程中，我们会不断的发现问题。将这些问题整理总结，并与相关方讨论处理方案，再将方案优化到流程中。如此往复，就是一个PDCA的循环。比如我们规定流程中每增加一个规则，就加入到QA的监督检查项中。这样一个循环一个循环的持续成长，才会让我们的这套机制一直处于进步当中。