急急忙忙,恍恍惚惚,项目C的2.2版本上线了,又是一次神级别的迭代。
简单介绍下,该项目C是一个Web项目,分为前后台,前台供外部用户使用,后台供公司内部人员使用。
相比于上次的项目,此次的变化如下:
1、人员
2、版本功能
这次迭代比上次2.0版本的功能多了一倍,但是排期反而被压缩。
测试过程中,产品同学不断催进度,一再强调为了冲刺年底的KPI,本次迭代只需保证主体功能没问题,就算测试ok了。
于是测试同学直接提前两天,发完了测试报告,恍恍惚惚的上线了。
这个版本明显的感觉就是时间特别紧,特别赶,但是也有很多复盘的地方,下面来趁热分析下,为后续的迭代留下些许的经验。
一、测试同学做的比较好的地方
一)暴露问题及时
这次迭代是两个同学进行测试,总共六个大模块,一人三个模块,一轮测试进行的很快,问题暴露的也很快。
二)项目功能的优先级把控到位
吸取上次迭代的教训,这次同样有与其他项目F的对接功能,优先测试了依赖于项目F的功能,两边配合很顺利,没有阻塞性的大问题,进展顺利。
二、待改进的地方
此次迭代的后期,产品同学做了一些关于交互的小修改,但是一般在群里通知,没有及时更新原型。
由于群里的消息太多了,有
Bug相关的,有确认需求的,消息刷的特别快,之前没有做统一的记录,后续回归起来非常麻烦,时不时就有漏掉的点,所幸的是,最后凭着记忆和聊天记录,确认都修改完毕了。
后续有需求修改的,会催促产品同学更新原型,同时自己也会做记录,以便于最后的回归测试。
二)非功能性Bug花费了太多的时间
1、字段合法性检测问题
在测试过程中,很多Bug都与字段的合法性相关,比如,没有限制字段的长度,用户填写的字段过长时,会导致页面变形,显示不友好,好多页面都有类似的问题。
还有关于字段能否同名的问题,好多字段原型中没有明确说明,但是与产品同学确认的时候,又需要做去重处理。
2、搜索框下拉选项的问题
很多页面都有某个字段的搜索项,例如接入方式:PC,Web,但是前后台涉及了6个页面,几乎都不一致,有的选项是PC网页版,有的又是PC,产品同学要求统一起来,因此又修改了很多地方。
3、功能体验相关的问题
本次迭代有个上传功能,但是原型上只要求上传成功,没有要求很多功能细节。比如上传过程中是否能取消,上传过程中是否能替换文件,上传过程中刷新页面文件是否会继续上传等等,后来跟产品同学确认,全部都算Bug,需要修复。
这些非功能性的Bug,后续在做需求评审的时候,会主动提出来,秉承「测试左移」的思想,让Bug在源头就被消灭。
三)与其他测试同学的配合
该项目是由我主测,另外一个测试同学辅测,刚好该同学有空,就一起测试了,平时配合的不多,还需要磨合。
在测试过程中,提了多个重复的Bug,后来达成一致:各自提Bug前可以先看下禅道,或者直接群里询问是否有过重复Bug,否则提出来好多重复Bug,既浪费了测试同学提Bug的时间,也浪费了开发同学查看Bug的时间。
四)提测质量需要提升
一个小中型迭代,Bug数共计95个,质量堪忧。
仔细分析了下禅道的Bug:
1、严重等级
严重等级并不高,91%的是3级Bug,不会阻塞整体流程,但是就是小问题很多。
2、Bug解决方案
83%都是已解决,7%的是设计如此,3%的不予解决,总体来说,有效Bug占比还是很高的。
3、Bug激活次数
激活次数为1和2的占比在10%左右,稍微偏高,被重新激活的Bug,开发再次修复,测试再次验证,其实是很影响效率的,而且会影响开发同学的KPI,所以在激活之前,也会很慎重。
4、Bug类型统计
在代码错误和功能缺陷之间没有做很严格的区分,整体来看,这两个比例占了75%,功能优化的占16%,需求变更占1%,大多数都还是需要修复的影响功能的Bug。
在提测前的冒烟演示中,只看了整体流程是否能走通,一些基本的问题都忽略了,后续在冒烟的过程中,会更严格点,争取改善下质量。
五)与开发同学一再确认测试范围
本次迭代中,有个页面,在线上验证时报错了,查原因,才发现,这个页面开发同学换了
数据库表,但是没有通知测试同学,也没有在提测邮件中说明,导致测试过程中没有覆盖到。
后续可以加强团队沟通,在一轮测试完成后,主动找开发同学再次确认,是否有其他模块的修改需要测试。
最后,争取每个迭代来个复盘,不断精进,不断成长,见证项目从0到1的成长过程。