前言
面试过几个应聘测试主管的应聘者，问到一个问题“你会如何接手一个新测试项目，你首先会做什么事，问哪些问题？”得到的答案几乎千篇一律：了解需求，做计划，然后设计用例，执行用例，最后提交报告……这样的答案，不能说错，但却不是我想听的。我想听到一些不一样的东西，准确的说是应聘者自己总结和思考过的东西，而不是网上流行的固定的那一套流程。
今天分享的主题是如何管理一个测试项目，跟上面的话题没有直接关系，不过也有借鉴价值。
管理一个测试项目大致可以分为事前、事中、事后三个阶段，从接到测试通知到完成测试计划为事前，从完成测试计划到完成测试报告为事中，完成测试报告往后是事后。今天主讲事前和事中，内容主要是各阶段工作的重点，需要做的准备（需了解的信息），常见的问题等。
事前
接手一个新测试项目以后，我首先会用一段时间来了解团队（这点很重要），学习产品架构，了解团队最新动态。我认为如果没有获取到足够的信息，做出的测试计划是没有信服力的。所以接手一个新的测试项目，首先要做的是先倾听而不是发表意见。
开发模型对测试工作的影响
现在比较流行的开发模式有瀑布模型和敏捷开发（迭代、进化、极限编程等），做测试计划的时候，开发模式在考虑因素中位于T1序列。
关于不同模式的优劣，争论一直没有停止过，本文不做讨论。模型的选择是立足于公司/团队所面临的问题，而且两者也并非不能交叉。这里需要提醒的是，如果选择了瀑布模型开发，《测试计划》中也不建议对时间进行精细的划分，“需求不会变更”只是一种美好的期望。每次需求变更，计划都需要进行随之改变——这个投入是没必要的——建议将时间投入在了解团队和项目信息中、规划测试策略上。
同理，在代码交付之前编写详细的测试用例也是有风险的。从实际工作来看，我们前期写得很多用例，到后来对应的功能甚至没有开发，或者开发出来的跟设计不一样，这也意味着我们前期花费了大量的时间和精力做了一堆无用功，而且用例写得越详细，测试数据准备的越“充分”，情况就越糟。但用例不能不写，因为抛开用例对我们测试人员的重要性不谈，开发有时候也需要根据我们的用例做自测，所以怎么写、写到什么程度合适呢？我的建议是可以写测试要点（试试mindmanager和visio），以后会详谈。
需要开发提供的文档
很多测试新手都有过这样的困扰：开发连一个完整详细的需求/规格书都没有，要不要给他们测试？
很多时候要不要投入测试不是我们能决定的，领导让你测，你敢说他们文档不提供你就不测？ 我想说的是，并非所有公司、团队或者项目都需要提供文档，如果是互联网公司、或者选择敏捷开发，文档是弱化的。其次，如果因为没有一个详细文档，我们就不能高质量的测试，那岂不是说明我们能力也有问题嘛？除了文档，我们可以通过其他信息来保证我们的测试质量。
另外，除非我们确实需要，否则不要让开发提供文档。
在项目初期的投入
测试越早介入项目越有利于保证产品质量，这个观点目前基本已成为共识。不过在执行层面上还会有问题。比如如果只是想让测试员参加早期的项目团队会议，那也许是浪费测试员的时间。在比如如果测试员不懂代码，派他去参加技术/代码评审常常是浪费时间，而且如果问出一些“小白问题”，自己尴尬不说，还可能导致被开发瞧不起。
那我们应该参加哪些会议呢？或者我们参加会议的时候应该关注些什么呢？
我觉得值得参加的活动举有：
-
评审文档的可测试性、可理解性和模糊性
-
考虑测试策略，是否需要学习必要的工具，是否需要进行质量度量
-
对团队进行培训，Bug预防
-
推动代码评审（自身需要接受培训）
-
拟定测试环境的配置清单
-
了解产品的客户、市场和竞争情况
沟通版本发布计划。避免过于频繁的版本发布，否则会在测试管理上面花费过多的时间，而且每个版本无法“充分”测试，难以保证质量。
关于《测试计划》
做多少轮测试才算充分？
我们都希望有某种方式保证已经完成了足够的测试，网上也能查到很多公式。但实际上我觉得这些公式都有很明显的严重的问题。也有一种说法“两（三）轮测试性价比最高”，这种方法理想的认为第一轮会发现所有bug，第二轮回归所有bug……但实际情况我们大都知道，这不可行，因为我们对产品的了解是随着测试逐步深入的，越往后测可能会想到更多更好的测试方式，也会发现以前没有考虑到的地方。除此之外，需求变更、BUG阻塞、引入新BUG等都会让测试轮数不止两三轮。
当初制定的计划测试时间总是无法按期进行，写测试计划还有意义吗？
《测试计划》中时间是其中一环，但不是最重要的一环。测试计划的编写有5W1H的指导原则，关于这方面网上很多资料。我现在的团队，项目进度控制的也不好，我的做法是在代码交付以后做“阶段计划”：制定一个阶段测试的目标，比如要使用什么工具、战术，要寻找什么类型的BUG，有什么风险，要研究什么资料，需要什么结果等。有了阶段目标之后，再制定阶段测试时间，可能是一小时，也可能是几天。在有条件时会安排几个人共同完成这个阶段任务，从效果来看，这种做法更有实际意义。
测试任务时间估算，请参考我的另一篇文章：测试管理分享-《如何为一组任务确定计划，估计每个任务所需的时间？》
未完待续。
欢迎关注我的公众号来交流：