最近新接手一个项目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、合理估期。
对于新项目的测试估期，除了考虑项目本身的测试时间外，还要考虑外部因素，例如团队磨合，外部项目插入等等。
每个版本复盘下，挺好~
ps：我是lc馨馨紫，全网名称统一，期待优秀的你关注我~
原创文章，转载请注明出处~
网友评论