将测试工作量估算为开发时间的百分比

Mar*_*uys 25 testing estimation

是否有人使用经验法则来估算测试所需的工作量,作为开发所需工作量的百分比?如果是这样,你使用了多少百分比?

小智 14

根据我的经验,25%的努力花在分析上; 50%用于设计,开发和单元测试; 剩余25%用于测试.根据项目的性质,资源知识,投入和产出的质量等,大多数项目将符合此经验法则+/- 10%的差异.可以在这些百分比内添加项目管理费用或作为在10-15%范围内的顶部开销.


Rob*_*anu 11

Google测试博客最近讨论了这个问题:

所以一个天真的答案是写作测试带有10%的税.但是,我们交税是为了获得回报.

(剪断)

这些好处转化为今天和明天的真正价值.我写测试,因为我获得的额外好处远远抵消了10%的额外成本.即使我不包括长期利益,我今天从测试中获得的价值也是值得的.我通过测试开发代码的速度更快.多少,这取决于代码的复杂性.您尝试构建的事物越复杂(更多ifs/loops/dependencies),测试的好处就越大.


小智 8

在估算测试时,您需要确定测试的范围 - 我们是在讨论单元测试,功能,UAT,接口,安全性,性能压力和体积吗?

如果您正在使用瀑布项目,那么您可能会遇到一些相当不变的开销任务.留出时间准备任何计划文件,时间表和报告.

对于功能测试阶段(我是"系统测试人员",这是我的主要参考点),不要忘记包括计划!测试用例通常至少需要从需求/规范/用户故事中提取所需的工作量.此外,您还需要花一些时间进行缺陷提升/重新测试.对于更大的团队,您需要考虑测试管理 - 计划,报告和会议.

一般来说,我的估计是基于所交付特征的复杂性而不是开发努力的百分比.但是,这确实需要访问至少一组高级指令.多年的测试使我能够确定特定复杂性的测试需要花费x小时的时间来准备和执行.某些测试可能需要额外的数据设置工作.某些测试可能涉及与外部系统协商,其持续时间远远超过所需的工作量.

但最后,您需要在整个项目的上下文中进行检查.如果您的估计远高于BA或Development的估计值,则您的基本假设可能存在问题.

我知道这是一个古老的话题,但这是我现在正在重新审视的事情,对项目经理来说是一个长期的兴趣.