每当我必须估计一个项目的时间(或审查其他人的估计)时,就会在alpha版本和生产版本之间分配测试/错误修复的时间.我非常清楚,对于未知大小的问题集,到目前为止对未来的估计并不是成功估算的好方法.然而,由于各种原因,一定程度的小时数总是在一开始就分配给这部分工作.而这个初始估计距离真实的最终值越远,那些参与调试的人就越需要在他们"超过"估计值时采取的悲伤.
所以我的问题是:你在制定这样的估算时看到的最佳策略是什么？整体开发估计的百分比是平的吗？设定小时数(期望它会上升)？别的什么？
还需要考虑的其他事项:如果客户负责测试(而不是内部质量保证),您将如何回答这种情况,并且您必须分配一定的时间来回应他们可能找到或未找到的错误(因此您需要找出错误修复的时间估计但不测试
这真的取决于很多因素.仅举几例:您正在使用的开发方法,您拥有的测试资源的数量,项目此阶段可用的开发人员数量(许多项目经理将最终将人员转移到新的东西上).
正如Rob Rolnick所说,1:1是一个很好的经验法则 - 但是在规范不好的情况下,客户端可能会推送"错误",这些错误实际上是指定不当的功能.我最近参与了一个使用许多版本的项目,但由于可怕的规范,花在修复bug上的时间比实际开发花费的时间多.
确保良好的规格/设计,并减少测试/错误修复时间,因为测试人员可以更轻松地查看测试内容和测试方法,并且任何客户都可以通过更少的方式来推动额外的功能.
也许我只是编写错误的代码,但我喜欢开发人员和测试之间的比例为1:1.我不等到alpha测试,而是在整个项目中完成.逻辑？根据您的发布计划,开发开始与您的alpha,beta和发货日期之间可能会有很长的时间.此外,越早捕获错误,它们就越容易(并且更便宜)修复.
一个好的测试人员,在每次办理登机手续后很快发现错误,是非常宝贵的.(或者,更好的是,在从PR或DPK办理登机手续之前)简单地说,我仍然非常熟悉我的代码,因此大多数错误修复变得非常简单.通过这种方法,我倾向于将大约15%的开发时间留给bug修复.至少在我做估计的时候.因此,在16周的运行中,我将离开2-3周左右.
从测试圣经:
测试计算机软件
页.31:"测试[...]占产品初始开发的45%." 因此,一个好的经验法则是在初始开发过程中将大约一半的精力分配给测试.
京公网安备 11010802040832号 | 京ICP备19059560号-6 