对,还是项目复盘

上一篇 / 下一篇  2021-12-15 15:57:16

本周,给大家分享的还是项目复盘,本次是项目V2.4版本的复盘。

项目背景:该项目是一个Web类型项目,分为前台和后台。本期主要是数据报告相关的功能,其实逻辑很简单,验证从数据库表到页面的展示逻辑,主要是根据多个字段进行分组求和,验证数据展示正确即可。

本次涉及6个页面,后台的3个页面,每个页面有18个字段,前台3个页面,每个页面大概5个字段。

人员和工期安排:1.5个后端人员,1个前端人员,1个测试人员,1个产品人员,开发3个工作日,测试4个工作日,产生Bug共计45个,质量有点堪忧。

从项目负责人的角度来分析下:

一、测试工期偏长

理论上,大多数情况下,测试时间是开发时间的1/3即可,从这个项目来看,逻辑也不复杂,唯一费时的可能就是造数据和核对字段花费点时间。

但是实际情况并不是这样,测试同学几乎一直在提Bug,验证Bug,激活Bug。这里在项目复盘的时候,测试人员需要提出来,时间到底花在哪里了。

否则,项目管理人以为质量还行,测试同学多估了时间,再说,抛出问题之后,项目管理人也可以有针对性的解决问题,让团队处于一个比较良性的循环状态。

二、质量惨不忍睹

没有复杂逻辑,主要的功能就是列表展示,查询,汇总和下载数据。6个页面,可以产出45个Bug,而且重新激活的Bug多达5个,Bugfix引入的也有5个,这个质量,可以说是比较差的了。

分析了下Bug,主要集中在字段显示不全,字段取值错误,下载数据错误,搜索结果错误,分页问题,小数点位数处理问题,默认字段展示错误,字段显示顺序与原型不一致,缺少搜索和排序功能等等。

上面是Bug数量的问题,其次,关于Bug修复质量的问题也不乐观,重新激活和Bugfix引入的数量,可以间接考察开发同学修复Bug的质量,小tips:很多公司将这两个指标纳入开发同学的KPI考核指标中。

思考了下里面的原因:

1、每个页面长的很像,而且字段太多了,开发同学改代码出错在所难免

中间出现过一个很懵的现象,就是第一版显示表头的字段正确,但是值不正确,第二版值和字段都正确了,第三版改其他页面,把这个页面的所有字段全改了,表头字段和值全不对,结果推翻再来,重新再修复一遍。

2、提测确实有点草率

本次迭代,没有进行冒烟演示就直接开始测试了,结果就是,随便一点就是Bug,下期得反馈下,冒烟流程还是得走,而且还得走的细一点,否则走了也就是个形式,提升质量的目的还是没有达到。

这个小版本就说这么多了,期待下一次版本的新风貌~


TAG:

 

评分:0

我来说两句

lc馨馨紫

lc馨馨紫

公众号「lcxinxinzi」,测试工程师|待过大厂|带过创业团队,爱给开发提Bug的测试妹纸一枚,面试资料和大厂内推+V:Icxinxinzi01

日历

« 2024-03-21  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 9684
  • 日志数: 26
  • 建立时间: 2021-10-29
  • 更新时间: 2023-08-02

RSS订阅

Open Toolbar