今天想聊一聊关于测试工作量评估及需求进度把控的内容。
我个人觉得有时候评估测试工作量其实也挺难的，比如有的需求没有需求文档，只能靠自己对需求的理解去大概评估，有可能评估的工作量比实际需要的工作量会少点，对于每周进行迭代的项目来讲，差出来的这点时间可能就会导致项目不能如期上线的风险。
我最近就亲身经历了评估测试工作量不够合理导致差点出现上线风险的案例，好在是及时在早会的时候和整个团队包括产品、项目经理抛出了风险，然后和开发同学协同，通过连续加班的方式按照原计划完成了所有需求内容的测试，虽然最后没有真的引发上线的风险，但是不得不说，连续的加班去赶进度真的很头疼。
这让我意识到工作量评估和需求进度把控的重要性。经过这次案例，我们团队内部也进行复盘了，导致发布风险点的原因主要有以下两点：
1.测试在评估工作量的时候没有按照每日正常的工作时长去评估的，而是把加班时间考虑进去了，本来按照正常来讲，测试完这个需求5人日，但是实际只评估了3人日（算上加班时间），而且没有预留一些时间去应对随时的变化，这导致测试在提测后就得加班加点的去执行测试，无疑是给自己增加了负荷。
2. 开发同学在评估工作量的时候，没有对需求内容仔细研究，只是看了需求文档表面的描述去评估的开发所需的工时，结果开发过程中发现对本次需求内容不熟悉，导致不得不延期了提测时间，并且由于开发刚开始没有对需求内容深入的了解，导致提测后的质量不高，也直接影响到了测试正常的测试进度。
不过当时还好距离发布日期还有2天时间，经过项目内沟通后，希望还是尽量保证需求如期发布上线，最后开发和测试同学通过连续加班才把工作内容完成了。
当然，我们项目组内也不是说经常出现这种情况，这次之所以出现这个问题我觉得最大原因还是相关方在评估工作量的不够认真仔细，没有预留足够的缓冲时间。
我们这次的需求是提供了需求文档的，如果认真看一遍就会知道自己评估的工作量是有点太乐观了。但是有的时候，一些需求并不会提供详细的需求文档，甚至没有需求文档，这就增加了相关方评估工作量的一个难度。
比如我们还有一个正在开发中的需求，产品的诉求就是优化当前平台开发流程，提升产品交付速度，开发要做的就是重新开发一些组件用以替换当前项目中的一些老组件，以及通过一些界面可视化配置来代替之前的编码工作，这个没块是有需求文档的，完全依赖于开发的技术方案，我们测试也只能通过和开发了解具体的内容，最直观的可能就是开发同学完成需求所需要的人日，然后我们测试据此参照进行评估。
通过以上说的实际工作中遇到的情况，我总结了以下关于需求工作量评估的一些注意点：
1、在评估工作量的时候，要按照正常每日工作时长去评估，除此之外，还得预留一点时间以应对可能出现的未预料的情况，比如开发延期、需求临时变更或者中途处理优先级更高的事情等。
2、测试在评估完工作量后需要与开发同学对接一下，保证测试和开发的时间在整个迭代周期内是可以安全、充足衔接的，毕竟开发是在测试的上游，如果一旦出现开发延期提测的情况，势必会影响测试的进度。
3、遇到没有需求文档或者需求文档不够详细的需求，评估工作量会比较难，因为没有具体的内容参照，这个时候测试可以花时间与开发同学仔细了解一下内容，比如如何实现的，有哪些特别需要注意的点，都可以增加我们对需求的了解，然后，测试可以把了解后的需求内容按照模块去编写测试策略，比如A模块涉及哪些功能，预估测试用例xx条，B模块涉及哪些功能，预估测试用例xx条等等，这样整体的需求内容就被我们拆解了，而且我们有了预估的用例条数，需求工作量就变得具体些了，这个时候我们再按照正常每日执行用例多少就可以评估出执行完所有用例所需要的人日，即使这不能很精确，但是相比光凭着自己脑子理解的需求去评估工作量还是更加有效的。
除了提升工作量评估的质量，其实还有一点很重要，就是测试同学需要具备把握需求整体进度风险的能力。比如在测试在看需求的时候，如果觉得这个需求比较复杂或者会有些易踩的“坑”，可以提前和开发同学沟通，他们也许会重新评估自己的工作量。在实际工作中，像开发延期提测、需求变更或者其他因素导致影响测试进度的情况是不可能完全避免的，这要求测试同学在工作中要具备适应万变的能力，当真的出现这种情况的时候，我们可以这么做：
1、重新及时评估工作量，确认对测试进度的影响范围，在项目组内及时抛出风险。
2、适实调整计划，尽量争取他人的支持，合理协调资源。比如某些需求是可以拆解分步开发和提测的，那么我们可以和开发商量，看能否分步提测这个需求以便可以挽回一点测试时间；可以在项目内或者项目外争取到其他测试同学的支持;可以通过项目和产品沟通，看能否调整优先级，先去覆盖优先级高的需求等等。
项目能否如期保质保量的交付依赖于项目组内各个职能互相的支持与配合，测试作为项目推进的过程中的一份子，我觉得应有测试“左移”的思想，并在实际工作中去践行，把测试工作“走在前面”。测试同学需要具备整体把控需求进度风险的能力，在项目的开发与交付中发挥应有的作用。如果能够让大家形成一种共识：我们的测试是安全可靠的，是值得的信赖的，那我觉得这就是我们测试同学所存在的意义，也是对我们工作的褒奖。
祝愿大家都能不断进步，努力成为一名优秀的QA，与大家共勉！
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
