研发吐槽测试测不出问题,7/3比例太畸形了

最近研发吐槽测试测不出问题,并列出了五月份测试情况,(研发测出的bug+运营测出的bug+产品测出的bug)/测试测出的bug约等于7/3。得到这个结果我很是震惊,这个比例太畸形了,7/3意味着测试大部分时间没有工作产出,这个比例映射出这样的心里“bug都是产品、运营找出来的,测试一定在划水!”。

研发吐槽测试测不出问题,7/3比例太畸形了

备注:虽然bug数量不能完全代表测试工作情况,但硬要当成一个衡量指标其实也说得过去。

为证实数据的可靠性,我对5月份测试情况进行统计,统计结果为 3/7,与研发所说的7/3还是有一定误差的,误差为什么会这么大,问题出在哪里?

为分析原因,我找对口的研发、产品和运营进行了长谈,沟通出以下结果:

  • 研发:“7/3的比例是个人感觉,没有真实地进行过统计!主要是因为在沟通群或者各种会议上看不到测试的身影,对测试的内容无感,比如上次迭代都不知道测了哪些东西”。
  • 产品:“在测试前没有跟我沟通过,这块功能毕竟这么复杂”。
  • 运营:“验收测试时发现的问题确实不少,感觉测试的工作不是特别给力”。

通过这次沟通,发现多方对测试工作都存成见,为什么会存在这种现象?为进一步剖析问题,我对测试外包的工作进行了整体复盘。原来该研发团队之前没有测试同学,当引入测试同学时,研发团队很容易保持旧有习惯从而忽视测试,好比大家上班坐地铁本不需要身份证,但疫情忽然严重起来,有关部门要求乘坐地铁要携带身份证,但是很多人保持旧有习惯会忘记带身份证。

在过去一个月里,研发流程采用“扁平快”风格,研发过程尽量减少文档、减少会议,减少沟通。这种节奏在人少时不会出现问题,人一但多起来就会出乱子!研发团队引入测试团队,若研发流程无文档无会议不沟通,任何一位测试都不可能配合得出色。所以这次的问题主要是沟通不充分,多方对新需求/迭代没有达成一致,测试做了很多工作,但研发团队无感知。

测试介入研发流程

如果一个研发团队没有对接测试团队的经验,那么在对接测试团队时要注意以下事项。

  • 产品 在需求评审时拉测试同学,让测试同学对需求能够充分了解;参与评审测试用例,能够从产品视角给出建设性意见。
  • 研发 在 系分评审 时拉上测试同学,让测试同学对本次迭代的主次功能进行充分了解;在评估上线时间时要考虑测试同学的测试时间,比如提取预留提测时间;参与评审测试用例,能够从研发视角给出建设性意见。(系分,全称为“系统设计、业务分析”)

上面两个要求对研发和产品提出的,小伙伴们可能会问:“若研发和产品之前没和测试对接过,他们根本不会遵守这个要求!”说的没错,既然研发团队不能,此时就需要测试同学要积极主动些,主动把产品和研发向合作方向上牵引,如何进行牵引呢?测试要知道研发流程是什么,下面给出一个简化版本的研发流程,大家可以用于参考:

研发吐槽测试测不出问题,7/3比例太畸形了

  • 需求收集:运营或者客户对需求进行阐述,产品进行需求收集。
  • 需求评审:产品一般会拉各方开需求评审会,在这个会议上对需求进行宣讲,测试要充分利用这个会议了解需求是什么。
  • 系分评审:确认本次迭代要上线哪些需求;本次迭代的重点功能是什么;需求提测时间、上线时间。

了解研发流程相当于了解每个角色的“作息”,下一步,测试要改变每个角色的“作息”,一般来说,测试要参与需求评审、系分评审、测试、上线四个阶段。在阶段开始前要做以下几件事:

  • 需求评审阶段/系分评审阶段开始前:联系各方提前了解会议内容,比如在系分评审前要了解系分中提到的技术名词和核心链路,避免会上听不懂;提醒会议主持人按时拉测试入会。
  • 测试阶段开始前:要与产品、研发、运营进行充分沟通,设计测试用例时要结合研发、产品、运营视角。
    • 研发视角:本次迭代更改了哪些地方,这些地方需要进行回归测试;本次迭代新增了哪些接口,这些接口是否需要测试。
    • 产品视角:有侧重地进行测试,关键需求要进行全面地测试,非关键需求的测试可以粗糙一下。比如A需求会影响用户使用,需要重点测试;B需求只修改了前端样式,可以简单测试。
    • 运营视角:增加新需求要保障全链路逻辑正确,运营要明确哪些是全链路逻辑。
  • 上线阶段开始前:向研发沟通变更风险点,上线前是否满足变更三板斧,本次变更的影响面。

小结

随着互联网工作压力增大,流程越来越趋向“扁平快”风格,研发过程尽量减少文档、减少会议,减少沟通。这种节奏在人少时不会出现问题,人一但多起来就会出乱子!研发团队引入测试团队会因缺乏沟通造成误解,此时就需要测试主动与研发团队建立联系。



留言

  1. #1

    测试陈(2022-07-11 22:02:04)
    过于真实,工作中必要的沟通少不了