敏捷实践 如何和开发更好合作——从一次突如其来质疑说起

阿东 · 2022年08月27日 · 最后由 陈随想 回复于 2022年09月02日 · 12461 次阅读

从一个故事说起 (本故事纯属虚构,供讨论和学习)

人物介绍

  • 阿科 - 一个测试负责人
  • 阿花 - 一个技术 leader

事件经过

在一个非工作内容讨论的会议快结束的时候,不知道为何突阿花然扯到了测试人员的输出,绩效等问题。

  • 阿花:你看我们开发测试比达到了 4:3,这个在行业算是行业高配了,我觉得你们测试效率不行,输出不够,我都不知道你们整天在干嘛
  • 阿科(一脸懵逼):因为项目历史原因,我们 UI 自动化测试覆盖确实不太高,但是最近 UI 自动化其实已经覆盖了大部分回归用例。并且 API 自动化也是一直有的,API 的回归测试结果我是定期在群里发送的,UI 的自动化回归最近也加了一部分了,我让阿西也每天发到群里。
  • 阿花:反正你们团队整体输出不行,你要好好改想办法提高团队效率
  • 阿科:好的,我们想法改进。我这边之前也是花了很多时间去维护 API 测试,包括维护测试数据,更新测试用例,补一些开发没有加的测试用例。
  • 阿花:你不能因为维护了下 API 测试,就把这个输出算到你头上,这是开发做的!
  • 阿科:。。。
  • 阿科:我这边之前一直忙上线流程,包括性能测试那些,其实没有那么多时间参与自动化和功能测试那些
  • 阿花:我不是说你要怎么怎么,你作为 leader 要考虑提高整个团队的效率和输出!
  • 阿科:因为第一阶段测试是陆陆续续进来的,为了赶进度,自动化确实没跟上。你看,这是我正在写的流程文档,我们这边已经制定计划开始改进了
  • 阿花:我不想看这些,我只看到有两个 automation QA 根本就没有 automation 的卡,你要想法让他们开始做一些具体的自动化任务,不能光是学习!
  • 阿科:好的好的。。。
  • 阿花:就这样吧,你多想想吧,你是 leader!你看需不需要专门开个 QA 的 retro meeting 不?
  • 阿科:好的,好的,可以的。

实际情况

因为项目迭代周期快,早期测试资源不足,而且全是新功能,需求经常改,时常出现一张卡做了一半改需求,其实不太适合 UI 自动化。为了保证按时交付,无论是手动还是自动化测试都去做手动了。在早期时候更是如此,只有阿科一个测试,更是加班加点去完成测试任务。

  • 因为没有明确说明 bug 数量是测试 KPI,测试这边提 bug 时候考虑到和开发大部分关系还是比较和谐的,很多时候没有专门建 bug 卡,或者为了提高效率几个 bug 合并到一张卡里面。这导致最后的 bug 统计报表并不能准确体现测试工作量,也不能准确度量软件产品质量。并且很多任务卡因为 bug 和需求改动导致测试多轮(三轮以上),这些数据都没记录和可视化出来。
  • 同时,也没有明确说明自动化用例覆盖率/条数等是测试的 KPI,因此为了能够快速迭代产品,早期 UI 自动化也没跟上。但是 API 自动化测试基本是跟上的,并且到项目第一阶段快结束时候 UI 自动化已经覆盖回归测试了。

基于这两点,阿科在项目开始时候默认为保证产品按时高质量交付是最重要 KPI,这下突然来个灵魂三连问,把阿科整懵逼了。因为平时缺少一些记录,也没有更具体的数据和报表体现测试工作量和输出,这次只能是哑巴吃黄连了。

项目背景

这是一个在现有的一个平台上开发的一个全新业务,技术和架构上没有太大挑战,但是业务逻辑相对比较复杂,细节非常多。研发流程是敏捷开发模式,两周一个迭代,但实际上做了大半年才真正第一次上线,所以其实是一个大的瀑布流中嵌套的敏捷流程。很多业务只有到了后期才能串联起来测试,并且需求变化从头变到尾,也是进一步加大了后期测试的难度。整个项目最大的难点在于满足复杂的不断变化的业务需求。

团队配置

一共两个敏捷团队,每个团队由一个技术负责人 + 两个后端 + 两个前端 + 两个自动化 QA+1 个手动 QA+1 个 BA 构成,除此之外还有一个 scrum master,一共接近 20 人。因为两个团队是做同一个产品,并且产品是一个业务上耦合度比较高的产品,所以两个团队一起做的时候其实不太敏捷,因为需要不停的跨组交流,沟通成本还是挺高的。

交付流程

每个 sprint 完了会给客户 demo,demo 完成之后客户在一个集成环境在做一些验收测试。但是早起参与 demo 的客户很少,临近上线加入更多客户参与 demo,提出了更多不同想法,这也是导致需求变更原因之一。

反思和改进

情绪归情绪,冷静下来反思后,确实有需要改进的地方。
借用原则这本书上的一个公式。

痛苦 + 反思=进步

用客观数据说话

无论什么时候,测试团队应该客观记录下测试人员的工作量和产出数据。因为测试人员角色相比开发,比较边缘化一些,产品没有出问题,那是理所当然的测试指责,一旦出问题,首先被问责的肯定是测试。因此,无论是工作数据还是产品质量度量的数据,平时都应该记录下来,最后能用一个可视化的报表输出最好,并且定期和团队回顾,持续改进。质量和测试工作度量的方法论很多,这里不在展开说,结合这个故事来说, 最起码的测试提出的 bug 应该认真记录,并且应该打上对应的标签方便日后分析。即使没有提 bug 的 KPI,这也是测试日常工作的一个记录和产品质量分析的记录。还有每个功能点测试轮数也需要记录,一个功能如果反复修改还出现 bug 导致迭代周期延长显然不是测试的问题。

进一步提高自动化测试覆盖率

客观的说,对于需求频繁变化的新产品,自动化维护成本太高(特别是 UI 自动化测试),而且很多探索性测试场景难以覆盖。但是如果自动化覆盖太低,又会让项目后期背上很多技术宅。对于一个配置了专职自动化测试的项目来说,如果项目到后期需要短时间迭代上线,而这个时候没有配套的自动化测试用例,肯定会被质疑,并且也会影响产品上线周期。因此,对于新项目如果添加自动化测试,就的具体具体分析了。首先应该参考自动化测试金字塔模型,优先 UT,然后 API,最后才是 UI 自动化。如果一定要做 UI 自动化,从场景说应该优先覆盖稳定的 somke case,从框架层面说,应该根据项目需求搭好底层框架,完成好基本的底层框架后,后面基本就是添加元素定位配置和业务场景的搬砖工作。

划分清楚职责范围

如果不是测试团队的指责范围的工作,如果没有官方要求,没必要默默承担,职场是个用数据和事实说话的地方,默默承担的工作未必能获得所有人认可。

避免情绪化回复质疑

当阿科面对质疑的时候,第一反应是测试团队这么辛苦,为了按时保质让产品上线付出了很多,也默默做了很多工作,因此第一反应回复质疑的时候是有些情绪化的。如果没有具体的一些数据和事实作为支撑,特别是本身就是突如其来的一些质疑时候,避免情绪话回复,这样只会让对方也越来越情绪化,因为对方很可能也是因为情绪上的一些原因提出一些质疑(比如对方也面临外部或者高层压力)。面对这种情况,如果有数据和就用数据客观回复,如果确实是需要改进的问题,下来反思,讨论,总结,继续改进,如果既没有足够的数据,也不是自己团队的问题,那就听着么,谁都难免会有情绪,相互理解下,说完了回去该吃吃,该睡睡,过几天就好了。

补充和更新(九月一号)

文章标题可能给大家造成一些误导,这篇文章目的不是真的要大家和开发或者别的角色搞对立,动不动就上纲上线的,更多的是关于反思和改进,作为不同角色应该怎么更好的合作。

今天过来看看 testerhome,没有想到大家讨论这么热烈(比之前一些技术文章火多了。。。),还有些评论都看不到了。首先特别感谢一些同学给出了很多中肯的建议,但是由于这个故事背景信息给的不够多,导致同学们在一些点可能有些争议,我就再补充一些背景和信息。

项目背景信息补充

  • 这是一个甲方项目,人员配置是按照甲方一个 team 标准配置来的,十几个敏捷团队都是这个配置。4:3 比例确实很高,是因为甲方对 UI 自动化有比较高要求,并且项目刚开始时候不是 4:3,而是 4:1,5:1 这样一个比例,测试是逐渐到位的。
  • 有评论说阿科更多应该是保证团队输出,而不是很多事情亲力亲为。但是阿科在甲方的角色就是一个高级自动化工程师,角色定义也是主要负责 UI 自动化这一块(API 测试在甲方是分到开发侧的,测试主要负责 review),和团队另外几个自动化测试角色一样的,而手动测试更多的承担质量保证角色,并且手动和自动化两个团队在甲方是两条不同汇报线。所以一些具体的技术工作还是要做的。而所谓的测试 leader 只是乙方给的一个角色,希望能够有个角色全局保证产品交付和协调测试资源,阿科也是愿意主动承担这个角色,所以阿科其实比本身的这个角色承担了更多责任。简单说就是既要全局的看产品交付以及和测试团队同步,同时也要完成自己的一些任务,有时候只能靠加班。
  • 接着第二点补充,自动化测试这边是有专门 team leader 的,阿科也定期回去和 leader 做一些同步,也邀请阿花的,但是阿花基本不参加。阿花的角色不是老板,平时也没有明确说明需要给他汇报工作。
  • 因为是甲方项目,阿科一直把乙方的阿花也当成自己人,并且定期团队都会有各种各样内部的回顾和总结会议,通常情况大家都会把问题公开透明提出来讨论并提出改进措施。并且还有每日的站会,所有人也会参加,每个组员也会总结前一天工作和当天工作计划,所以当花突然提出各种质疑时候,阿科会一片懵逼。这也是为什么阿科推测对方当时可能有些情绪化的原因之一。
  • 有评论提到没有看到保护测试团队。第一是当阿花是带有一些情绪化东西质疑时候,这个时候其实不是有理必争的时候,这好比你老婆生气的时候你却要和她讲道理。其实后来阿花私下又提到这个事情,说当时这么说也是更多为了帮助测试改进,没有别的太多意思。第二是前面已经提到的需要改进的事情,就是测试团队平时没有留下足够的数据最为一个支撑。
  • 不是所有开发或者 leader 都质疑测试工作,其实还有阿虎阿轩。。。(包括一些 leader)都是很认同测试工作的,时常提到测试这边检查很细致。这也是前面提到的为什么测试开发关系其实总体比较和谐
  • 因为没有分支发布策略(用的 trunk-based 策略)和发布版本和专门测试环境,也是导致测试难度加大的一个因素。

进一步思考

如果反过来阿科作为开发,应该怎么更好和测试或者别的角色合作呢?

  • 有问题尽早的明确的提出来,没有必要拖延掩盖。
  • 尽量以事实作为依据,针对问题讨论,而不是针对人。
  • 避免情绪化讨论,如果因为自己被老板问责心情不太好,等稍微冷静下来再讨论
  • 重在改进而不是追责。
  • 注意说话方式,比如这个故事这样开头就好多了:我觉得你们测试最近真的挺辛苦的,经常加班加点保证产品交付,我们要不要一起来看看我们整个流程还可以怎么优化?我们开发还可以配合你们做些什么?争取做到大家都 955,你看行不? 如果这样开头,后面恐怕就是另外一个故事了。

再进一步思考

无论在什么公司做什么项目,都会遇到各种各样的问题,可能是技术问题,可能是非技术问题,总之问题是永恒存在的,并且没有办法解决完的,更麻烦的是如果不觉解决,问题还会越来越多。因此我们只能不断发现问题,排出优先级,一个一个解决,保持一个持续改进的状态。
希望和各位 testerhome 同学共勉。

先写到这吧,成都今天静态管理了,希望能早日恢复正常~

共收到 35 条回复 时间 点赞

标题 “永远不要和开发做朋友” ,会不会有点过了?

我记得楼主前段时间有发一篇三十五岁之后找到一家外企工作的帖子。其实楼主的这个经历,和这篇提到的各种敏捷团队,等等,都和我现在的情况非常相似。
我是三年前入职已经广州的外企,然后去年团队原来的老大离职之后,由我接手团队的管理。上面我的每一点,都是和老板,和开发团队沟通之后的感受。在老板的眼里,是真的不会关心你做得有多累,而是看你是不是真的把你的工作做好。这个自上而下也是成立的:你也不会希望你的自动化工程师整天在忙着手工测试,没有自动化产出吧?
所以还是要学会换位思考,把自己从一个尽责的团队万金油测试,转变成为一个管理者的角度和心态。不要想着面面俱到,把什么细节都做好,不到迫不得已,也别把自己陷进去具体某个难点里面去埋头苦干。发掘团队里面合适的人,把你的想法和任务分给他们去帮你完成。如果没有合适的人,说明的也是你需要培养或者招人,把团队的短板补起来。
管理不易,承受来自各方的压力也不易。与君共勉!

支持你,顶,有过相同的

回复内容未通过审核,暂不显示

有点没看明白,怎么突然扯自动化

回复内容未通过审核,暂不显示
hu 回复

戾气这么重逛啥社区,测试不见得要技术多高深才能揪出问题吧?有很多深层测的 bug 也只是在某一次普通的点点中发现的,不爽测试人员技术不够深,招个开发去做测试就能保证质量更好吗

Jerry li 回复

为二楼点赞!

自己以前初次带团队,最难的是心态的转变,从自己大部分事情都亲力亲为,改为多依靠团队内外的力量解决问题,这个确实会比较难(特别是大部分情况下,团队内成员能力不一定非常强,有时候会觉得指导他的功夫自己都搞定了)。

可以把老板的质问作为警钟敲响起来,后面逐步去转变吧。

PS:真的建议标题改一下,这个故事里,核心问题还是在 leader 身上,和开发没啥关系(可能只是因为技术 leader 刚好是开发出身?)。

技术 leader 说输出和效率,leader 却一直在说自动化怎么怎么样,明显是把输出和效率和自动化画等号了。其实老板视角关注的输出和效率,核心是测试是否可以快速完成需求的测试(这个一般看 开发测试时间比),并且保障上线后质量没大问题(这个直接就看客户反馈或者线上问题数量)。至于是否通过自动化解决,这个属于细节,相对关注度没那么高。而且说实话,一个需求过程中都会经常改的项目,自动化做得再好又有啥意义呢?

hu 回复

你这个地图炮,范围很大。而且除了标题说开发外,其他文中内容基本都是在自我反思,并没有在诋毁开发。

请不要断章取义。

你要换位思考。作为测试 LEADER,如果只考虑我做了哪些,我有哪些苦劳,话语权肯定不太够。你话语权不够,为下面人就更难争取利益。
从老板/小老板角度看重什么?
一般有几个点:

  1. 产品质量。
  2. 在压缩生产周期的情况下,至少保证产品不拉跨。
  3. 核心指标测试。
  4. 工程部署

测试本身就是偏服务性质的研发职位,你要去实时关注老板预期,这几项哪个是最重要的,哪个是核心问题,并尝试去解决。
长期的 UI 测试平台,只能解决 5%-10% 的问题,长期老板肯定是不会满意的。

PS:这种吐槽,我都听习惯了。。。这里其实你自己和团队都应该有点危险感。。。

给你个不锈钢铲子,你来产出,好不好。研发工资多少,测试工资多少。莫比比,在比比,我换家公司

说实话,这跟你们记多少 bug 没啥关系,测试资源这块确实没利用好,4:3 比例确实很高,像这种新需求、迭代快的真不建议搞 ui 自动化,耽误交付时间不说,产出也不明显,ui 自动化测试只是保障线上巡检和回归测试这块,是很难被认可的,大厂都支撑不了这样的资源消耗。

我建议调整下测试策略,先保障需求按时发版以及线上无严重 bug,联调时就能介入接口测试,接口自动化和接口点点点耗时差不多,等前端提测后点点点再介入,需求按时发版且无其他需求提测时,再分配到 ui 自动化,不能算在发版计划里头。从老板角度,测试的作用就是保障线上的稳定,给你人力也是为了需求按时上线,像性能这块耗时长的话可以往后放,线上真遇到性能问题也有研发的锅😁

hu 回复

“做的工作说的是什么自动化测试,其实就是鼠标点点点”,当你说出这句话的时候就知道你对测试有非常深的认知,我就好奇这么懂测试的人能写出啥内容,简单看了下回帖全都是唱衰测试,也看出来你测试干了好些年,从你输出的干货能感觉到你比国内 3 万家互联网企业还懂测试。😄

Aaww 回复

不管这个人,这个人就是一个嘚~,有人发帖就在哪里 BB,一直在刷存在感

团队的自动化和功能人员占比问题比较大

我给楼主一下可实施的建议,这个问题很典型,研发团队质疑测试团队,不知道你们在干嘛,看不到专业产出,这时作为测试 leader,应该要有一点危机感了。

首先澄清观念:产出 ≠ 苦劳,结果是最终大家看的,过程辛苦和中间难度可以说,但要主次分明,否则听起来就不太专业,给人一种你很虚你在打感情牌的感觉。

回到上面的问题,一些实际有效的改进点:

现象 1:研发不知道测试在干什么,觉得测试人多价值低

  • 原因:中间过程黑盒,做的事情没清楚外漏,说人话就是平时没给研发刷脸刷得够多,接入研发流程的地方不够多,计划对齐不够清楚,没有度量数据来说问题
  • 解法:需求变更多——测试卡口,规范提测流程;测试很苦逼,自动化维护工作量大——数据说话,需求提测,缺陷数量,缺陷解决时长,测试执行周期等,网上一搜一大把。

现象 2:自动化掰不清

  • 原因:没理清楚自动化的价值
  • 解法:自动化能不能发现问题,有没有用——数据;自动化维护成本如何——数据;哪些用例要做自动化,自动化整体如何持续运营——机制、流程、运营计划

现象 3:研发觉得测试的人一直在 “学习”,其实就是含蓄的说在划水

  • 原因:人员的工作规划不清晰,大家的目标不够明确
  • 解法:1v1 沟通,明确每个人的职和责,每个人有固定的 Topic,定期 review 产出,而不能永远以储备知识为借口来说没产出
王稀饭 回复

“产出 ≠ 苦劳”,回答的很清晰,很专业👍

回复内容未通过审核,暂不显示
陈恒捷 回复

建议删除 6 楼和 8 楼发言,戾气太重,毫无营养

hu 回复

那你作为一名开发跑来测试圈里吐槽,内心确实挺明亮的,在这答非所问,他只是说在平常的会议中突然被关系好的开发被刺,并未吐槽开发的不好,想表达公私分明的态度吧。

你想了解我们怎么吹牛皮,可以多看看论坛里的精华帖,像你这种有技术底子的肯定看得懂吧。

我给个邪门歪道的做法

楼主说的我曾经遇到过,直到测试人员大量离职,测试开发比降到 1:10、1:10+ 后,就没人 BB 什么输出、什么效率了,开发提测质量低,也不敢在我面前 JJYY 了,让干啥就干啥,很爽的。
适当把测试资源降低到预期以下,正所谓 “天之道,损有余而补不足”~~

PS:测试资源充足后,很多时候会找些性价比低的事情干,嗯,以回应某些 “输出不足” 的质疑。

homin 回复

你不要侮辱我们开发,开发队伍里没这号人~

槽神 回复

😂 看来槽神也深受其害

两个自动化 qa,一个手动 qa,一个快速迭代的项目不明白为什么会是这种人员配置

自动化不适用于快速迭代的项目其实这个大家应该都是公认的吧,特别是需求不明确的项目初期,UI 自动化的成本巨大,我都不太理解这个时候就进行 UI 自动化的目的是什么。我倒是建议前期约束研发交付的时候交付文档规范,以及产品改动需求的每次争议都留存好,相信我,你不会愿意,中途产品质疑测试为什么没发现实现的功能与需求不符合(这个改动是产品要求的但是产品不记得了!)。总之,做好所有的记录。其次标题确实太过了,不要和开发做朋友这个太标题党了。

阿东 #28 · 2022年09月02日 Author
Jerry li 回复

谢谢你的建议~

阿东 #29 · 2022年09月02日 Author
Jerry li 回复

谢谢你的分享,一起加油!

阿东 #30 · 2022年09月02日 Author
陈恒捷 回复

谢谢你的回复,从不同角色出发看测试确实会产生一些误解。

阿东 #31 · 2022年09月02日 Author
王稀饭 回复

谢谢你的总结,很详细,确实不能把劳苦=产出。

阿东 #32 · 2022年09月02日 Author
homin 回复

谢谢你的建议

阿东 #33 · 2022年09月02日 Author

根据大家建议,标题已经更新

开发和测试如何更好地配合?
在本职工作范围内,互相给予最大的支持,避免无端相互质疑。

内容有点多,就不多说,针对下面这个说下我的想法。

用客观数据说话

本身我觉得用数据说话也没毛病。但实际上施行起来,我觉得还是弊端不小的。
首先说下用数据说话的目的:为了证明你说所非假。
譬如,证明测试确实做了很多,证明开发提测质量差(这块我们就喜欢这么搞,统计各种 bug 数量来论证,有什么提测中的 bugP1P 分别多少个,有什么集成后的 BUG,影响到其他系统的 bug,每个 bug 都填写各种各样的原因,统计原因归类,比如属于 A 原因属于 B 原因,QA 侧原因分析,PM 侧原因)。
我以我们搞的这块来说说弊端。
1、数据有水分(这就不用细说了吧)
2、增加很多不必要的工作量,而且本人切身感受增加的工作量不少。。。(比如会去纠结这个算 p 几的 bug,这个 bug 开发和 QA 两边原因没统一等乱七八糟的事)
我不太清楚 LZ 打算怎么搞,但是我个人角度认为,数据说话,稍微差了点。
如果去细细询问在一线的人员(这个人员可不要太多水分了,有不少 QA 以及开发,确实不少水分),从他的谈话中大抵你就明白这个开发提测如何,甚至质量原因都能问清楚。不过这个做法很难,因为很多人不说实话(这个时候就看你怎么当领导了)。
从这个角度上说,我是比较认可询问一线人员得出的结论,而不认可数据。但是前者需要你问出实话,以及这个被问的人的和你(你是个提问者)的关系。虽然很难做到,但是团队总归还是有那么一两个人这样靠谱的人的。

至于 “数据说话”,倘若数据假了,起的反作用,我想(这个负作用)是很大的。我是非常建议各位负责人深思熟虑之后,再去做 “数据说话”。

------------补充一下温馨提示:建议 QA 还是以和开发保持良好关系作为首要考虑点。kpi 的东西教不会你什么的,甚至你的 QA 领导也教不了你什么。而你需要的东西,不管是工作上的东西,还是个人技术提升,你都可以从开发那边偷学到的。

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