经常有这么一个问题：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提交了一个检查单，如下：

审核子过程/活动
检查项
检查方法
二次估算
是否按时进行了二次估算？
按照PMS 计划本月要求评审完成的子系统方案都应该进行二次估算。
作者是否参与集成测试活动估算？
检查& 访谈&参与估算会议：
1、估算报告中是否有该子系统方案作者的估算记录。
2、访谈该子系统方案作者是否参与了估算。
作者是否参与各模块开发活动估算？
检查& 访谈&参与估算会议：
1、估算报告中是否有该子系统方案作者的估算记录。
2、访谈该子系统方案作者是否参与了估算。
开发相关人员是否都参与集成测试活动估算？
检查& 访谈&参与估算会议：
1、估算报告中是否有所有相关开发人员或开发科长/开发经理的估算记录。
2、访谈开发人员/开发科长/开发经理是否在估算前对估算对象进行了了解，并参与了估算。
重点关注参与估算的开发人员必须是这个模块的编写人员或者是这个模块负责的开发科长或开发经理。
开发相关人员是否都参与各模块开发活动估算？
检查& 访谈&参与估算会议：
1、估算报告中是否有所有相关开发人员或开发科长/开发经理的估算记录。
2、访谈开发人员/开发科长/开发经理是否在估算前对估算对象进行了了解，并参与了估算。
重点关注参与估算的开发人员必须是这个模块的编写人员或者是这个模块负责的开发科长或开发经理。
是否会议方式估算？
 
检查& 访谈&参与估算会议：
重点关注是否通过会议方式进行估算，并对估算结果达成共识。一般可在子系统方案的最后一次评审会上（要求在PMS进度计划中子系统方案评审任务完成时间点前）进行。
详细设计估算是否完整有效？
检查& 访谈&参与估算会议：
1、关注模块的完整性，即是否每个涉及的模块都有估算（例如：如果有涉及到网管的是否进行了估算）。
2、关注详细设计相关估算内容（详细设计文档规模、工作量、评审工作量）的完整性。
3、关注最终估算结果的合理性：每个估算对象的“估算结果”是否取自估算过程中偏差最小的“平均值”栏中结果（同时注意估算公式是否正确，项目组目前二次估算采用delphi方法）
编码估算是否完整有效？
检查& 访谈&参与估算会议：
1、关注模块的完整性，即是否每个涉及的模块都有估算（例如：如果有涉及到网管的是否进行了估算）。
2、关注编码相关估算内容（编码代码行、工作量）的完整性。
3、关注最终估算结果的合理性：每个估算对象的“估算结果”是否取自估算过程中偏差最小的“平均值”栏中结果（同时注意估算公式是否正确，项目组目前二次估算采用delphi方法）
单元测试估算是否完整有效？
检查& 访谈&参与估算会议：
1、关注模块的完整性，即是否每个涉及的模块都有估算（例如：如果有涉及到网管的是否进行了估算）。
2、关注单元测试相关估算内容（单元测试用例编写工作量、测试用例条目数、测试执行工作量）的完整性。
3、关注最终估算结果的合理性：每个估算对象的“估算结果”是否取自估算过程中偏差最小的“平均值”栏中结果（同时注意估算公式是否正确，项目组目前二次估算采用delphi方法）
集成测试用例估算是否完整有效？
检查& 访谈&参与估算会议：
1、关注集成测试用例相关估算内容（集成测试用例文档规模、用例数、工作量、评审工作量）的完整性。
2、关注最终估算结果的合理性：每个估算对象的“估算结果”是否取自估算过程中偏差最小的“平均值”栏中结果。（同时注意估算公式是否正确，项目组目前二次估算采用delphi方法）
集成测试执行估算是否完整有效？
检查& 访谈&参与估算会议：
1、关注集成测试第一阶段工作量/第二阶段估算内容的完整性。
2、关注最终估算结果的合理性：每个估算对象的“估算结果”是否取自估算过程中偏差最小的“平均值”栏中结果。（同时注意估算公式是否正确，二次估算采用delphi方法）
偏差超过约定的偏差值是否再次估算？
检查& 访谈&参与估算会议：
参与估算会议或者检查估算报告，针对估算偏差超过约定偏差值（目前项目组约定为50％）的估算项，关注是否保留有估算过程数据。
是否完整填写估算人员姓名及过程数据？
检查& 访谈：
检查估算报告中每个sheet中是否明确填写估算人员姓名，以及每个估算人员的估算过程数据，必要时进行访谈。
估算报告是否及时归档？
检查：关注是否在PMS 进度计划中对应子系统方案评审任务完成时间点前及时归档到SVN中“子系统设计/二次估算”目录下
 
检查项包括：
  1. 是否按时进行了二次估算？
  2. 作者是否参与集成测试活动估算？
  3. 作者是否参与各模块开发活动估算？
  4. 开发相关人员是否都参与集成测试活动估算？
  5. 是否会议方式估算？
  6. 详细设计估算是否完整有效？
  7. 编码估算是否完整有效？
  8. 单元测试估算是否完整有效？
  9. 集成测试用例估算是否完整有效？
  10. 集成测试执行估算是否完整有效？
  11. 偏差超过约定的偏差值是否再次估算？
  12. 是否完整填写估算人员姓名及过程数据？
  13. 估算报告是否及时归档？
我们可以看到，这个单里的条款，它们的重要性不是同一个层次的。这不是一个制定任何规程的好习惯。我们需要知道把同一个层次的条项罗列在同一个层面上。比如：
  1. 是否按时进行了二次估算？
  2. 作者是否参与集成测试活动估算？
  3. 有哪些与这个估算相关的活动？
    1. 作者是否参与各模块开发活动估算？
    2. 开发相关人员是否都参与集成测试活动估算？
  4. 是否会议方式估算？
  5. 有哪些与这个估算相关的绩效？
    1. 详细设计估算是否完整有效？
    2. 编码估算是否完整有效？
    3. 单元测试估算是否完整有效？
    4. 集成测试用例估算是否完整有效？
    5. 集成测试执行估算是否完整有效？
  6. 偏差超过约定的偏差值是否再次估算？
  7. 估算报告是否及时归档？
层次这个概念在很多地方都有应用。看看我们公司的结构，你就可以体会到层次的普遍应用程度。不同层次的，就不会在同一个级别的领导之下。比如，生产、财务、市场都是在同一个层次上。我们不会把“融资”放在同一个层次，它一定是在财务底下的。
 
层次会影响效率。比如我们的检查单，合理的层次，会让员工与QA更明确各个部分的重要性，在开展工作的时候也可以更好地掌握注意力。
 
要了解层次，可以这样看：同一个层次的，是比较相对独立，互不影响的。低一个层次的，是它上面层次的一部分，或者说，是会对上面层次的提供贡献。比如：“是否按时进行了二次估算？”和“有哪些与这个估算相关的活动？”是相对独立的。但“作者是否参与各模块开发活动估算？”就是与估算相关的活动之一。这个有点像CMMI的级别定义原则。这些都是帮助有效的理念，并且被广泛应用在过程管理与以外的很多方面的。
 
检查单的组织可以考虑条项的层次。
 
如果不了解这个“层次”的观念，就请你提问。我们务必交流清楚。
 
6）下一步就是分辨符合性与有效性。还记得上面提到的三个考虑么：
  • 每一个条款或是步骤是为什么，要解决什么问题？（要解决什么？）
  • 这个条款或是步骤有什么后果？ （有什么后果？）
  • 这些要解决的问题与实施后果如何影响项目的目标？（对项目的影响与风险）
我们要知道，如果问题是：
  1. 是否按时进行了二次估算？
我们的答案就会是“是”或是“否”。这个问题要解决的，就是：你是否遵从计划？是一个符合性的问题。所以解答这个问题一点都不难。但是如果问题是：
  1. 完成二次估算的时间对项目有什么影响？
这个问题要知道完成时间对项目有什么影响，要知道估算知否有效。这才是有效性的检查项。回答这个问题就一点都不简单。我们要知道这个完成时间有什么后果。早于计划的要求完成？按计划时间要求完成？超时了？超了一点点？超了很多？还有更厉害的：这个模块/任务是否在关键路径上面？我们要知道所有这些，可能还有其他的，才能作一个判断。做这个判断，就要知道关键因素与它们的后果。比如：
 
估算晚了两个星期。但这是一个2 年的项目，而且这个任务可以有5 个星期的灵活性。那么，这样晚了两个星期的作用就不很大。他是不符合。但后果不大。
如果估算晚了两个星期，项目是2 年的项目，而且任务是在关键路径上。后果就可能让项目延误两星期。是大概2 %的延误。这样的延误，绝大部分客户可能发现（重要），但都不会太计较的（不严重）。
 
如果估算晚了两天，任务在关键路径，项目是2个月的项目。这样问题就严重好多了。
 
所以如果要作有效性审核，我们需要知道关键因素，以及他们的后果。
 
一个步骤的目的，如果单单是看项目是否符合，而不考虑后果的，这样的管理，目的就是在于“限制行为”。限制或是规范行为的坏处，就是引起项目的抗拒。所以“限制行为”的管理很难有好效果的。
 
7）那么，我们可以开始把这些关键因素组织一下，为把检查单改变成为有效性的检查单做准备。我们需要把原本的改成符合与有效兼顾，并且增加一些遗漏的关键因素。首先，我们可以把下面的条项：
  1. 是否按时进行了二次估算？
  2. 作者是否参与集成测试活动估算？
  3. 有哪些与这个估算相关的活动？
    1. 作者是否参与各模块开发活动估算？
    2. 开发相关人员是否都参与集成测试活动估算？
  4. 是否会议方式估算？
  5. 有哪些与这个估算相关的绩效？
    1. 详细设计估算是否完整有效？
    2. 编码估算是否完整有效？
    3. 单元测试估算是否完整有效？
    4. 集成测试用例估算是否完整有效？
    5. 集成测试执行估算是否完整有效？
  6. 偏差超过约定的偏差值是否再次估算？
  7. 估算报告是否及时归档？
小心看一下，用提高效率的观点，考虑每一个条项的后果，改编成有效性的条款，如下：
  1. 估算完成的时间对项目的影响：
  2. 作者乐于承诺估算结果的程度与原因：
  3. （暂时忽略）
  4. 估算的方法与过程保证了估算的合理性：
  5. （暂时忽略）
  6. （暂时忽略）
  7. 估算结果得到维护与使用：（包含了“估算报告是否及时归档？”）
我们现在加入我提到的三个因素：
  • 负责任务的人亲自牵头估算
  • 大家（项目组与客户）对任务范围与内容的认识是一致的。
  • 方法与参考数据的使用是合理的
检查单就变成：（ 斜字代表这个步骤新加进来的。）
  1. 估算完成时间对项目的影响：
  2. 作者乐于承诺估算结果的程度与原因：
    1. 负责任务的人牵头估算
  3. 估算的方法与过程保证了估算的合理性：
    1. 大家对任务范围与内容有一致的认识
    2. 估算方法适合项目要求
    3. 方法的调整是合理的
  4. 估算结果得到维护与使用：
    1. 项目计划使用了估算结果来安排任务
如果需要，可以把原来的符合性的放回去。可以把它们放在另一个部分，也可以把它们放在适合的层次。比如：
  1. 估算完成得时间对项目的影响：
·   是否按时进行了二次估算？
  1. 作者乐于承诺估算结果的程度与原因:
·   负责任务的人牵头估算
  1. 估算的方法与过程保证了估算的合理性:
·  大家对任务范围与内容有一致的认识
·  估算方法适合项目要求
·  方法的调整是合理的
·   是否会议方式估算？
·   作者是否参与各模块开发活动估算？
·   开发相关人员是否都参与集成测试活动估算
·  （如果用Delphi方法）偏差超过约定的偏差值是否再次估算？
  1. 估算结果得到维护与使用：
·   估算结果在计划里项目计划使用了估算结果来安排任务
·    估算报告是否及时归档？
  1. 以往估算的绩效：
·   详细设计估算是否完整有效？
·   编码估算是否完整有效？
·   单元测试估算是否完整有效？
·   集成测试用例估算是否完整有效？
·   集成测试执行估算是否完整有效？
 
现在的检查单包含了本来的条项，也包括了从有效性的角度的内容。但有效性方面还是不充分的。所以我们需要每一个条项都问这个问题：
 
我如何可以判断这些条项的有效程度？这个也需要我们了解过程的关键因素！
 
上面已经提到过估算的完成时间如何影响项目。包括延误的比率、客户的要求、任务是否在关键路径等等。其他的，我就把我考虑的加到相关的条项底下，如下：
  1. 估算完成得时间对项目的影响：
·   是否按时进行了二次估算？
·   延误程度对比项目的里程碑与周期的影响有多严重
·   延误如何对比任务的关键路径宽容时间
·   考虑这个任务的关键性与项目对它的依赖程度
  1. 作者乐于承诺估算结果的程度与原因:
·  负责任务的人牵头估算
·  判断负责人对结果的信心
·   查看负责人以前的承诺（按时完成任务）表现
  1. 估算的方法与过程保证了估算的合理性:
·  大家对任务范围与内容有一致的认识
o    在如下面两条罗列的估算活动以及其他情况底下，多方面的干系人的表达是一致的。
o    如果有开估算会议，讨论覆盖足够的内容与议素，但进行顺利，没有理解不一致的迹象。
o    （还可以有其他的蛛丝马迹来判断）
· 估算方法的效能适合项目的目标
·  参考与使用的历史数据与对比、调整的合理性
·  是否会议方式估算？
·  作者是否参与各模块开发活动估算？
·  开发相关人员是否都参与集成测试活动估算？
·   偏差超过约定的偏差值是否再次估算？
  1. 估算结果得到维护与使用：
·  项目计划使用了估算结果来安排任务
·   项目明确有哪些活动受这个估算结果影响（可以更好处理将来的延误）

 

·  估算报告是否及时归档？
  1. 以往估算的绩效：
·  详细设计估算是否完整有效？
·  编码估算是否完整有效？
·  单元测试估算是否完整有效？
·  集成测试用例估算是否完整有效？
·  集成测试执行估算是否完整有效？
 
希望大家可以关注到这里检查点之间的关联性，以及我们的步骤如何影响项目的专注。
 

8）上面的表就是一个从你们本来使用的检查单，增加了审核有效性的角度而得来的。让我们把这个资料放到一个表格里：

因素
后果
检查项
检查方法
符合
估算完成得时间对项目的影响
 
是否按时进行了二次估算？
 
 
延误程度对比项目的里程碑与周期的影响有多严重
 
 
延误如何对比任务的关键路径宽容时间
 
 
考虑这个任务的关键性欲项目对它的依赖程度
 
 
作者乐于承诺估算结果的程度与原因
 
负责任务的人牵头估算
 
 
判断负责人对结果的信心
 
 
查看负责人以前的承诺（按时完成任务）表现
 
 
估算的方法与过程保证了估算的合理性
 
大家对任务范围与内容有一致的认识
 
 
估算方法的效能适合项目的目标
 
 
参考与使用的历史数据与对比、调整的合理性
 
 
是否会议方式估算？
 
 
作者是否参与各模块开发活动估算？
 
 
开发相关人员是否都参与集成测试活动估算？
 
 
估算结果得到维护与使用
 
项目计划使用了估算结果来安排任务
 
 
项目明确有哪些活动受这个估算结果影响
 
 
估算报告是否及时归档？
 
 
偏差超过约定的偏差值是否再次估算？
 
 

 

 

 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
大家可以补充“检查方法”这一列。大家也可以按这个思路，增、减因素与检查项的内容与细节。其实标准的检查单，也应该可以让大家按情况“调整”。请留意，我不说修改，而说调整，含义是：我们需要按标准的思路，让它更有效，而不是把内容随意变动。我说的明白么？
这样的表格跟以前的有两个分别：
  1. 语气是开放式的，不鼓励是否地打勾。每填一个条项，都希望QA知道需要明白后果。以后习惯了这样思维，我们就可以不那么关注语气的问题了。我鼓励大家目前还是在意一点比较好。
  2. 内容多了一些有效性的关键因素。这个是可以积累的。我们需要从工作中观察，以需要多讨论，多交流，多看书。一位QA发现一个关键因素之后，不能单单加到自己的检查单里。QA小组最好组织讨论会议，让每一位QA都知道一个关键因素的来龙去脉，原因后果。这样才能让QA团队的经验建立起来。
也请留意，每一个关键因素都有数个检查项，但对项目来说，同一个关键因素的所有检查项加起来只有一个后果，我们不单单在乎是否打勾，而是要判断项目的表现有什么后果。我们可以按关键因素预设一些后果。比如：超越预期、没有风险、有可承担的风险、有不可承担的风险、不可承担又不可缓解的风险等。项目的操作状态，就是这几个关键因素的执行后果。每一个关键因素的后果，都取决于它下面的检查项。但我以前也说过，我觉得每一项打分，然后加起来，不是一个很好的方法，因为有些条项的重要性，会因为其他的条项内容而改变的。我们可以这样做，然后参考那些分数。只是不要把分数看成决定一切就可以了。
 
想象一下，如果我们的QA审核报告都是这样的，大家就会越来越清楚如何提高项目的效率。将来的过程问题，大部分都可以从QA报告的历史资料找到答案。过程改进将会变得非常容易。
 
9）不要以为这是唯一的有效性检查单，所以不要把这个看成经典。有效性的检查单可以有很多。比如，我们如果不一定要求从你们本来的检查单开始，我们可以从我提到的三个因素开始。那么，检查单就会不一样。
我们要能够分辨得细一点，要争取了解细一点的议素。比如，不要把上面的检查单看成固定不变的。但也不要以为什么事情都不能是固定的。有些事情固定了，就不灵活，不能适应不同的情况，效果就不好。有些事情是不会改变的，改了，就没有效果了。如何判断呢？
 
基本上：
  • 因果关系是不会变的。没有了因，就不会有果。
  • 解决方案，就几乎永远都会有不同的方案，达到相同或是接近的效果。
要进步，我们就要慢慢掌握这些理念，并且能够把它应用到自己的工作上。