如何评估测试工时？

看到这样一个问题：如何在保障质量和平衡资源分配的情况下，在项目迭代中评估测试所需投入的时间？评估时间是否需要包含开发修复 bug 的时间？很经典的一个项目管理和软件工程问题。

如问题所描述，要保障质量和平衡资源，这正好切中了软件工程角度的影响质量三要素，即范围、成本、时间。

从软件工程的角度来说，其目的是为了构建和维护高质量的软件，质量是核心内容。为了保障质量，需要明确范围、投入足够的成本和时间，当然这只是理想状态。实际来说，三者最多只能取其二。

从项目管理的角度来说，进度和成本是最核心的问题，管理者都希望在尽可能投入较少资源的情况下，尽快的交付以便于收回应收账款(或者业务运营带来的收益)。

这个时候矛盾的点就出现了：交付需要满足上线要求，否则出问题修复的成本会很高。在范围和成本不变的情况下，尽快交付会导致质量下降。但要保障质量势必要投入足够的资源，这又触碰到了管理者最敏感的成本问题。

如何解决本文开头提出的问题？下面是我的一些思路和实践经验。

首先分享一个概念：需求池。

所谓需求池，即一个承载需求的“容器”。将收集到或者需要在后续迭代的需求进行简单初筛后，按照一定的规范(模块、类型、优先级)进行汇总录入其中。

需求池的管理工具有很多，比如 Excel、飞书文档、MindManager 或者其他项目管理工具。

为什么要建立需求池呢，有如下三点好处：

• 对需求进行记录，避免混淆不清或丢失。

• 有助于建立清晰的版本迭代计划，从宏观角度把控项目进度。

• 提前识别项目和需求潜在的风险，借此评估所需投入的时间人力资源。

建立需求池以后，后续所有迭代的需求都从其中进行筛取，按照下一版本的可用资源(研发/测试可用人日)、需求实现难易程度(成本)来确定该次迭代的需求数量。

其次，从项目管理的角度出发，按照版本迭代频次(比如一周一版本或两周一版本)可以将一次迭代划分为四个阶段：需求-研发-测试-交付。

其中，技术同学只需要关注中间两个阶段，即研发和测试。毕竟在每次迭代中，真正耗费工时的就这两个阶段。

按照我之前负责项目管理和质量保障时的经验，研发和测试的投入时间占比大抵可以按照如下几个比例划分：

• 从零开始项目：研发测试资源投入比 3:1——5:1。

• 正常迭代项目：研发测试资源投入比 5:1——7:1。

• 基础技术设施项目：研发测试资源投入比 7:1——10:1。

其中，所谓的从零开始项目就是全新的项目，包括需求、架构等都需要重新设计，因此需要投入大量的资源。而正常迭代项目中，参与人员对需求、系统架构等方面都较为熟悉，可以适当的减少一些人力资源投入。

至于基础技术设施项目，比如基础架构团队为业务团队提供各种技术工具(MQ、监控、服务注册发现)，则可以投入较少的测试资源。一方面原因是基础技术设施现在各种工具框架更为成熟稳定，开箱即用；另一方面的原因则是基础架构团队的人员配置能力更好，质量可以靠技术同学自身的专业能力和职业素养来保障。

总结一下，评估研发/测试工时(资源)投入有两个思路：1-根据人力资源定需求数量；2-根据需求数量定人力资源。

即在影响质量三要素中，我们将版本迭代(时间因素)锚定，然后平衡需求的范围和所需投入资源。当然，交付质量需要在项目开始之前有明确可量化的指标，还要考虑团队技术同学自身的能力，以及需求的质量。