统称QA

统称QA

陈能技

2007-9-29

原文：The QA Catchall- Alan S. Koch

几年前，我在一次名为“A is for Assurance ： A Broad View of SQA”的演讲中介绍保证质量需要进行的各种活动。在问题和回答环节，发生了这样一段对话：

某听众：我喜欢做你说的那些事情，但是我不知道怎样才能看到他们在我的QA部门出现。

我：你的角色是？

某听众：QA分析员。

我：那么你做什么工作？

某听众：我编写测试计划和测试用例，并测试我们的产品。

我：那么在你们公司其他质量角色是什么？

某听众：QA经理管理测试。

我：…

我不敢告诉那位听众今天我要讲的：“你没有工作在一个QA部门，你的经理没有在负责QA的管理，你做的东西与质量保证毫无关系。”

我讲得可能会让像那位听众一样的人感到受挫折，因为软件行业让人们对达到高品质而做的工作感到受挫折。我见到过的和跟我一起工作的QA们对质量都很兴奋，但是他们通常处于一个让他们很少有机会能保证质量的位置。

测试是QA吗？

不，测试不是质量保证。

为了更加清楚，让我们先抛开软件不看。先看一下在制造业，测试员对来料进行检测，或者把零件从组装线拉下来并检查公差。不管是那一种情况，他们都在检查以确保这些成品符合规格的要求。制造也组织把这些测试的功能称为质量控制QC，而我将要讨论的完全是另外一套质量保证（QA）的活动。

质量控制活动出现在产品已经开始构建或构建完成后，用来检查产品是否满足一定的质量水平。你在某些东西出现之前是不能做QC的。而到了那个时候，你只有两个选择：接受或拒绝。你不能改进质量，你只能控制已经做好的产品是允许它继续还是把它退回。就像我们通常所说的，“你不能通过测试来提高产品质量。”

QC的本质是做出反应。它发生在产品或部件被构建好后 – 检查是否满足规格 – 并决定如何反应。QC不能保证任何东西。

技术评审是QA吗？

不，技术评审不是质量保证。

没错，评审发生在产品完成之前，而测试发生在过程的后端，但是与QC的功能一样，评审人员在组装线的中间抽取一部分进行测试。虽然整个产品还没被组装完成，但是被检视的那部分是完成的，那部分是被测试的。

需求评审发生在需求规格说明书被准备好签字后。架构评审在系统架构几乎定案时。设计评审发生在组件的设计已经完成后。代码评审发生在某个模块的代码被编写完成后。这些评审是一种测试用于保证产品是可被接受的并作为后续工作的基础。

技术评审被用于检查和纠正工作产品的错误。它们的目的是为了通过判断工作产品是可被接受的，否则它们必须被退回进行返工，从而控制质量。技术评审的本质也是作出反应，虽然让它们发生在开发过程的早期，要比测试早。但是，它们同样的，本质上也是QC。

那么什么是质量保证？

回到那个流行的说法：如果“你不能通过测试得到质量，”那么怎样才能得到呢？你必须内建它。

与QC对比起来，QA活动是主动的。QC通过回顾的方式来看质量是否被建立，QA则在产品或组件被构建好之前就开展了，从而确保当产品被构建好时，会拥有适当的质量。

为什么我会碰到那么多的QA部门他们不知道如何开展质量保证活动呢？因为他们从来没有看过一个软件开发组织真正地参与到QA中！即使是今天我还是很少能看到一个真正的QA团队。

因此，如果你真正参与到软件质量保证中，你能用怎样的主动的步骤来保证当你的下一个产品被构造出来时拥有你的顾客需要的产品质量属性呢？

当组建一个QA组织时，从这些步骤开始。它们相对容易实现并提供真正的质量利益。

l 对某种共通的模式取得一致的看法

l 定义一致的惯例

l 确保标准和流程被使用

l 保持对项目的回顾

l 从缺陷数据分析和学习

l 应用你学习到的东西

如果你的组织已经开始在做这些东西，那么祝贺你，你已经在“游戏”中了。但是继续读下去 – 你可能未能从它们得到完全的好处。

对普遍模式取得一致意见

Paul Simon会唱“Fifty Ways to Leave Your Lover”，但是你是否真的需要50种方法来命名你的变量呢？我曾经发现让一组开发人员对模式或模板（标准）要比说的容易。每个开发人员都有他自己喜欢的工作方式，而大部分开发人员对有机会讨论他们使用的标准表示欢迎。

标准模式提供项目组成员一个重要的基础让他们协作。当每个人以不同的方式处理同一任务时，协作是最难的事。一个开发人员会不愿意跟其他人合作，如果他认为其他人会不同意他的方法时。而当合作确实发生时，那些差异会妨碍理解和利用其他人的知识和经验。

如果产品使用一致的模式构建，QC活动（评审和测试）能更好地专注并且更高效。如果缺少了它们，评审人员和测试人员必须尝试捕捉开发人员可能做的任何东西产生的问题。这样一种漫无目的QC方式需要更多的努力并导致很差的覆盖率和很低的缺陷发现率。

模板也能促进更好的技术工作。一个开发人员以自己的方式做一项工作会很容易忽略重要的步骤或忽视重要的信息。拥有完整的工作标准，则不会对最后工作应该是怎样存在什么问题。

你应该考虑计划的标准，规格说明书、代码、用户界面的标准，文档、培训材料的标准，和任何其他工作产品的标准，因为对一个项目应该如何进行能帮助确保它的质量。但是对于标准，你必须识别它被应用的上下文并提供需要时进行裁剪的指引。任何你所赞同的标准应该帮助你做好你的工作而不应该是一件紧身衣。

定义一致的惯例

注意标题并没有说你应该使用惯例或流程。因为每个人都在使用流程做他们经常做的事情。对，你的组织已经有一套软件开发的惯例。关于那些惯例，你首先必须问你自己的两个问题是：

1、它们是否满足你的要求？

2、你是否始终在适合的上下文中执行它们？

第一个问题专注在惯例的质量本身。它们是否适合它们对应的目的？根据目的，你可能问这样的问题：它们是否支持和鼓励你所需要的合作？它们是否能促进开发组与客户之间的充分交流？它们是否支持最好的软件工程标准的使用？它们是否能帮助你达得你的质量目标？

通常，当人们意识到他们的流程时，是因为他们痛苦地意识到了那些流程。例如，流程会妨碍合作、技术发挥或者是利益相关者的关系，又或者是其他方式不能满足项目组的要求。说“我从来未碰到一个我喜欢的流程”的人可能已经使用了很多很好的流程但是没有意识到它们。

高质量的流程不总是不可见的，它们确实让事情进行得更加顺利。它们在提供灵活性以适应每个项目的特殊要求的同时鼓励卓越。简而言之，他们支持你的项目需要。

第二个问题专注于你们执行这些惯例的质量。如果你没有恰当地、始终如一地按照你赞同的惯例做事情的话，好的流程的益处可能丢失。持续地使用高质量的流程是为了确保每个人都知道什么时候以及如何遵循它们并坚持团队期待的惯例。“那就是我们这边做事的方式。”

确保标准和流程被使用

为了从你建立的标准和流程中得到益处，你必须持续地检查以确保你们在按定义好的方式做事，并确保你得到你计划的结果。行为如果不能被持续地强化最终会导致消失。这是人类行为的一个事实。

能力成熟度综合模型（CMMI）通过过程审计来实现。（CMMI把这些审计归类为质量保证活动因为它们是在测试流程而不是产品。）敏捷方法（例如极限编程、SCRUM）为了这个目的会聘请一个方法教练。不管这个检查是怎样进行的或者称呼是什么。它产生质量效果。

当你发现一个被接受的标准或流程被忽略的情况时，需要进一步调查和跟进，因为可能是由于各种各样的原因导致的。例如：

l 人们只是忘记了遵循标准或流程。提醒他们

l 人们没有意识到标准或流程或者不知道怎样使用它。改进你的沟通或培训方法

l 标准或流程不适合目前的工作。发布裁剪指引或替换它

l 标准或流程过于低效或过于烦琐而不适应当前情况。简化它以便它能满足要求而不是起阻碍作用。

每个对标准或流程的违背是一个学习和改进的机会，以便更好地满足项目组的需要。

保持项目回顾

把他们叫做“学习到教训”，“马后炮”，或者其它的，这些是主动改进工作质量的最有效的工具。回顾是指专门预留指定的时间用于回顾一个项目并学习经验教训。关键问题是：“什么进行得挺好，我今后如何重复它？”和“什么做得不够好，我如何防止它在将来再次出现？”

虽然回顾被广泛认为是“最佳实践”，但是我发现很少被实践。两个最普遍的原因是：“很难让大家在一起做一个回顾”和“我们曾经那样做过，但是它对我们如何做事情没有产生任何影响。”

第一个原因是因为回顾工作在项目的最后才进行。很多项目成员已经被调动，剩下的人则忙着产品发布和支持。敏捷方法建议一个简单的修正问题的方法：不要仅仅在项目的后期才做一次回顾，在项目过程中有规律地做回顾。这样的好处包括：

l 项目组成员都在，因为他们仍然被分派到这个项目

l 对一个月左右的状态进行回顾会更容易计划，因为它只会花上一个小时或两个小时的时间，而不用一整天甚至更多。

l 项目组成员的经验仍然记忆犹新，所以所有经验都能记住并包含在讨论中。

l 最重要的是，你能把学到的经验教训应用到剩下的项目过程中。

第二个原因是你收集了很多有趣的经验信息，但是你没有途径把那些信息使用在将来的项目中。（我将在“应用你学到的”中讨论。）

从缺陷数据中分析和学习

你的缺陷库是个藏宝库。是你的质量失误的记录，因此是你在将来的项目去改进质量的机会。如果你没有记录你的产品缺陷，那么今天是一个好的起点。如果你已经在收集一些缺陷数据（例如，只是在发布后或只是那些重大的或开发后期的），那么你可能需要扩展你的收集范围。

对质量改进有用的缺陷数据包括：

l 什么错了？这不是现象，而是需要修正的问题。例如：“无限循环”是一个现象；“重复使用同一个指针”是一个问题。

l 问题是什么时候产生的？那个特定的开发活动是问题的原因？是需求分析工程吗？系统设计？代码？测试？（对，我们在修正其他bug的时候引入了缺陷。）

l 什么时候诊断出问题？它不能被马上修正，但是我们关心的是它存在了多长时间而没有被发现。

l 问题是如何被发现的？那可能是你可以在后面持续使用的测试方法。什么时候问题被发现了？是否存在上游的QC过程没有有效地发挥应有的作用？

l 它导致的代价有多大？它很容易理解。确保考虑了所有这些诊断和需要重新做的工作，包括重新设计、重新编码、重新编译、重新构建、重写测试用例、重新测试、重新发布、补丁发布、管理缺陷报告、报告状态等等。（不要忘记那些不可挽回的损失，像在市场上的困窘。）

l 那是什么类型的错误？当你有一大堆的缺陷（谁没有呢？），对缺陷进行分类可以对分析和学习有所帮助。

当你分析你的缺陷数据，寻找那些经常发生的缺陷，还有那些带来严重损失的缺陷时。你会发现这些缺陷就是你要在将来避免的（或者至少要在开发中早点发现），因为这些能最大限度改进质量。

应用你学到的

很多我提到的QA活动会帮助你获得关于提高产品质量的机会的信息。但是这些信息本身不能确保质量。你必须采取具体的行动来应用它们。例如，如果你的设计流程在某些特定类型的项目中过于烦琐而无法有效使用时，你必须想出另外的替换流程和在将来的项目中使用它。

有规律地（例如，每年、每个月、每天），停一停，识别改进的机会，然后调整你的标准、流程和方法来使那些改进得以整合。如果没有特地计划好并让某人尽到他的责任，这个活动则不会发生。

最后，你的项目初始流程必须包括从一个前面的项目学习的步骤。寻找经验库和缺陷历史来决定你的项目应该做哪些与前面的项目不一样的事情。这一次你能采取什么行动来确保更好的质量？再一次强调，这个明确的任务必须在项目初始时刻进行，否则它会被忽略而忙于启动每个新的项目。

开始QA

如果你的组织正在做一些我讲的事情，那么你们已经开始走向一个真正的有质量意识的组织。认识到那些QA活动是什么，让它们在有机会发挥价值的地方扩展它们。

如果你的组织还未参与真正的质量保证活动，那么你有很好的机会去改进你过去项目的表现。但是在你获得任何益处之前，你必须算算你的组织在低质量方面付出的成本。为了这个成本数据，你的组织可以指定一个人或一个组织负责QA并代表权威来执行我所说的那些行动。

质量保证主要是一个学习过程：学习不能很好工作的和你能改进的；学习那些能很好地工作的，它能工作的上下文，并把它制定成程序；学习如何在每一个你承担的项目中把工作做得更好。

任何一个实行质量保证工作的组织都是一个学习型的组织。第一个步骤就是学习如何把质量保证作为你的一个工作的标准部分。然后A才真正代表Assurance（保证）。