这段时间,某产品线总是出现质量问题。几乎每次的事故原因回溯分析都会归结于开发人员的Test和Code Review做得不好,不是接口问题,就是分支问题,要不就是想当然。似乎,这一切都在意料之中。自从上月底,研发的过程执行力度明显衰减。每次私下与开发人员交流,他们总抱怨进度太紧,没有时间做这些……其实,对于我们这样的内部产品研发来说,没有时间往往只是借口,常常是自己不愿意做或觉得不重要。
基于这样的背景,我与研发的经理一起,讨论出一个落实研发测试和Code Review的方案。也就是,在编码完成后,进行代码冻结,以便于记录单元测试的过程。这样,SQA就可以对UT基线与ST基线之间的代码差异进行审计,并对UT报告和Code Review报告进行核查。于是,我提出了SQA有权依据过程执行情况拒绝产品提交到测试部门进行测试,也就是说,正常流程下,研发的设计评审、测试和Code Review做得不充分,就不能提交系统测试。这个方案在今天的Sepgleader会议上被否决了。领导认为,SQA应该定位在服务职能上,不应该有控制项目的权利。
晚上回来,我一直在思考这个问题。直到想到了国家审计署的职能,似乎才有了一些醒示。审计只有监督权,没有控制权,输出也只有报告和建议。简要的说,SQA要做的就是审计、报告、建议,再审计、报告、建议……
可是,SQA常常在审计中迷失。如何才能突破审计的范畴,在更大的空间提升“增值”的机会呢?这是我们下一步要突破的坚冰。
Jacob Chin © 2006