SQA可否拥有项目控制权利？

   在项目型组织下，这个问题就没有讨论的必要了。要是职能型组织，连协调员都没有，部门/阶段之间如何控制？

    这段时间，某产品线总是出现质量问题。几乎每次的事故原因回溯分析都会归结于开发人员的Test和Code Review做得不好，不是接口问题，就是分支问题，要不就是想当然。似乎，这一切都在意料之中。自从上月底，研发的过程执行力度明显衰减。每次私下与开发人员交流，他们总抱怨进度太紧，没有时间做这些……其实，对于我们这样的内部产品研发来说，没有时间往往只是借口，常常是自己不愿意做或觉得不重要。

    基于这样的背景，我与研发的经理一起，讨论出一个落实研发测试和Code Review的方案。也就是，在编码完成后，进行代码冻结，以便于记录单元测试的过程。这样，SQA就可以对UT基线与ST基线之间的代码差异进行审计，并对UT报告和Code Review报告进行核查。于是，我提出了SQA有权依据过程执行情况拒绝产品提交到测试部门进行测试，也就是说，正常流程下，研发的设计评审、测试和Code Review做得不充分，就不能提交系统测试。这个方案在今天的Sepgleader会议上被否决了。领导认为，SQA应该定位在服务职能上，不应该有控制项目的权利。

    晚上回来，我一直在思考这个问题。直到想到了国家审计署的职能，似乎才有了一些醒示。审计只有监督权，没有控制权，输出也只有报告和建议。简要的说，SQA要做的就是审计、报告、建议，再审计、报告、建议……

    可是，SQA常常在审计中迷失。如何才能突破审计的范畴，在更大的空间提升“增值”的机会呢？这是我们下一步要突破的坚冰。

Jacob Chin © 2006