如何管理测试项目？

前言

    面试过几个应聘测试主管的应聘者，问到一个问题“你会如何接手一个新测试项目，你首先会做什么事，问哪些问题？”

    得到的答案几乎千篇一律：了解需求，做计划，然后设计用例，执行用例，最后提交报告……这样的答案，不能说错，但却不是我想听的。我希望听到一些不一样的东西，准确的说是应聘者自己总结和思考过的东西。

    今天分享的主题是如何管理一个测试项目，对回答这个问题有借鉴意义。

    管理一个测试项目大致可以分为事前、事中、事后三个阶段，从接到测试通知到完成测试计划为事前，从完成测试计划到完成测试报告为事中，完成测试报告往后是事后。今天主讲事前和事中，内容主要是各阶段工作的重点，需要做的准备（需了解的信息），常见的问题等。

事前

    接手一个新测试项目以后，我首先会用一段时间来了解团队（这点很重要），学习产品架构，了解团队最新动态。我认为如果没有获取到足够的信息，做出的测试计划是没有信服力的。所以接手一个新的测试项目，首先要做的是先倾听、深入了解情况而不是发表意见。

    有的员工很喜欢说“在我们以前的单位是怎么怎么做的....”，这是很忌讳的。会让听众觉得，你还没有融入到现在的团队，做事不考虑实情。

开发模型对测试工作的影响

    现在比较流行的开发模式有瀑布模型和敏捷开发（迭代、进化、极限编程等），做测试计划的时候，开发模式在考虑因素中位于T1序列。

    关于不同模式的优劣，争论一直没有停止过，本文不做讨论。模型的选择是立足于公司/团队所面临的问题，而且两者也并非不能交叉。这里需要提醒的是，如果选择了瀑布模型开发，《测试计划》中也不建议对时间进行精细的划分，“需求不会变更”只是一种美好的期望。每次需求变更，计划都需要进行随之改变——这个投入是没必要的——建议将时间投入在了解团队和项目信息中、规划测试策略上。

    同理，在代码交付之前编写详细的测试用例也是有风险的。从实际工作来看，我们前期写得很多用例，到后来对应的功能甚至没有开发，或者开发出来的跟设计不一样，这也意味着我们前期花费了大量的时间和精力做了一堆无用功，而且用例写得越详细，测试数据准备的越“充分”，情况就越糟。但用例不能不写，因为抛开用例对我们测试人员的重要性不谈，开发有时候也需要根据我们的用例做自测，所以怎么写、写到什么程度合适呢？我的建议是可以写测试要点（试试mindmanager和visio），以后会详谈。

需要开发提供哪些文档？

    很多测试新手都有过这样的困扰：开发连一个完整详细的需求/规格书都没有，要不要给他们测试？

    很多时候要不要投入测试不是我们能决定的，安排了测试任务，我们若因为一点困难就推掉，这是说不过去的，不是吗？

    现实情况是，并非所有公司、团队或者项目都需要提供文档，如果是互联网公司、或者选择敏捷开发，很多文档是弱化的。其次，如果因为没有一个详细文档，我们就不能高质量的测试，那岂不是说明我们能力也有问题嘛？除了文档，我们可以通过其他信息来保证我们的测试质量，比如沟通，竞品，行业资讯，业务知识等。

在项目初期的投入

    测试越早介入项目越有利于保证产品质量，这个观点目前基本已成为共识。不过在执行层面上还会有问题。比如如果只是想让测试员参加早期的项目团队会议，那也许只是在浪费测试员的时间。再比如如果测试员不懂代码，派他去参加技术/代码评审常常是浪费时间，而且如果问出一些“小白问题”，自己尴尬不说，还可能导致被开发瞧不起。

    那我们应该参加哪些会议呢？或者我们参加会议的时候应该关注些什么呢？

    我觉得值得参加的活动举有：

• 评审文档的可测试性、可理解性和模糊性

• 考虑测试策略，是否需要学习必要的工具，是否需要进行质量度量

• 对团队进行培训，Bug预防

• 推动代码评审（自身需要接受培训）

• 拟定测试环境的配置清单

• 了解产品的客户、市场和竞争情况

沟通版本发布计划

    避免过于频繁的版本发布，否则会在测试管理上面花费过多的时间，而且每个版本无法“充分”测试，难以保证质量。

关于《测试计划》

    做多少轮测试才算充分？

    我们都希望有某种方式保证已经完成了足够的测试，网上也能查到很多公式。但实际上我觉得这些公式都有很明显的严重的问题。也有一种说法“三轮测试性价比最高”，这种方法理想的认为第一轮会发现所有bug，第二轮回归所有bug……但实际情况我们大都知道，这不可行，因为我们对产品的了解是随着测试逐步深入的，越往后测可能会想到更多更好的测试方式，也会发现以前没有考虑到的地方。除此之外，需求变更、BUG阻塞、引入新BUG等都会让测试轮数不止两三轮。

    计划测试时间总是变，写测试计划还有意义吗？

    《测试计划》中时间是其中一环，但不是最重要的一环。测试计划的编写有5W1H的指导原则，关于这方面网上很多资料。我现在的团队，项目进度控制的也不好，我的做法是在代码交付以后做“阶段计划”：制定一个阶段测试的目标，比如要使用什么工具、战术，要寻找什么类型的BUG，有什么风险，要研究什么资料，需要什么结果等。有了阶段目标之后，再制定阶段测试时间，可能是一小时，也可能是几天。在有条件时会安排几个人共同完成这个阶段任务，从效果来看，这种做法更有实际意义。

    测试任务时间估算，请参考我的另一篇文章：测试管理分享-《如何为一组任务确定计划，估计每个任务所需的时间？》