项目延期半天的8点感受

原创 lc馨馨紫程序员馨馨

最近新接手一个项目C，跟踪了一个迭代，首次迭代就遇到项目延期，虽然只延期了半天，但是复盘整个过程，还是有很多值得思考和改进的地方。

简述下项目C的背景，项目C是一个Web类项目，分为前台和后台，前台面向用户，后台面向公司内部人员。

本期迭代的参与人员：一个产品同学，一个前端开发同学，一个后端开发同学，一个测试同学。

本次的测试策略：分阶段提测。后台优先提测，测试时间计划为4天，前台后续提测，测试时间计划为4天。

最终结果：延期半天，Bug总计44个。

看起来时间是非常充足的，但是最后还是延期了半天，复盘了整个过程，延期的主要原因如下：

一、测试同学个人原因

1、对项目的整体进度把控不到位

纯粹根据以往的项目经验，过度乐观的评估项目进度和质量，没有考虑到一些外部因素。

2、对项目功能的优先级没有把控好

本项目C有两个功能点是依赖于外部项目F的，没有在前期就介入测试，而是放到最后来进行测试，最后发现这两个功能点的问题比较多，随之耗时就很长了。

时间主要花在与外部项目F的相关同学确认对接方案和测试同学验证功能上了。

外部项目F由于历史架构原因，无法很好的支持该功能，最后经过多次讨论，双方选择了一个折中的临时方案进行解决，中间的沟通成本和时间成本很大。

测试同学由于首次接触该项目C和项目F，中间验证的过程，需要开发的不断支持，中间的时间成本也很大。

要是能优先测试，提前暴露问题，最后就不会在ddl前赶着沟通修改和验证了。

3、造数据过度依赖于开发同学

前台有3个数据报告页面，但是测试环境没有任何数据，需要在测试环境造数据进行测试。

起初，开发同学说帮忙造数据，我就没管，直接等着开发同学造数据了。

最后发现开发同学帮忙造的是最简单的场景，并没有考虑数据的真实性，例如一个用户一天到底产生几条数据，最终到底取和值还是均值等等。

等到我意识这个问题的时候，又耽误了半天。最终，赶紧熟悉了4个数据库的6张表，自己写SQL覆盖了用户可能出现的多个测试场景，发现完整的场景好多问题。

如果自己能不过度依赖开发同学，提前熟悉数据库的各个表，早点造数据，测试时间就可以缩短一点了。

二、外部原因

1、团队磨合

由于是新项目，团队也是首次合作，平时的沟通，Bug流转，需求确认等都需要时间进行磨合，测试估期的时候没有考虑到。

关于修复Bug，本团队的开发同学喜欢批量修改Bug后提交代码，最后导致的结果就是中间会漏掉几个Bug没有修改，但是状态已经标记为已解决，最终测试同学得重新激活，转给开发同学，中间其实是有沟通成本的。

从开发同学来说，批量提代码，可能会更方便些，不用修一个Bug提一次代码，但是从测试同学来说，不太赞同批量提代码的方式，主要有以下两点原因：

（1）批量提代码，容易漏修复某些Bug

比如一次修复10个Bug，中间在修复第6个Bug的时候，开发同学被其他同学打断，后续再接着修复的时候，可能就漏掉了。

（2）批量提代码，不利于测试同学回归Bug

在测试前期，时间相对充足的情况下，影响不大。

但是在测试后期，时间非常紧急，测试同学大多时候都是等着验证Bug的，前期一直在等，突然来了好多个Bug，全部压在一起了，是不利于项目风险控制的。

如果转过来10个Bug，前面7个都是通过的，第8个修复后引进了一个大Bug，项目的最后节点出现大问题，对项目来说风险是很大的。

如果分散点，按照Bug优先级来进行修复，重要Bug早修复，修复后即更新代码，测试同学验证后，有问题早暴露，对整个项目推进是十分有利的。

2、其他项目的穿插

在测试该项目的过程中，插入了另外一个小项目的测试，大概耽误了一天半的时间，中间没有考虑到该问题。

在最后一天的测试中，开发同学参与讨论了下一期的需求以及其他项目的问题，整个下午都在开会，一直无法修复Bug，中间也耽误了半天。

三、经验总结

1、合理把控被测功能的优先级。

与外部系统有交互的功能，优先介入测试，尽早暴露问题。

2、造数据尽量真实。

有需要造数据的模块，不要过度依赖开发同学，测试同学早点造数据，完整的数据更能暴露出问题。

3、合理估期。

对于新项目的测试估期，除了考虑项目本身的测试时间外，还要考虑外部因素，例如团队磨合，外部项目插入等等。

每个版本复盘下，挺好~

参考文章：

大厂面试题之影响测试进度的六大因素

我是lc馨馨紫，『在看』、『点赞』、『转发』、『关注』就是最好的鼓励和认可，期待认识优秀的你~

扫码可添加个人微信

期待认识优秀的你

继续滑动看下一个