过程改进 QA (质量保证) 和 QC (质量控制) 的区别

laofo · 2012年04月02日 · 4 次阅读

QA(质量保证)和 QC(质量控制)的区别

 在软件项目中,不少技术人员经常混用 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 可以合并”,也不应该忽略哪一个工作。

了解下,以后走质量管理路线,呵呵

需要 登录 后方可回复。