[思变到改进]看测试计划到测试管理计划的演变

 

前言：本次备战大概是半年前开始的，目的是熟悉PMP九大知识域，并将其中的管理思想和技术方法实践在自己的项目管理过程中。

现将一些自己在测试管理过程中，对测试计划的思考和整理的部分分享出来。希望能有所共鸣，特别是PMP2004版本以后对于项目成功的定义标准转变，这是促使我对这个管理计划第三版修改的直接原因。

 

 最初测试计划，按照我所接触的内容大致包括以下内容：

1)      测试范围：功能和非功能测试需求、测试需求基线、测试需求阶段、测试选择类型和模型、过程剪裁、测试需求风险评估。

2)      测试策略：测试类型(功能测试、性能测试、安装测试、配置测试、文档测试、界面测试、数据库测试)等；

3)      质量管理：测试类型与测试阶段；

4)      测试准入标准及结束标准：测试通过标准、转测标准、系统测试结束标准、性能测试准入条件、性能测试完成条件、测试监控方法等；

5)      测试组织结构：组织形式、角色和职责；

6)      测试工作内容：测试阶段交付物；

7)      测试交付工件列表：交付物清单；

8)      测试时间进度表：里程碑时间轴。

它的主要作用是将测试范围给予界定，并通过对测试产品的分析提出合理的测试方法论指导项目团队开展测试工作。

 

第一版的计划大概是在07年年初设计的，这个时候对于管理的计划概念仅仅停留着概括性阶段，主要是将项目的资源、范围概括性进行描述。测试计划本身对测试工作指导意义不大，且内容复杂文字描述过多。

 

总体来说第一版的计划信息量是很大的，个人觉得涉及面还是基本都说到了。但是对于实际测试工作指导意义不大，特别是在测试组织结构比较复杂的时候，每个测试组和个人的操作风格很难统一。这样会导致测试分析的思路不一致、测试设计的质量决定于人员自身修炼和项目经验。如何才能将项目团队的功效发挥到最大呢？08年，这个问题一直困扰着我们。我们开始反思测试计划本身的问题：

1)      第一个问题：测试计划缺少阅读指引；

07年的时候我们发现测试计划写出来也没人看，到了项目结束的时候项目经理可能连计划多少轮测试都不清楚。为什么没人看？是因为信息不够多么？信息不够全么？测试计划没有阅读指引，发给项目团队人员就成走马观花。

2)      第二个问题：过程剪裁太粗略；

直接导则的问题是，刚搞管理的人。对过程剪裁一片迷糊，到底什么项目能够剪裁。剪裁到什么程度是合适的。

3)      第三个问题：测试策略过于泛化；

这个问题是在与华为合作部交流以后体会到的。测试策略本身有两个作用，第一是策略是一种方法论。即是我们07年已经实现的内容，比如对于功能测试而言我们的测试重心在什么地方，怎么做测试分析和设计工作。第二层则是在交流以后感悟到的，即策略是一种思想整合。如果你需要项目团队按照统一的分析思路、设计方法去做一件事，则在测试策略上就需要在前期保持一致性。特别是对于大型产品的测试而言，尤其重要。否则，就可能出现测试粒度定义不同，测试覆盖不完全的结果。这对于测试经理来说是极其恐怖的。

4)      第四个问题：项目整体目标、阶段目标定义不清；

这个问题在07年的时候是很严重的。为什么会出现如此巨大的进度偏差，在分析了07年的项目数据后发现项目整体目标(商业目标/系统目标)不清晰是导致项目进度延期最大问题。也就是说，项目计划中没有明确的告诉项目经理所要达到阶段目标是什么样的，没有Smart衡量标准、时间约束、条件约束。出了问题，没有明确的排查方案和时间计划。阶段收尾后，没有一个量化的数据为下一个启动过程提供决策素材。

5)      第五个问题：项目责权不清；

这个问题也在项目中时有发生。比如说：需求没有明确的接口人，项目经理的工作也比较乱。需求到了测试后期，变的无法控制。没有定义CCB决策等级、变更审核和批准人等。责权的问题，我觉得主要暴露在接口人上。模块的负责人是谁，谁来组织去处理模块内部的事物，这一点很关键，不然我们要花很多时间在无谓的沟通上，会造成测试组的工作急剧膨胀。

6)      第六个问题：缺少里程碑与交付物交互关系。

这个问题会导致QA在审计测试计划的时候，无法掌握计划的监控点。包括自己在带项目的时候，监控的频度是很难掌握的，频度太高会造成项目组工作量的增加且可能无法完成正事，造成抵触情绪。监控的频度太低，会造成项目失控，导致项目延迟或者失败。

 

08年针对以上的六个问题，做了一些调整。主要思路是解决测试思路的整合以及测试计划信息延展性。

分别解释一下这两块内容：

1)      测试思路的整合：主要的工作是加入了针对功能模块的测试策略分解，核心观点的是整合思路。比如说：我们尝试使用Freemind或者MindMangaer的技术对被测试对象进行分解和推演。特别对于异常分支和各种条件假设分析效果分析非常好，这个分析过程也可以辅助开发来进一步了解系统的结构。其次，是通过归类分析的技巧将新变动部分及继承部分内容分开，从而能够较为准确的估计工作量、评估变动范围。

2)      测试计划信息延展性：主要的工作是使原测试计划信息交互性更强，在项目测试过程中发挥的用处更大。也就是说，在两个过程组之间需要通过测试计划来做连接。其核心是要将计划中指导过程，延续在实际项目测试过程中，为项目经理、PMO委员会、QA以及其它干系人提供更丰富的项目过程信息。

通过精简和集成08年测试计划修改为以下框架：

1)      测试范围：功能和非功能测试需求、测试需求基线、测试需求阶段、测试选择类型和模型、过程剪裁、测试需求风险评估。

2)      测试策略：测试类型(功能测试、性能测试、安装测试、配置测试、文档测试、界面测试、数据库测试)等；

3)      测试方案：模块测试策略、测试框架、测试风险等；

4)      质量管理：测试类型与测试阶段；

新加入：需求列表、测试指标、结束标准、用例目标、质量目标，主要强调阶段性；

5)      测试准入标准及结束标准：测试通过标准、转测标准、系统测试结束标准、性能测试准入条件、性能测试完成条件、测试监控方法等；

6)      测试组织结构：组织形式、角色和职责；

新修改：项目组织结构、接口人(需求、协调)、干系人的期望，主要强调职责部分；

7)      交付物清单：里程碑交付物，主要强调监控时机；

8)      测试时间进度表：里程碑时间轴。(删除，放入Project中管理)

 

经过09年10个月使用和评估，我们觉得第二版本的测试计划主要解决过程指导的问题。项目经理对于测试计划的认知度更高，约束力更强。如果项目经理没有意识去看测试计划，可能会导致他自身的工作分配不合理。这一点是非常值得欣慰的。至少测试计划不在是个摆设了，项目团队对于它有一定依赖关系了。下一步改进的动力在哪里呢？来看看我们遇到的问题吧：

1)      第一个问题：需求跟踪矩阵(责权和关联)；

08年公司引入新的需求管理方式，即需求跟踪矩阵。但是，由于测试计划是Word版本的。其测试需求是嵌入在内的，这样就导致了更新测试计划非常麻烦。这样，原本引入测试需求跟踪和计划本身脱离开来，需求到了后期同样会出现不一致的情况。如何才能解决这个问题呢？其核心是要考虑一种整体变更方法和流程，从需求入手由变更来控制项目的范围以及成本和质量。

2)      第二个问题：进度紧张资源分配不合理；

分析Project中的一些项目计划，可以看出对于人员分配有些及不合理。比如：一些项目中可能出现单个人员单天工时超过500%的情况。如何才能有效平衡时间、成本、质量三者的关系呢？交付时间紧张的时候，什么是我们必须要保证的部分，哪些部分能够申请不测试或者需要一定介入条件。这就是范围管理部分，没有约束清楚的、界定模糊所致。这里还包括如何去做估算，估算的约束条件、影响因数等等。

3)      第三个问题：缺少整体变更机制；

这个问题其实提出来是在09年年初的时候。以前我们认为整体变更是需要QA参与的，必须由质量部门发起这种过程改进。但是，随着项目历程不断深入，在没有QA参与整体管理的时候，管理成本越来越高。整体变更机制，是第三版计划核心要考虑问题之一。怎么变，按什么变？变化后怎么全盘控制。

4)      第四个问题：阶段目标定义过粗；

实际这个问题一直都存在包括在第一个定义的版本中。通过对PMP2008版本的深入学习和公司组织内部培训。这个问题得到很好的答复，首先阶段目标与活动定义一样都需要一个渐进明细的过程。不是项目一开始，就能将其厘清的。很多项目，特别是公司的自研产品或者需求不确定的电信产品，更多时候是被迫是走这个过程的。问题的关键在两方面，首先是国内的用户普片技术程度不高，不能提供精细化需求描述，想法不清楚；第二点，是我们能控制的部分，但是往往又控制不好的部分，即质量标准。项目范围边界在哪里？怎么才算达到了质量标准，往往项目前期客户期望太高，市场或项目经理过渡承诺，没有定义明确验收标准。后期客户的想法越来越多，最终导致项目无法验收或超出成本预算。

针对以上4个问题，10月份我们对测试计划（现更名为:测试管理计划）进行了较大的调整。这次调整，首先是在思维模式上的一次很大变革。过去的两个计划，我们更多的是强调计划本身因数以及指导思路。而第三版计划我们希望能达以下效果：

1)      整体管理：是要考虑PMP九大知识领域的内容。如何从需求入手通过有效的变更控制，达到适机调整目的。第三版的测试管理计划将着重强调管理、监控和梳理三个方面，并在整个测试活动中扮演重要角色。

2)      回溯管理：回溯的诉求来源于项目结束的定义标准。第二版计划更多强调的是对于过程指导和认知。由此，就产生了一个问题。当项目收尾时，如何来界定项目是否达到预期目标呢？所以第三轮计划需要强调测试结束的时机和方式，是因为哪些事做了，哪些事没做，为什么没做？应该有一个清单，来记录我们做了哪些事，哪些是做完结果怎么样，哪些事没做完但不影响项目发布。

3)      需求管理：从原始需求入手从源头上建立一个跟踪模型，这个模型既能跟踪到与需求交互的项目人员，也能跟踪到由它延展出来的项目需求、测试需求、测试特性以及测试用例；

4)      范围管理：首要解决问题的是哪些测试，哪些不测试，哪些测试是需要一定的准入条件；其次，哪些是原始需求中有，基线需求中没明确，什么时机加入到测试范围中来的，我们怎么样做计划调整；

5)      变更机制：变更控制机制这是以前的计划都没有的内容。但这个机制很必要，首先这个版本的计划的核心是变。全程围绕需求而展开，思路是把输入源控制住了在考虑对数据源的定义和约束，从而达到过程可以衡量的效果。变更机制主要控制这样几块，变更的内容和变更范围(记录)、变更的影响(评估)、变更类型(归类)、变更的审批(批准)、变更的时间(监控)以及变更的状态(发布)。

所以第三版的计划是这样的：

项目制度：http://hi.csdn.net/attachment/200911/6/7120_125748887507kK.jpg

项目剪裁：http://hi.csdn.net/attachment/200911/6/7120_1257488876BDF5.jpg

原始需求及需求分解管理：http://hi.csdn.net/attachment/200911/6/7120_1257488877JL1t.jpg

项目整体变更管理：http://hi.csdn.net/attachment/200911/6/7120_1257489349cbU5.jpg

测试范围：http://hi.csdn.net/attachment/200911/6/7120_1257488880B9O2.jpg

里程碑和时间管理：http://hi.csdn.net/attachment/200911/6/7120_1257488915eo4Z.jpg

质量和人力资源管理：http://hi.csdn.net/attachment/200911/6/7120_1257488894gAK6.jpg

由于时间关系，这里没有将第三版计划细节部分进行解释待下回分解。