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

转载自:http://www.uml.org.cn/Test/201707191.asp

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的测试同学结对编写测试用例,抽取共性部分,运行时附加个性化的系统特性,并行测试效率提高,设备占用率降低。

自研的API管理和测试平台

过去后端的API规范是通过word文档进行管理,版本变更是需要手动通知相应人员,而且每个人编写的格式不统一,容易造成冲突,解决上有时间开销,另外修改跟踪反馈上的成本很高,开源项目中也没有能够适合交友团队模式的工具,因此投入开发API管理和测试平台。

考虑到客户端与后端交互是通过API进行,将API平台化管理带来效益:

1.使用平台化管理清晰呈现MobileAPI接口分布图,有效减轻了后端同学管理接口规范的工作;

2.方便客户端同学快速查阅和版本对比;

3.API修改历史记录对比,修改后第一时间系统自动通知相关人员;

4.在接口定义完之后,可直接生成API Mock,节约手工写mock接口的时间,客户端同学可以直接开始开发工作,与后端开发并行;

功能点包括以下三个方面:

API 统一规范

支持在线管理接口规范文档:接口规范管理功能有很多特性,包括自动生成change log,自动生成技术审查的规范文档,review通知,接口版本管理,支持任意历史版本的对比,方便追踪每个版本的变化。

后端同学只需要专注于接口定义,大大节约了文档维护的时间,更早投入开发工作。

图-API规范示例

图-历史版本diff对比

API 模拟调试

平台支持从接口规范文档直接生成API Mock,在后端接口开发完成之前,前端、客户端的同学利用Mock Server摆脱后端接口的依赖,直接开始开发工作,与后端开发并行。

图-API模拟调试节省时间

API 自动化测试

平台支持从接口规范文档直接生成API测试用例,测试人员集中参与关键场景编写,执行用例之后自动生成测试报告咯,测试同学可以在后端开发的同时,写好测试用例,在开发完成后做冒烟测试,以及回归测试,提升测试效率。

图-API自动化用例流程

图-API自动化测试报告

持续集成与静态代码分析

过去代码构建在开发人员本地进行,每次提交在解决冲突上时间开销大,每个环节发现的问题滞后,无法自动化集成、按需构建,以及代码的质量没有数据参考。

团队需要引入有效的自动化构建平台,以及静态代码分析平台,用以指导日常开发过程的质量改进,将代码问题的反馈机制自动化,构建数据可视化。

持续集成

为了让产品可以快速迭代,同时还能保持高质量。技术团队对各产品的各端都建立了持续构建平台:在代码集成到主干之前,必须通过自动化测试。只要有一个测试用例失败,就不能集成。保证持续地发现、反馈和解决问题。

图-美聊持续集成

静态代码分析

为了保证代码质量,从代码层级降低线上出错的可能性,技术团队引入了静态代码分析技术:在不执行计算机程序的条件下,对源代码进行分析,找出代码的设计缺陷,例如代码规范、内存泄露,以及体现总体质量:代码覆盖度、技术债务的趋势图,通知技术改进,拦截在上线之前,这些数据都成为QA统计的数据来源。

图-Sonar静态代码分析qa仪表盘(Java、iOS、Android)

客户端手工覆盖度数据收集工具

过去执行完测试用例之后,无法考量哪些代码覆盖了,哪些没有覆盖,测试用例写的好不好,为了解决这些困境,在客户端Android、iOS植入手工测试覆盖度工具,收集代码覆盖度展示,目的是找出测试过程中未被覆盖的代码,指导测试人员调整测试策略,开展探索式测试。

图-客户户端UI手工测试报告

下图是执行美聊2.8版本iOS相关用例后的统计结果,可以根据结果调整测试策略,例如:如果改动了登录模块,目前用例覆盖度比较低,那是需要加强特殊场景测试,还是其他方面呢?这个需要团队review下做出决定。

图-美聊2.8-iOS手工覆盖率

利用BugTags工具的问题反馈

过去发现线上问题无有效收集数据的手段,用户反馈之后,需要相关人员跟进沟通,询问环境、设备等诸多问题,整个过程繁琐,人力投入开销大,引入BugTags是为了简化Bug提交过程,记录重现场景相关信息,将客户端的大量复杂操作最大限度简化。通过白名单机制,美聊可以让用户打开Bugtags摇一摇问题,提交用户的相关环境、设备信息,进一步推进排查问题的效率。

图-BugTag竞品分析

BugBash质量活动

传统的产品走查,产品、视觉、交付、运营只对自己负责的功能部分有了解和检查,缺乏一个需求方的整体走查。当有人发现一些功能间互相关联的问题时,已经比较晚,修复成本高。引入Bug Bash(所谓Bug大扫除的活动),在项目开发阶段的末期,专门划出一个专门的时间段(通常1天),打破以往非技术人员未参与的做法,在这期间所有参与项目的人员(技术、产品、交互),集中全部精力,运用各方面的知识来搜寻项目的Bug,做到及早发现问题。

图-Bugbash流程

会后将问题汇总,用以推动开发改进功能。

图-Bugbash记录

QA数据收集

在Sprint总结会上为了让项目成员能更加清楚了解整个Sprint的质量、进度问题,从Q4开始对每个Sprint都做了数据收集和展示。通过收集每个迭代版本的工时、bug数据,在总结会上向全体人员(技术、产品、视觉、交互、运营)呈现当前版本总体质量多维度数据,指导工作的改进方向。

· 按照阶段的bug分布展示

图-bug分布展示

按照组件的bug分布展示

图-组件分布展示

Android Monkey崩溃性测试

持续集成环境每日代码daily build之后,夜间在测试专属服务器进行长达几个小时的Android Monkey崩溃性测试

图-Android Monkey崩溃性持续构建

图-Android Monkey崩溃性测试报告

兼容性质量风险控制转移

目前交友测试团队现有的Android测试机型不足,为了解决Android碎片化,特别是兼容性问题,借助公司内部的易测平台来控制质量风险。

图-网易易测

图-网易易测:美聊基础兼容性测试

图-网易易测:花田基础兼容性测试

重点关注基础兼容性:安装、启动、monkey随机、卸载。

团队人才建设

16年初的测试团队规模太小了,业务测试需求不足以满足,人员技能集中在黑盒测试,没有移动UI自动化测试、后端Server API自动化测试、测试平台开发的相关经验,并且全员对于Android、iOS代码不了解,白盒测试无实践经验,也会导致排查问题不够深入了解原理。

从16年Q2开始制定团队建设技术,那么整个测试团队的关注点是什么,如何聚焦,根据技术总体需求、产品需求来落实测试需求呢?

根据团队特性,测试、开发划分了边界,只有从这些方面出发,才能更好要求组员的技能形成阶梯化,以及在招聘要求是按照此需求来落地,市场上大有可为之人,如何切实际为之更重要,下面从几个方面来谈谈。

测试团队关注点

Martin Fowler在博客中解释了TestPyramid,如下图所示:

图-Martin Fowler:TestPyramid

单元测试是第一道测试关卡,也是一个陷阱,测试人员如果投入到此环节上,将是一种资源耗尽型的质量活动。比业务熟悉程度,测试人员没有开发人员高深,比写单元测试的效率,测试人员没有开发人员高效,这里交友测试团队也跳坑了,历经一个季度跳入、跳出,理想的状态下是:开发的框架很松耦合,例如使用了MVP/MVVM开发模式,实际情况是这些技术债务在逐步偿还,熟悉代码的开发人员进行单元测试都有阻碍,测试人员谈何容易,简单点来说不务正业,投入产出比低。

真正要从业务需求的痛点出发挖掘适合团队的方向:测试层次的关注点是最清晰的一条分水岭隔离开发代码级别的:单元测试、集成测试,测试人员真正的关注点是:以手工测试为主,自动化为辅的发展阶段,同时围绕整个研发测试过程的质量反馈,包括:需求阶段、开发阶段、发布阶段、运营阶段。

图-测试层次关注点

理清整个需求之后,就是团队成员角色转型:

图-岗位的转变

分为三种:

基本职能:手工测试工程师,进阶职能的:自动化测试工程师,再高级一点,测试开发工程师,其实也可以称为全栈,名字不是最重要,也不会设立这种title,只是要明确把活给细分出来。

最后,根据需求,也把产品测试人员分布明细理顺了:

图-测试人员产品线分布明细:2016年Q3

按照此规划来落地招聘需求,避免因人设岗,而是实实在在的产品需求、技术需求来决定人才所向。

测试团队文化建设

由于篇幅有限,简单来说形成学习分享的技术氛围,让测试人员定期组织技术分享,这些技术主要是可以用于生产落地以及对新技术的调研成果展示均可,另外有一些虚拟组设置,例如:自动化测试组、平台开发组,用于把兴趣相同的组员融合到一起,投入到合适的方向上。

以上是本人在网易交友事业部一年以来对测试团队转型带来的分享,在合适的阶段对测试资源做合理的投入是有必要的,发展初期的困难适当取舍产品质量,换来更多功能亮点吸引用户,占领市场,站稳脚步,发展中期,确保用户的活跃、稳定,是需要靠产品质量取胜的,产品功能并不在于多花俏,有新意、简单化、易传播这几个点可以适当考虑,其实到了中后期,技术很多处于还债阶段,之前设计的系统业务模块解耦、微服务化,提高可测试性都非常重要,而测试人员往往对于技术还债的重构要更加留意,一不小心就掉进坑里,久久不能自拔,同时最后牺牲最宝贵的就是测试质量,这是需要取舍的,别以为质量就是高高在上,测试团队的利益应当与开发、产品团队的保持一致,这才是发展的硬道理。

另外,在接下来一年有计划的话,交友测试团队会把关键环节的实践在infoq逐一分享给大家,敬请关注,最后附上一张《网易交友事业部测试团队技术栈》:

时间: 2024-10-25 20:38:48

回到网易8个月测试团队转型实践的相关文章

测试团队成功适应敏捷的障碍

测试团队在从传统开发模式向敏捷模式转变的过程中存在各种障碍,敏捷测试专家Lisa和Janet从自身经验出发探讨了其中的原因和解决方法. 任何变化都面临成功路上的障碍.组织文化可能是要克服的最大障碍.组织文化一旦建立就很难改变.组织文化的形成需要时间,一旦就绪,员工会忠于该文化,这使得对改变相当的抵制. 丧失身份 由于很多原因,测试人员坚持独立的质量保证团队,但是主要原因是害怕,特别是: 害怕丧失质量保证人员的身份    害怕如果向开发经理汇报,会丧失支持,程序员会获得优先权    害怕缺乏在敏捷

构建高效测试团队11层武学心法

     测试是一门武学,流程是武技.工具是武器,思维是秘诀.有简单的如花拳秀腿,也有深奥的九阴真经.九阳真经. 测试好比玩魔兽世界,知己知彼,方能百战不殆. 测试好比玩CS,玩得好可以一枪爆头(轻松找出系统缺陷),玩得不好,上线后被客户骂得晕头转向. 所以我们要在打好拳脚的基础上用各种测试技能武装自己,然后再根据自己对测试质量的了解去不断挖掘自己的潜力(作为测试管理者就要不断发现并挖掘团队成员的潜力,使之快速成长),全方位提升各项测试技能,例如,怎么了解当下系统业务知识.怎么了解当前系统需求.

构建高效测试团队11条法则

       测试是一门武学,流程是武技.工具是武器,思维是秘诀.有简单的如花拳秀腿,也有深奥的九阴真经.九阳真经. 测试好比玩魔兽世界,知己知彼,方能百战不殆. 测试好比玩CS,玩得好可以一枪爆头(轻松找出系统缺陷),玩得不好,上线后被客户骂得晕头转向. 所以我们要在打好拳脚的基础上用各种测试技能武装自己,然后再根据自己对测试质量的了解去不断挖掘自己的潜力(作为测试管理者就要不断发现并挖掘团队成员的潜力,使之快速成长),全方位提升各项测试技能,例如,怎么了解当下系统业务知识.怎么了解当前系统需

让测试团队慢慢死去!-有同感,转载

看完这篇文章想说的话: 技术发展是很快的,本人出生软件开发,后转做测试,在这四年里,体会很多.从一开始的手工测试+loadrunner性能测试,那个时候黑盒测试要求多,工资也还比较高,一直到现在,市场需求逐渐转到要求会coding脚本居多的测试“开发”工程师职位,相对的工资也比纯手工的点点点高出一截,但是要求相对的开发能力也要不必开发弱,各种技术原理都需要有所涉猎和想法. 特别是还在上学和想要从事这个行业的兄弟姐妹们,如果不跟上时代的节奏,会被渐渐淘汰的. 这个阶段发展应该还是在中间的过度阶段,

如何管理好测试团队

如何管理好测试团队 1.作为一个团队的管理者,最起码的是要自己懂自己产品或项目的业务.这一点很重要,第一这样有助自己分配工作给团队中的成员,要不然自己都搞不清楚业务难度和业量就分配工作给team member是件很让人难以接受的事情.第二,有助于自己和其它team或department的合作和沟通,不至于其它team提出的问题,自己还不清楚就答应或否定要做. 2.作为一个管理者,要懂更多的技术,至少是了解更多的测试技术,要了解其工作原理,这样有助于自己帮助团队成员research或者说技术的应用

史上最全的测试团队组建方法

背景:公司刚成立一个产品线,自然同时需要组建一个对应的测试团队,这个时候公司选择了小A来负责组建和管理该测试团队,并且当前就小A一个人.那么问题来了,作为一个新任命的测试经理,小A应该一步一步怎么去做呢?都需要哪些技能才能够承担这样的责任呢? 寻找队友:所谓巧妇难为无米之炊,第一步肯定就是要招人了(这个时候对于团队的目标应该也有个大概的方向,后面详细说明):当然, 公司也不是土豪,给的预算也有限,一般很牛逼的人估计也不愿意过来.在这样的情况下,如何找到合适的队友呢?不错:找潜力股,然后在团队里面

你理想中的测试团队是什么样子的?

有的测试团队会让你工作很开心.工作也很有价值,有的测试团队工作不开心.心也那么累,所以理想的测试团队是什么样子的?下面只是我个人的看法,欢迎大家一起讨论. 首先看看何谓团队,本人的理解是为达成共同的目标而相互协作并利用各自的技能.知识.资源的人.物.事等.基于以上定义中的要素,所谓的完美团队与团队100分是根本不存在的,团队是无限趋于100分,因为团队成员再亲密,也不可能是切肤之触,另外团队成员的思维和出发点不尽一致,即使团队成员就某一项的某一点达成共识,也是短暂的,如果一个团队中的所有成员思维

如何组建测试团队?

最近有一个朋友入职一家新创业公司,有幸成为测试负责人.在开心之际也迎来一个问题:就是作为一个新晋的测试主管,应该怎么开展工作才能尽快体现自己的价值,以及体现测试部的价值? 话题有点大,比如如何制定部门规划.流程规范,如何制定KPI,如何提升人员素质,如何打造团队文化和凝聚力,如何提高执行力......所以我觉得有必要围绕着测试部建设这个话题,把自己的一些心得整理成一个系列. 今天分享的话题,也是这个系列的第一步:即如何组建测试团队? 几年前,我作为第一个测试人员入职一家处于创业起步阶段的公司,负

一个测试经理的分享:我是如何管理测试团队的

很多刚从测试人员转向测试管理岗的同学,肯定会有很多疑惑,不知如何下手 且一时观念无法转变 到底该如何管理测试团队? 很多同行已经写过N多类型专题文章 今天老徐主要分享自己的经验,以及老徐是如何管理测试团队的 仅个人经验分享 可参考.欢迎点评 --正文-- 测试管理,范围很广 带1-2人也是管理 带几十人也是管理 但是管理方法肯定会不一样 今天分享10人左右的测试团队,老徐是如何管理的 1. 首先,根据业务情况,或者项目情况,拆分成几个测试小组: 每个组,有一个测试负责人 老徐只需直接管理每个组的