关于时间评估,有很多非常专业的评估方法 & 评估公式
实际执行的情况是:没有那么多时间给你去估算(也许,从接到项目到上线,总共只有两天时间;你期望用1天时间去估算测试需要多长时间,明显不现实)。而且,不同的项目、不同的团队、不同的质量要求、不同需求的紧急度,需要的测试时间,完全不同 。
在需求都不完全清楚的情况下,怎么估算测试时间呢 ?
简单粗暴的评估方法:「三分之一」大法 。
根据开发评估的整体时间,除以3 ,得到测试总时间 。再结合经验 ,适当加减20%时间即可 。
如果需要把每个模块的时间,细分呢 ?还是保持如上的原则:总时间不变,等比拆分,得到每个模块的时间 。
四点建议
-
测试估算的时间,只需考虑测试的执行时间。如果中途,由于开发延期提测,或者开发修改Bug时间过长,等待新版本测试。在时间评估的时候,需考虑这个时间,把此块时间加上(或者,发版时间,顺延) 。
-
自己估算的时间,如果后续发现时间不够,自己加班,想办法消化 。另外,版本结束后,吸取经验,总结下,是哪个点消耗时间过多,是否可加速(自己总结的经验,终身受益) 。如果确实不可加速,说明整个团队的效能,是低于「三分之一」评估大法的,下次估算,在之前评估时间的基础上,再加上20%的时间 。
-
项目过程中,不接受临时新增需求的测试,如果有临时需求,需要增加对应的测试时间(这块,理论上是这样,实际情况是,很多同学,经常被强塞任务,时间却没有增加)。
-
现实情况是,估算好的测试时间,已确定的上线时间,往往由于一些外部因素,提前上线,这个时候,测试同学,需列出已知风险,并做好本职工作,避免背锅 。
文章转载自公众号为 IDO老徐 简尚 文章: “测试时间估算”的现状 及 4点建议 文章地址: https://mp.weixin.qq.com/s/wGnWcSUhhWIvThgOd1-j2A