测试基础 跟着高手学复盘_初步理解

伍个一 for 杭州软件测试圈 · 2021年02月20日 · 最后由 陈恒捷 回复于 2021年02月23日 · 715 次阅读

2021 年春节假期之后第一天上班,对年前的项目进行收尾,想主导一次项目复盘,但是主持的复盘效果并不好。于是,就找了极客时间的《跟着高手学复盘》 ,可以落地的方法论。

1. 复盘项目概述

2021 年春节前,接了一个有点难的项目,经历前期接近一个多月的 N 次需求评审,三版才敲定原型,设计评审,中途测试人员调整,后台开源框架引入,新协议 grpc 的全面使用,和后台大佬认知差距过大,以及前端人员不足的情况下,发布了一个内部项目。

由于是内部项目,上线之后用户暂时为 0,从运行半个月的情况来看,主体功能正常,数据暂时没有发现异常,这么来看的话,皆大欢喜,算是一次成功的发版?8 个遗留 BUG,两个功能未实现,一个技术问题,五个没有时间解决的,以及迭代过程中的一些其他的问题。觉得需要主导一次复盘,但是这个项目组的人员都是大佬级别的,复盘效果不好的话担心浪费大伙时间(2020 年主导过几次其他项目的复盘,效果差强人意,多数开成了批斗会),于是就找到了《跟着高手学复盘》。

学习笔记(思维导图),课程内容比较经典,有些就直接复制,自己慢慢消化,今天和大家聊聊看完课程的收获。

2. 复盘的常见问题

2.1 复盘变成了甩锅和背锅

截取了去年某项目复盘的一张 PPT,如下所示:涵盖了测试情况,上线情况,存在不足,还有项目组其他角色暴露出来的一些问题
示例
一场复盘下来,足足开成了批斗会,以至于上一次复盘的时候,产品负责人说他知道问题在哪,在外被项目批斗,在内被领导批斗,不想在项目组内再来一次了。但是,批斗,甩锅,背锅,不是复盘的目的啊

专栏中是这么描述这个问题的:不以追责和惩罚为目的来做复盘,把重点放在对未来的优化上,才可能拥有 “群众基础”,这是复盘的前提。

将心比心,大部分人都不愿意承认自己的失误的,只想在别人身上找原因,真的有没甩过锅的测试?

2.2 不知道怎么得到有价值的复盘结论

我之前主导或参与的复盘,项目结束之后,相关人员聚集相互商议,类似于 “茶话会”,各自阐述在迭代中的得失,哪些做的好?哪些做的不好?

相互批斗之后,然后,商讨出一些问题以及解决方案,例如:遗留 BUG 该怎么管理?测试报告输出方式等指出一些问题,但是这些结论怎么做,落地效果如何,不怎么好。

2.3 复盘结论得不到别人支持

复盘结论得不到别人的支持,复盘结论落地困难,说多了都是泪。

3. 复盘的目的

针对于复盘中的常见问题,在专栏中找到了个人认为的答案。

3.1 对未来的优化

甩锅,背锅这个方式不可取,一次甩锅一时爽,难道还能每次都甩锅?遇到问题,解决问题,不解决的话,会因为这个问题栽更大的跟头(解决不了就抛给能解决的)。

复盘的目的更多是对未来的优化,防止下次迭代同样的问题重复出现,例如 :分页不传参数的 BUG,上次迭代出现了三次位置,不长记性的话,下次迭代出现了四次,这种问题不解决,发现 BUG,提 BUG,接受 BUG,验证 BUG,摆明了是重复工作量嘛,取其精华,去其糟粕

3.2 对认知的修正

这次迭代收获最大的就是改变了我对几个功能点的认知。
先说认知这回事,个人理解迭代是个结果导向性的工作。需求就是那个结果,如果大家对某个需求的结果认知一致的情况下,中间的过程就各自实现就好了,反正结果是一致的,但是事实,不太如人意啊

例如:用户登录的时候用户名是否需要区分大写?

之前的经历告诉我,用户名是需要区分大小写的,这次迭代的需求也没标注这块,个人觉得用户名区分大小写应该是个常识性问题,然后测试过程中发现不区分大小写,提了 BUG 之后,研发说就不区分,就找产品确定,产品被研发说服确认用户名不区分大小写,然后经过两个小时的理论,我也被说服了,用户名不需要区分大小写。

项目迭代过程中,会存在一些隐形需求,就像上面的用户名大小写,单点登录,异常提示等常识性问题,但是就是这种,这些常识性问题,你的常识和我的常识是一样的么?

会出现同一个需求,一千个人一千个哈姆雷特,理解的结果都不一致,实现的功能肯定是不一致的,所以,复盘就是对一部分错误认知的修正 。

4. 复盘的模型

记录了一些复盘模型,太偏向于理论,暂时没什么理解,就不一一赘述了,有大佬的话,欢迎指点下。
各个模型


具体的课程中的复盘操作,落地方案,我也大概梳理了一下,但是贴合项目组太深,包含业务信息,而且没有在项目组实践,等下周在项目组中复盘,观察一下结果之后,再抽象出来分享一下

共收到 4 条回复 时间 点赞

很认同复盘的目的之一是对未来的优化。至于对认知的修正,个人觉得改进下统一认知的机制,遇到分歧能更快速统一认知就好。互联网项目基本需求文档不可能事无巨细,有分歧很正常,能快速统一认知就行。

个人经历,复盘后最大的难点在于如何落地复盘得出的结论,这方面主要有几个原因:

1、这个结论本身比较虚。比如很多时候有些代码里的隐藏问题,会得出一个 “加强代码 review ” 这种结论。但实际这个结论实际操作很难,怎么算加强,多看几次?谁去加强,leader 还是开发自己?连怎么确认是否有落地都难,那落地就更难了。

2、这个结论操作起来不符合人性。比如楼主举的例子 “分页不传参数的 BUG 多次出现” ,有时候产生的结论是 “以后每次分页记得传参数” 。说实话,这类 bug 容易出现,是不是说明这个地方写起来不符合人性所以容易遗漏?那是不是应该改进写法,比如这个传参数内置到分页库里,而不是开发每次手动加?

3、结论具体了,但没有负责人和约定的完成时间,或者就算有也没有人监督。复盘产生的结论很多时候不是业务中的日常事务,更多是额外增加的优化工作,优先级不高。如果没有明确负责人和约定的完成时间,可能项目一忙起来就都忘了。没有监督人在接近完成时间时及时催促提醒,也很容易导致超时甚至不了了之。

至于解决么,前两个主要依赖复盘主持人带节奏,主持人要注意不要得出这两类结论。第三个主要就是靠 leader 或者指定的监督者了,也可以依赖制度,比如周会的时候最近 1 周到期的改进项需要明确同步目前进度。前期大家还没自觉需要多刻意提醒,有了自觉后会逐渐变好。

陈恒捷 回复

大佬工作几年了,感觉你这认知跟技术实力。拍马不及啊

先分类,抓本质,出方案;

liuyang 回复

已经工作 7 年多了。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册