蔡晓东的博客

一、软件质量观与QA活动

在不同的软件过程方法中，对软件质量保证（Software Quality Assurance）的关注程度也不同。例如RUP，更强调以架构为中心，对过程和工件的要求并不是特别高。对于CMM，则非常强调过程的可视性，CMM 2级要求里程碑的可视性，这与其他软件过程和我们的软件开发实践基本相同。CMM 3级要求活动的可视性，CMM 4级要求定量控制，这就要求软件项目组必须严格遵循过程，并真实反映过程的执行情况。因此，CMM高度要求QA活动的独立性。

一般认为，软件业对于质量的观点，最初认为质量是“测试”出来的，因此设置了专门的测试岗位。之后，人们意识到，到了测试阶段再来发现质量缺陷，成本太高；对于软件结构上的缺陷甚至无法在测试阶段修复，最后可能要推倒重来。于是，人们认为质量是“设计”出来的。最后，随着设计技术的成熟及软件的日趋复杂，技术因素不再是最重要的，对于软件过程的遵循和改进，才是最有利于质量和生产率的提高。

我们这些应用软件项目的实践者，不也在一家一家公司，一个一个验证这一点吗？我们必须相信，当测试与设计基本形成习惯以后，“过程”逐渐成为是软件项目与软件企业的无形资产，应当传承及发展。

二、为什么需要独立的QA活动

设置独立于项目组的人员执行QA活动，有利于软件研发部门领导（Project Director）获得项目的准确信息，并可以与历史数据及其它项目比对，及时发现隐含的风险。

难道不能由由项目经理执行QA活动吗？这有两个方面的原因。其一，项目经理更关注项目进度、技术、质量、过程等很多方面，而且一般都非常忙碌，不可能过多关注过程；专职QA人员更能把注意力集中在过程上。其二，对项目经理的必要监督。中国的文化，主张“用人不疑，疑人不用”。西方的管理制度，在设置一个职位时，更注重监督，即“授权”又“限权”。在CMM中，PM、QA、SEPG体现了三权分立的思想：SEPG立法，规定组织级软件工程规范；PM拥有行政权，在组织级规范下负责项目组的正常运作；QA拥有监督权，根据组织级规范检查项目组的活动是否正确，并提供独立的QA报告。

三、如何进行QA活动

QA活动的主要内容是：评审（review）软件工程活动及审核（audit）软件工作产品。

在评审软件工程活动中，确保当执行工程活动时过程得到遵循。采用的方式是参加评审及出席会议，这样可以观察到评审报告及会议记录以外的内容，切实观察过程的执行，而不是为了满足评审要求，提供的一份不客观、不完整的评审记录或会议纪要。可以预设一份检查单（checklist），在评审时应用检查单逐个核对是否符合。评审将输出评审报告，同时也把结果通知项目组相关人员。

审核软件工作产品，确保开发工作产品时过程得到遵循。采取的方式是在软件工作产品输出时，对其进行审查。我们经常看到的情况是，在编码实现进行一定阶段后，再去补写详细设计文档。QA活动要求紧密跟踪软件工作产品的输出，并及时审查，这样才能关注其“过程”是否得到遵循。

四、从事QA活动人员的技能要求

一般的，QA人员不要求很强的技术技能，对于软件工作产品是否存在技术性错误或问题难以判断，但也不属于QA活动范畴。QA关注的是过程，只要过程是合乎规定的，那么软件工作产品的质量将由过程中其它相关人员，以及技术评审去保证，而不是QA人员。但是，QA人员的核心技能是对软件工程体系的理解。软件工程知识是很难简单通过书本学习到的，需要有一定的软件工程实践经验。也就是说，虽然没有明确规定QA人员必须具备技术能力，但实际上，完全不具备技术能力的人员，很难具备QA人员所需软件工程技能。

这样，软件工程知识的缺乏，将大大限制信息获取的渠道。为了不被考核扣分，项目组可能编写一些明显未达到质量要求的工作产品，而QA人员不具备识别能力。QA活动最终流于形式，这将形成了恶性循环。研发部门领导确信，QA工作不可能有实质的效果，因此，应该让“不会做开发的人员做测试，不会做测试的人员做QA”。项目经理及骨干人员确信，QA帮不上忙，只是来“找茬”的。项目组有意识被QA人员隐瞒关键信息，QA活动进一步流于形式！

针对这一现象，一种观点认为QA应当是“老师、医生、律师、警察”。即首先为项目组提供软件工程方面的支持，其次才是对违规项目的检查和报告。这对于QA活动来说不是必要的，但对于从事QA活动的人员来说，如果完全只是评审及审核，那么容易造成与项目组的对立，最终工作难以开展。这已经超出了“管理过程学派”及软件工程的关注范畴，更多体现了人际冲突和沟通的问题。