如何管理测试项目？

前言

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

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

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

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

事前

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    做多少轮测试才算充分？

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

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

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

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