质量保证与质量控制的区别

在软件项目中，不少技术人员经常混用QA(Quality Assurance 质量保证)和QC（Quality Control 质量控制）这两个术语；甚至一些实施培训的专业公司（Baidu和Oristand）也混淆了这两个概念。这种概念混淆，很不利于组织导入CMMI（软件能力成熟度模型）或ISO9000；更进一步说，也不利于提升软件项目管理水平。

实际上，这两个工作的性质明显不同，它们对从业人员的素质要求也很不相同。简单地说，QA（质量保证）是针对项目实施过程的管理手段，QC（质量控制）是针对项目产品的技术手段。

QA监督做事

QA致力于按照正确方法、在正确的时间做正确的事情：从做事方法上按照既定流程来保障产品质量，控制开发工作而不是解决具体存在的BUG。更贴切地说，QA并非“保证质量”而是“过程管理”（Process Management），以确保项目以一套成熟高效的做事方法开展和实施。依靠在QA制约下的开发过程，能够前瞻性地从制度上保障开发出好产品。因此，具有良好QA管理的企业，容易获得客户更多的信任。

在CMMI体系中，QA人员是独立于项目组的（不受项目经理管辖），他可以把项目经理不认错的QA缺陷上报给CCB（地位比PM更高的配置管理委员会）或高层经理裁决。

在一些大型企业的IT项目实施过程中，经常要成立甲乙方在一起协同工作的联合项目组。在这种情况下，甲方项目成员不仅要检测乙方的产品质量（QC），还要监督乙方开发过程中的做事方法（QA）。

一般地说，项目的QA人员要检查项目开发过程是否制定和贯彻了管理标准、过程（Process）、策略等正规要求，要提出完善改进的意见，指出过程是否有效、如何让过程更有效，并评估这些要求的效率、效果。

QA人员还要确保项目组成员理解这些要求。除了培训新员工理解组织过程，或培训老员工理解变更了的组织过程之外，他并不直接干预开发者的工作，而是在项目管理的最高层面上工作。他要与项目经理和CCB、配置管理员、QC人员打交道。

怎样才知道QA工作是正确的？它也是结果导向的：通过不断改进组织过程，更快、更低成本地制造出用户需要的产品。

例如，在一个大项目中，QA人员可以帮助项目经理制定项目计划，使项目按照有组织的规程推进；他要使项目组成员明白，应按照相应的报告、里程碑、文档等规定来开展自己的工作。随着项目的进展，QA人员可以适时导入“检查点”来查看哪里会发生新的风险。如，项目正在从事预定范围之外的工作，或项目有待加强管 理之处。这些检查点是确保合适的人在正确时间就位的一个机会。

从目前国内不太理想的情况来看，QA工作往往靠“意向性、模糊”的企业文化来代替， 我认为，完全依靠这种企业文化来造就合理成熟的工作套路，显得过于间接和不确定。因为在人员变动较快的软件行业，新入职的员工理解和认同企业文化并准确映射到具体工作中需要一个明显的滞后时间。这个弊端在小企业中不明显，但在大企业中会比较突出。所以，有必要建立起一套通用的QA工作标准模板，并在重要的大项目中指派专人担当QA人员。 QA人员要实时追踪了解、监督、评估项目中各种事件（现象）是否符合规范的流程？现有流程是否有效率？低效事件是因未被流程涵盖还是流程缺陷所致？就是说，QA人员要有“透过现象看本质”的抽象分析总结能力，项目中每个配合失误的“掉链子”现象，都会触发他的思考并提出改进建议。

经过这样的努力， QA人员能从一系列个性化项目中不断地抽取出有效的、有普遍意义的流程优化经验和建议，它们被项目管理办公室（PMO）确认后，会不断地 沉淀、纳入（归档）到企业的过程资产当中，成为今后企业的项目管理的通用工作指导。这样，具备成熟、可操作性的企业文化并不断进步的另一个“IBM”就会由此诞生，企业也就有能力把更多的项目做成“项目组合”（Portfolio）了。

QC是最后一关

QC工作是指测试人员检查开发人员的产品是否满足预期的品质要求，并给出改进建议。QC服务于开发工作，处于开发工作的控制之下。更贴切地说，QC并非直接“控制质量”，而是“需求印证/确认”（Requirement Validation）或产品测试。

由于QC是“用现实应用场景来评测开发人员理想化思路”的过程，所以项目经理必须重视这个依靠创造力、想象力的QC工作，投入足够资源保证QC工作。这是产品发布的最后一道关口。

QC工作，是要把程序员“纯真的技术理想”锤炼成鲁棒性极好的应用系统。测试人员需要站在软件技术和用户应用场景之间，反复、全面地检查验证二者的映射关系，还要分析“BUG越改越多”的成因并说服、帮助开发人员澄清和遵从产品版本的质量底线。测试人员不得不经常在很紧张的时间压力下，以清醒的探险性、逆反的批判性思维来全面细致地“围捕”程序员的疏忽。这就要求他要比程序员更快更准地理解用户需求、软件架构；并在接受新项目的时候，头脑迅速切换到不同的用户应用场景。即，他要有更强的跨行业学习的能力。这种能力，往往是程序员难以具备的。

理想的测试人员还应该具备“并发思维”的能力，以便捕捉多个程序员之间在多任务场景下极其容易发生的共享冲突。他还应该熟悉数据库建模和SQL，以便排查出隐患很大的、程序员和用户都难以察觉的垃圾数据并判断出成因。

由此可见，那种对测试人员常见的“编程能力不行的人，才去做测试”轻视观点是错误的。测试人员业务素质的提升空间很大，他的价值也应该得到更长远的推动和提升。

QA、QC是各不相同的重要工作，需要不同素质的人来担任。不应该认为“QA和QC可以合并”，也不应该忽略哪一个工作。