回到网易8个月来的测试团队转型实践

发表于:2017-7-19 11:04

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:李乐    来源:InfoQ

  2016年初月回到网易,进入交友事业部,更加专注于移动互联网APP研发测试领域,在将近一年来的时间里,经历了开发、测试团队的转型,下面讲述带领测试团队从挖掘痛点的转型实践。
  测试团队现状
  交友事业部人员朝气蓬勃,个人认为更像一个创业型的公司,初期技术资源都投入到产品功能需求开发中,对于产品质量稍作妥协,不需要太严格的过程控制和质量把控,相比开发资源而言,测试的投入资源不是那么急需。
  随着用户量的上升,各种类型的移动设备问题错综复杂,用户对产品的质量有要求,部门老大对质量越来越重视,狠抓这块,从2015年Q4、2016年Q1分别招入两名测试人员,整个技术团队对于质量把控的诉求越来越强烈了,到后来整个测试团队跟随开发团队的规模壮大而壮大起来了。
  开发测试人员配比
  交友事业部有三款APP产品:同城约会、美聊、花田,一线开发人员总数20人,一线测试人员总数4人,示例如下(2016年Q1统计):
  图-开发测试人员配比
  图中可见测试开发比例是1:6,Android、iOS端各占一名黑盒测试人员,后端API无相关测试人员参与;
  测试技能现状
  所有产品线的测试手段都是以手工测试为主,无自动化辅助手段,回归测试成本高,Android、iOS独占测试人员忙于业务的功能性需求的黑盒测试,非功能性需求无法满足。
  Android、iOS与后端Server进行数据交互的API规范定义是一致的,早期无相关测试人员参与,导致发现API问题较晚,推迟到客户端功能开发完成阶段才进行检验,同时也造成后端API回归成本高;
  功能测试以及API相关测试在研发测试过程走一轮、预发布环境第二轮、生产环境走第三轮,深度依赖于手工测试,发现问题滞后,相比需求、研发阶段修复的成本来说,发现的阶段越晚修复成本越高,最终可能导致带着严重问题上线运营。
  测试流程现状
  交付式测试,开发人员把相关功能任务设置为done之后交付给测试人员,测试人员未全程参与从需求源头开始跟进(及时了解需求背景和细节,消除需求含混性,及早开展测试用例编写工作),从而研发过程中客户端功能、后端API的可测试性(一个完整的功能是可以分多个功能小点提测,最终完整再提测一次)无法提高,测试人员也无法及早进行冒烟测试;
  无测试人员专属的持续集成构建环境,Android、iOS打包依赖开发,测试人员存在时间等待上的开销成本一直存在未能降低。
  测试三轮验证:测试环境验证第一次、预发布验证第二次、生产验证第三次,为什么做三轮,这三轮的评估依据是什么?
  整个测试过程,只有测试人员参与,产品、客户端开发同学的协助如何提升融入进来呢?
  测试任务评估没有依据
  针对需求的相关测试任务,出牌评估工时,没有评估依据,直接拍脑袋进行,体现在:这个需求需要测试哪些方面?涉及客户端Android、iOS哪些特性?有哪些兼容性需要测试?只有把所有相关点列出来,评估完整的时间,再进行合理的取舍,让质量维度维持在一个可接受的平衡点,而不是一味追求最高质量,往往很多时候,利用现有资源做最平衡的质量优化,可接受的容忍度。
  所谓平衡点的简单例子:
  1.字体样式的问题,并非致命的,可以权衡接受跟着上线;
  2.客户端列表过长溢出,没有边界判断机制,这就是致命的,必须修复上线;
  3.客户端数据出错了,后端还可以通过快速发布来解决,并不影响客户端的上线;

  图-改进的测试评估依据
  生产力改进实践
  生产力改进实践环节,是围绕几个大方面开展的:
  图-生产力改造围绕方面
  敏捷开发
  建立Scrum流程框架(版本开发流程),以此为基础的版本开发模式,各个角色紧密配合的PDCA循环:高度合作,善于计划和总结、拥抱变化、高度可视化。
  图-Scrum流程框架-交友
  自研的燃尽图进度跟踪工具
  过去Jira任务管理系统自带燃尽图不能根据团队特点,展示实际进度和体现反馈风险所在,导致错过反馈进度问题的最佳时间,因此根据团队特性,自研能够反馈实际进度的燃尽图,让项目进度透明化,技术、视觉、交互、产品都参与到风险识别和反馈中来。
  带来的效益:
  1.使用新版燃尽图之后,每日晨会分析历史进度问题有依据,能够明显看出风险所在
  2.产品人员主动关注燃尽图趋势变化,及时调整有问题的任务,提高研发交付的时效
  3.每日工时可以看到研发、测试人员的个人进度,及时沟通遇到的困难,推进解决
  图-自研的燃尽图
  负责客户端的测试人员承担产品职责单一,技术要求多层次
  最初测试人力资源不足,为了提高更大的复用率,要求每位测试人员负责客户端Android、iOS的两端的测试工作,编写一份基础用例,根据每端特性在测试过程中再改变策略,落地实施的第一个季度就暴露出问题:
  1.同时兼顾一个产品多个功能的测试任务,对于客户端开发同学而言,他们是并行工作的,而测试同学需要在不同功能的Android、iOS两端来回切换,导致效率低;
  2.同样问题也存在兼顾多个产品的测试任务,有些产品是同时进行的,需要在多个产品的任务中切换,导致对两个产品都不熟悉;
  3.测试设备占用时间严重,在进行Android、iOS轮换切换的场景中,一人独占相关设备;
  改进:单一职责,专职专责,原则上不再进行跨项目的版本任务,也不在版本中负责一个功能的Android、iOS相关测试任务(除了运营的相关活动项目可以兼顾Android、iOS测试),主攻Android、iOS单一方向的功能测试、自动化测试,说的高大上一点好像成了全栈测试工程师。
  实施半年之后,收益颇深,各自负责Android、iOS的测试同学结对编写测试用例,抽取共性部分,运行时附加个性化的系统特性,并行测试效率提高,设备占用率降低。

31/3123>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号