如何为一组任务确定计划，估计每个任务所需的时间？

前言

以前的文章，虽然现在来看无论从内容还是文笔，都颇多稚嫩之处，但对于测试经验较浅者，仍有可取之处。

在工作过程中，我们常常面临多个项目或者多项任务的情况，若不把任务梳理清楚，或者不把时间进行科学合理的评估，很容易造成时间不够用、测试不充分、质量不过关、进而领导不认可、自己辛辛苦苦不但得不到回报反而被黑锅压身的后果。

　　该如何评估计划时间呢？常规的做法有：

• 每个测试员的工作都有大量的任务构成，所以就需要制定测试任务清单，此为第一步。
• 有些任务只需进行一般描述，有些任务可以分解的相当细。根据自己所能，对需要一天以上时间完成的任务单独列出一项。
• 估计每个任务会占用的时间，然后累加起来，再加上25%（根据公司具体情况，可多可少）的会议、培训和其他非项目工作，并以此估计所需的总时间。

　　上面说的几点人人皆知，但知易行难。比如说，列出任务清单就是一件简单的事，因为很容易遗漏或者低估测试范围（这就引申出一个问题，任务所需的时间应该由谁出？）。

　　说说我的思路：

• 类比法：如果做过类似的项目，可以类比以前的经验估计此次任务的时间；
• 利用模型估算：如果了解项目的长度或者复杂度，并且了解以当前公司将程度长度和复杂度与测试时间关联起来的数据为基础的模型，则可以使用这种模型进行估算。
• 考虑风险：考虑这个项目的风险，然后列出针对风险应该做些什么（时间和任务）
• 其他因素：如对这个任务的了解程度，比如这个任务的开发人员的技术水平和严谨程度，比如程序员对这个应用程序的擅长程度。 还比如这个程序员这段时间状态不好，犯错较多，也需要更多测试。如果编写了测试文档，也可以使测试工作进行的更快。另外有的测试任务还需要根据批量来确定测试周期。

note：使用类似的方法，测试经理可以估算出项目进展中任何时刻的测试员人数，越到项目后期（掌握的信息越多），估计也就更准确。

问题：测试计划按照2轮进行估算时间，这样做有什么利弊？

很多项目经理要求项目做两到三轮测试。他们认为，第一轮会暴漏所有问题，第二轮和第三轮检查所有错误修改。换句话说，这就好比一厢情愿的认为应用程序不会有需求变更，所有缺陷会一次性改好，并且其他关联功能也会运行的很好！ ——实际上，我们都知道产品不得不进行的次数比两轮多得多。

· 随着产品了解的逐步深入，我们会考虑到新的更好的测试，也会找出新问题。 如果只做两轮安排，前面说的这种情况就会被抑制。

即使在第一轮发现了所有问题，那么在修改缺陷后不引入新问题的几率微乎其微。

况且，很多时候测试用例在第一轮并不能执行，很多缺陷会阻断测试的执行。

其实我更想表达的是，计划变更并不可怕也无法阻止，可怕的是很多公司和团队会把变更看做一种失败和拖延。

还有一个情况就是，应该由谁来定测试任务所需的时间，关于这一点我也说说自己的看法。

作为测试经理，我经常会用自己完成某项任务的时间来要求组员，不过我不得不承认，好几次我都低估了安排给其他人的任务。我的做法是如果我的评估和测试员自己的评估存在冲突时，特别是他们的评估时间长得多时，先听听他们对测试任务和测试范围的看法，弄清楚什么原因导致他们给出的时间看起来那么长。——这是一个很不错的可以帮助测试员成长的机会。

　　有时候我不得不修正自己的估计，重新定义测试任务。

　　需要注意的是不要强迫测试员接受自己的看法，大家都不是傻子，这样做会让自己失去权威，而且任务就那么多，实际需要的时间基本是固定的。强迫测试员接受自己的计划很难得到一个好结果。

　　当然我致力于花费更多的时间放在测试计划上，而不是让测试任务承担人给出测试时间，是因为我们部门里面存在很多“有特色”的人，员工意识严重，一个2小时可以完成的任务，他们能给你估算2天。

　　在我上一家公司，我的做法是让承担工作的人告诉我时间。把人带出来以后，自己很轻松。

　　总而言之，做出估计的人选应该是最注意花费多长时间的人，有时候这个人是经理，有时候可以是测试负责人，有时候谁也不是。这取决于谁掌握的信息更多，也取决于估算出现问题时谁来承担责任。——但是无论哪种情况，都不要用“希望”来进行估计。