经常有这么一个问题：QA为什么对过程改进有帮助。答案当然与如何理解、如何管理、如何处理QA与项目之间的关系密不可分。这里有很多议素我们需要好好探讨。其中一个比较实在一点的，就是如何让QA可以在审核之中，发现项目是否遵从标准规程之余，还能否发现可以提高项目效率的机会，并且提出有针对性地建议，让项目可以更有效地达成项目的目标。
QA审核的内容，通常都可以从审核的检查单之中看到一个端倪。如果检查单里的问题，他们的答案明显与项目的效能无关的，按照这样的检查单审核，就当然不能发现如何帮助项目提高效能。所以我提到QA需要制定“有效性”的检查单。
问题立刻出现了，就是“什么样的检查单才是有效性的检查单？”本文的目的就是希望解答这个问题。
让我首先作几个声明：
1）当我们谈“有效性”审核的时候，我们不是说“遵从性”的审核不好。我希望强调一点：“遵从性”是制度化与成熟程度的基础。没有了遵从性的团队、组织，是不成熟的，过程操作一般是低效的。只有具备了一定程度上的遵从性，过程管理才能开始生效。请大家明白这一点。
所以我们谈有效性审核，其实是说在遵从性审核的基础上，考虑有效性的问题。这是一个能力水平的提升，而不是一个对标准规程的叛逆。
2）要提升过程的效能，因为每一个项目团队能力、风格不一样，是需要针对性的。这些针对性，就反映在调整检查单上面。我也遇到过这样的问题：“QA的标准规程里有标准的检查单，我们是否必须者用同样的检查单，才是符合标准的QA审核？”
我希望说明的就是：在符合标准要求的情况下，进行部分的调整是可以容许的。这个概念，就体现在 CMMI 要求标准规程里提供“适配”，并要求制定适配的准则。我们需要了解这一点。当然这个需要对规程与过程管理具备一定的了解与判断能力。这些知识与经验是需要积累的。
3）千万不要认为只有一个方法制定检查单。做任何事情，都有很多实际方法、途径可以完成。这里只是一个案例。我希望大家可以看到要考虑什么问题，要如何思维，然后发展自己的观察、分析、判断等能力，这才是最重要的。
好了，我们就谈谈如何制定“有效性”的检查单吧。我拿了一个案例来说明。这个案例是一个组织在使用的，用来审核“估算”的标准检查单。这里就来说明如何从这个检查单开始，加入“有效性”因素的考虑，来达到一个既满足本来的遵从性审核任务，也可以反映项目的操作是否有效的检查单。
制定有效性检查单的步骤：
1）我们要知道，“有效性”就是能够达到目标。如果没有目标，或是QA不清楚目标，有效性是无从谈起的。
所以QA一定需要知道检查单上面每一个条款，如何与项目的目标相关联。
2）符合性与有效性既相互关连，也相互独立。如果要过程有效，我们需要建立制度化。制度化的一个条件，就是每一个员工都需要有愿意遵从规程，符合规程的意愿。我们需要用一种大家都了解的，一致的方法，来处理日常的、或是不理想的、特殊的情况。要过程改进，我们就需要有遵从的纪律。
所以有效性是建立在“遵从、符合”的基础上的。
另一方面，如果规程制定得不合理，或是缺乏灵活性，来适应不同的项目、技术、产品。比如，无论项目大小，周期长短，都要求用“Wideband Delphi”进行估算。这就不灵活了。短周期的小项目就很不适合了。又或是要求严格复杂的测试用例分析、策划等等，也有同样的问题。那么，项目的过程就是符合，也不会有效。
所以QA需要具备专业态度与独立精神来处理现实中“符合性”与“有效性”的冲突与一致。
3）因为过程有效性，就是能够达到目标。那么，审核过程的有效性，就需要判断。所以一定要求审核的人（QA）具备这种判断能力，而不是期待把检查单细化到没有判断能力的人也可以实施。
举一个例子，如果检查单里的问题是：
一）估算是否按计划的时间完成？ 那么谁都可以判断。但这不是有效性的。因为我们没有考虑不按计划的时间完成是否影响项目的目标。
二）估算完成的时间是否对项目达成目标造成风险？这个问题才是有效性的。那么，就需要判断了。我们不能够有效地定义：超时两天就可以，三天就不可以。这在大部分的情况底下其实是不可能的。能够回答这类问题的人，需要有判断能力。
这是为什么我们要求QA不断提高自己的能力的原因。
谈到QA能力，我在这里先问一下：我们可否识别“子过程的目标”与“审核子过程的目标”？我们需要能够分辨这个。举一个例子：“同级评审”的目标，就是发现缺陷。但是为什么我们要审核“同级评审”这个子过程？那么目标就可以有很多：比如，作为考核的依据；查看项目是否遵从标准规程；评价这个子过程的操作实效；发现项目是否具备实施同级评审的技巧，等等。我们一定要能够分辨这些不同层次的目标。
4）总结一下：要从事有效性的审核也好，制定有效的规程也好，就需要考虑：
每一个条款或是步骤是为什么，要解决什么问题？ （要解决什么？）
这个条款或是步骤有什么后果？ （有什么后果？）
这些要解决的问题与实施后果如何影响项目的目标？（对项目的影响与风险）
这些就是QA需要能够回答的问题。
QA需要养成一个考虑这些问题的习惯来建立自己回答这些问题的能力。
5）假设我们已经具备这些能力，那么制定有效性的检查单就不难了。第一个考虑的概念，就是“层次”。假设EPG提交了一个检查单，如下：
检查项包括：
是否按时进行了二次估算？
作者是否参与集成测试活动估算？
作者是否参与各模块开发活动估算？
开发相关人员是否都参与集成测试活动估算？
是否会议方式估算？
详细设计估算是否完整有效？
编码估算是否完整有效？
单元测试估算是否完整有效？
集成测试用例估算是否完整有效？
集成测试执行估算是否完整有效？
偏差超过约定的偏差值是否再次估算？
是否完整填写估算人员姓名及过程数据？
估算报告是否及时归档？
我们可以看到，这个单里的条款，它们的重要性不是同一个层次的。这不是一个制定任何规程的好习惯。我们需要知道把同一个层次的条项罗列在同一个层面上。比如：
是否按时进行了二次估算？
作者是否参与集成测试活动估算？
有哪些与这个估算相关的活动？
作者是否参与各模块开发活动估算？
开发相关人员是否都参与集成测试活动估算？
是否会议方式估算？
有哪些与这个估算相关的绩效？
详细设计估算是否完整有效？
编码估算是否完整有效？
单元测试估算是否完整有效？
集成测试用例估算是否完整有效？
集成测试执行估算是否完整有效？
偏差超过约定的偏差值是否再次估算？
估算报告是否及时归档？
层次这个概念在很多地方都有应用。看看我们公司的结构，你就可以体会到层次的普遍应用程度。不同层次的，就不会在同一个级别的领导之下。比如，生产、财务、市场都是在同一个层次上。我们不会把“融资”放在同一个层次，它一定是在财务底下的。
层次会影响效率。比如我们的检查单，合理的层次，会让员工与QA更明确各个部分的重要性，在开展工作的时候也可以更好地掌握注意力。
要了解层次，可以这样看：同一个层次的，是比较相对独立，互不影响的。低一个层次的，是它上面层次的一部分，或者说，是会对上面层次的提供贡献。比如：“是否按时进行了二次估算？”和“有哪些与这个估算相关的活动？”是相对独立的。但“作者是否参与各模块开发活动估算？”就是与估算相关的活动之一。这个有点像CMMI的级别定义原则。这些都是帮助有效的理念，并且被广泛应用在过程管理与以外的很多方面的。
检查单的组织可以考虑条项的层次。
如果不了解这个“层次”的观念，就请你提问。我们务必交流清楚。
6）下一步就是分辨符合性与有效性。还记得上面提到的三个考虑么：
每一个条款或是步骤是为什么，要解决什么问题？（要解决什么？）
这个条款或是步骤有什么后果？ （有什么后果？）
这些要解决的问题与实施后果如何影响项目的目标？（对项目的影响与风险）
我们要知道，如果问题是：
是否按时进行了二次估算？
我们的答案就会是“是”或是“否”。这个问题要解决的，就是：你是否遵从计划？是一个符合性的问题。所以解答这个问题一点都不难。但是如果问题是：
完成二次估算的时间对项目有什么影响？
这个问题要知道完成时间对项目有什么影响，要知道估算知否有效。这才是有效性的检查项。回答这个问题就一点都不简单。我们要知道这个完成时间有什么后果。早于计划的要求完成？按计划时间要求完成？超时了？超了一点点？超了很多？还有更厉害的：这个模块/任务是否在关键路径上面？我们要知道所有这些，可能还有其他的，才能作一个判断。做这个判断，就要知道关键因素与它们的后果。比如：
估算晚了两个星期。但这是一个2 年的项目，而且这个任务可以有5 个星期的灵活性。那么，这样晚了两个星期的作用就不很大。他是不符合。但后果不大。
如果估算晚了两个星期，项目是2 年的项目，而且任务是在关键路径上。后果就可能让项目延误两星期。是大概2 %的延误。这样的延误，绝大部分客户可能发现（重要），但都不会太计较的（不严重）。
如果估算晚了两天，任务在关键路径，项目是2个月的项目。这样问题就严重好多了。
所以如果要作有效性审核，我们需要知道关键因素，以及他们的后果。
一个步骤的目的，如果单单是看项目是否符合，而不考虑后果的，这样的管理，目的就是在于“限制行为”。限制或是规范行为的坏处，就是引起项目的抗拒。所以“限制行为”的管理很难有好效果的。
7）那么，我们可以开始把这些关键因素组织一下，为把检查单改变成为有效性的检查单做准备。我们需要把原本的改成符合与有效兼顾，并且增加一些遗漏的关键因素。首先，我们可以把下面的条项：
是否按时进行了二次估算？
作者是否参与集成测试活动估算？
有哪些与这个估算相关的活动？
作者是否参与各模块开发活动估算？
开发相关人员是否都参与集成测试活动估算？
是否会议方式估算？
有哪些与这个估算相关的绩效？
详细设计估算是否完整有效？
编码估算是否完整有效？
单元测试估算是否完整有效？
集成测试用例估算是否完整有效？
集成测试执行估算是否完整有效？
偏差超过约定的偏差值是否再次估算？
估算报告是否及时归档？
小心看一下，用提高效率的观点，考虑每一个条项的后果，改编成有效性的条款，如下：
估算完成的时间对项目的影响：
作者乐于承诺估算结果的程度与原因：
（暂时忽略）
估算的方法与过程保证了估算的合理性：
（暂时忽略）
（暂时忽略）
估算结果得到维护与使用：（包含了“估算报告是否及时归档？”）
我们现在加入我提到的三个因素：
负责任务的人亲自牵头估算
大家（项目组与客户）对任务范围与内容的认识是一致的。
方法与参考数据的使用是合理的
检查单就变成：（斜字代表这个步骤新加进来的。）
估算完成时间对项目的影响：
作者乐于承诺估算结果的程度与原因：
负责任务的人牵头估算
估算的方法与过程保证了估算的合理性：
大家对任务范围与内容有一致的认识
估算方法适合项目要求
方法的调整是合理的
估算结果得到维护与使用：
项目计划使用了估算结果来安排任务
如果需要，可以把原来的符合性的放回去。可以把它们放在另一个部分，也可以把它们放在适合的层次。比如：
估算完成得时间对项目的影响：
· 是否按时进行了二次估算？
作者乐于承诺估算结果的程度与原因:
· 负责任务的人牵头估算
估算的方法与过程保证了估算的合理性:
· 大家对任务范围与内容有一致的认识
· 估算方法适合项目要求
· 方法的调整是合理的
· 是否会议方式估算？
· 作者是否参与各模块开发活动估算？
· 开发相关人员是否都参与集成测试活动估算
· （如果用Delphi方法）偏差超过约定的偏差值是否再次估算？
估算结果得到维护与使用：
· 估算结果在计划里项目计划使用了估算结果来安排任务
· 估算报告是否及时归档？
以往估算的绩效：
· 详细设计估算是否完整有效？
· 编码估算是否完整有效？
· 单元测试估算是否完整有效？
· 集成测试用例估算是否完整有效？
· 集成测试执行估算是否完整有效？
现在的检查单包含了本来的条项，也包括了从有效性的角度的内容。但有效性方面还是不充分的。所以我们需要每一个条项都问这个问题：
我如何可以判断这些条项的有效程度？这个也需要我们了解过程的关键因素！
上面已经提到过估算的完成时间如何影响项目。包括延误的比率、客户的要求、任务是否在关键路径等等。其他的，我就把我考虑的加到相关的条项底下，如下：
估算完成得时间对项目的影响：
· 是否按时进行了二次估算？
· 延误程度对比项目的里程碑与周期的影响有多严重
· 延误如何对比任务的关键路径宽容时间
· 考虑这个任务的关键性与项目对它的依赖程度
作者乐于承诺估算结果的程度与原因:
· 负责任务的人牵头估算
· 判断负责人对结果的信心
· 查看负责人以前的承诺（按时完成任务）表现
估算的方法与过程保证了估算的合理性:
· 大家对任务范围与内容有一致的认识
o 在如下面两条罗列的估算活动以及其他情况底下，多方面的干系人的表达是一致的。
o 如果有开估算会议，讨论覆盖足够的内容与议素，但进行顺利，没有理解不一致的迹象。
o （还可以有其他的蛛丝马迹来判断）
· 估算方法的效能适合项目的目标
· 参考与使用的历史数据与对比、调整的合理性
· 是否会议方式估算？
· 作者是否参与各模块开发活动估算？
· 开发相关人员是否都参与集成测试活动估算？
· 偏差超过约定的偏差值是否再次估算？
估算结果得到维护与使用：
· 项目计划使用了估算结果来安排任务
· 项目明确有哪些活动受这个估算结果影响（可以更好处理将来的延误）
· 估算报告是否及时归档？
以往估算的绩效：
· 详细设计估算是否完整有效？
· 编码估算是否完整有效？
· 单元测试估算是否完整有效？
· 集成测试用例估算是否完整有效？
· 集成测试执行估算是否完整有效？
希望大家可以关注到这里检查点之间的关联性，以及我们的步骤如何影响项目的专注。
8）上面的表就是一个从你们本来使用的检查单，增加了审核有效性的角度而得来的。让我们把这个资料放到一个表格里：
大家可以补充“检查方法”这一列。大家也可以按这个思路，增、减因素与检查项的内容与细节。其实标准的检查单，也应该可以让大家按情况“调整”。请留意，我不说修改，而说调整，含义是：我们需要按标准的思路，让它更有效，而不是把内容随意变动。我说的明白么？
这样的表格跟以前的有两个分别：
语气是开放式的，不鼓励是否地打勾。每填一个条项，都希望QA知道需要明白后果。以后习惯了这样思维，我们就可以不那么关注语气的问题了。我鼓励大家目前还是在意一点比较好。
内容多了一些有效性的关键因素。这个是可以积累的。我们需要从工作中观察，以需要多讨论，多交流，多看书。一位QA发现一个关键因素之后，不能单单加到自己的检查单里。QA小组最好组织讨论会议，让每一位QA都知道一个关键因素的来龙去脉，原因后果。这样才能让QA团队的经验建立起来。
也请留意，每一个关键因素都有数个检查项，但对项目来说，同一个关键因素的所有检查项加起来只有一个后果，我们不单单在乎是否打勾，而是要判断项目的表现有什么后果。我们可以按关键因素预设一些后果。比如：超越预期、没有风险、有可承担的风险、有不可承担的风险、不可承担又不可缓解的风险等。项目的操作状态，就是这几个关键因素的执行后果。每一个关键因素的后果，都取决于它下面的检查项。但我以前也说过，我觉得每一项打分，然后加起来，不是一个很好的方法，因为有些条项的重要性，会因为其他的条项内容而改变的。我们可以这样做，然后参考那些分数。只是不要把分数看成决定一切就可以了。
想象一下，如果我们的QA审核报告都是这样的，大家就会越来越清楚如何提高项目的效率。将来的过程问题，大部分都可以从QA报告的历史资料找到答案。过程改进将会变得非常容易。
9）不要以为这是唯一的有效性检查单，所以不要把这个看成经典。有效性的检查单可以有很多。比如，我们如果不一定要求从你们本来的检查单开始，我们可以从我提到的三个因素开始。那么，检查单就会不一样。
我们要能够分辨得细一点，要争取了解细一点的议素。比如，不要把上面的检查单看成固定不变的。但也不要以为什么事情都不能是固定的。有些事情固定了，就不灵活，不能适应不同的情况，效果就不好。有些事情是不会改变的，改了，就没有效果了。如何判断呢？
基本上：
因果关系是不会变的。没有了因，就不会有果。
解决方案，就几乎永远都会有不同的方案，达到相同或是接近的效果。
要进步，我们就要慢慢掌握这些理念，并且能够把它应用到自己的工作上。
最新内容请见作者的GitHub页：http://qaseven.github.io/