BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

敏捷测试推进工作笔记(一)

| 作者 段念 关注 4 他的粉丝 发布于 2011年10月8日. 估计阅读时间: 11 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

【从这篇文章开始,我打算在本专栏中记录本人在组织中推进敏捷测试的工作过程,这篇文章描述的是从5月到8月共3个月内的主要工作。在两个月的时间内,我们初步决定了发展方向,在敏捷测试的氛围建设方面都有了一些进展。2个月中主要的工作是:团队改造,工具体系搭建,建立了初步的开发和测试的尊重和良性互动,开始在少数项目中使用自动化测试建立更好的反馈机制和提升效率】

2011 年4月,我离开了原来的团队,加入了一家200人左右的互联网创业公司(以下简称H公司)并担任该公司的Engineering VP职务。我负责的团队包括一个产品开发团队,测试团队和其他两个团队。离开一个成熟的敏捷环境,进入一个新环境,我期望能够使用敏捷方法让这个新公司的开发和测试部门能够有更好的生产率和更好的工程师驱动的文化。从6月份至今,我已经在组织内推进了一些与敏捷相关的行动,从结果上看,敏捷的意识和氛围的确向前推进了一些。当然,在我看来,创造一个更接近敏捷的环境是手段而非目的,因此,这一系列的笔记仅用来尽可能忠实的记录我在这个组织中推进敏捷测试的方式,以及这些推动带来的改善。

H 公司是一个以social game开发和发布为主要业务的公司,在我刚加入的时候,H公司的测试团队有15人,几乎全部成员都没有什么技术背景,采用的测试方式是典型的手工测试。团队使用Testlink工具管理用例和测试执行,使用Bugzilla系统进行缺陷跟踪,自行开发了提测系统用于管理测试提交。测试人员分布在各项目团队中,每个项目有2-4名测试工程师,测试工程师的主要工作方式是被动接受测试任务,按照开发工程师指定的测试范围进行手工验证。显然,这是一个国内企业典型的传统测试团队,测试团队成员充当“发现问题的最后一个环节”,以黑盒和手工测试的方法对应用进行验证。

Socail game这个是一个竞争非常激烈的行业,对social game来说,快速更新和快速发布往往是一款游戏能否成功的关键之一。因此,对H公司来说,快速发布的能力非常关键。通常,开发工程师可以在一周内完成 3-4个新功能提交,但由于测试工程师需要在多个平台和多个浏览器上对应用进行测试,结果测试往往成为产品发布的瓶颈。从开发工程师和产品的角度来看,测试时间太长;而如果为了缩短测试时间而仅将测试范围定义在新功能上,测试中又会遗漏不少问题,导致结果不理想。在这种状况下,测试工程师越来越忙,却完全不能真正在提升产品质量方面发挥作用。

显然,H公司的测试团队采用的传统测试流程和方法在这类要求“快速”的企业中很难适应,除非对测试团队的行事方式与测试文化进行一个彻底的改造,测试团队很难在组织中发挥重要的作用。

敏捷的推进先从团队开始

团队在敏捷中的重要性不言而喻。团队是由个人组成的一个集体,在我看来,决定团队的水准的,自然是团队中的每个个体,如果一个团队中的成员根本就不具备帮助达到这个团队目标的能力,再有能力的领导,再好的愿景也是白扯。因此,首先需要的是从人入手改造这个团队。这个团队中的成员几乎都没有很好的开发和编码背景,要求他们从开发的角度理解测试、理解生产率和推进自动化是不可能的事情。对他们来说,对自动化的理解很可能就是找个工具录制一下,形成脚本,然后简单的维护一下脚本。而我期望推进的是,建立一支真正能够真正与开发形成良性交互,能够帮助推动整个组织的生产率和产品质量的队伍。考虑到整个公司的现状,大规模的替换测试团队的成员是不现实的,因此,在测试团队之外,我们新成立了一个Tools/Automation的组,这个组的目标是推进整个组织的自动化,从生产率上帮助建立自动化框架(不仅仅是测试自动化,而是整个组织的自动化和生产率)。这个组的每个成员都由我自己担纲招聘,虽然到目前为止这个团队只有四个人,但由于每个人的编码和测试经验都比较不错,更重要的是,他们都是爱折腾,对结果负责,愿意推动事情发生的人,因此,到目前为止他们在推动敏捷测试环境方面发挥了主要的作用。

除了建立新的团队外,提高原有团队的招聘标准是另一个手段。虽然各个项目组在新功能更新频繁的情况下,不断的要求增加新的手工测试工程师,但在我的坚持下, “新进入的测试工程师必须要求具有一定的编码技能和知识背景”这一条要求还是能够得到满足。当然,项目组缺人的问题是必须要解决的,因此我主要依靠在项目中可以明确看到结果的逐步的自动化测试推进让项目组意识到依靠自动化测试解决他们的问题比依靠手工测试有效得多。此外,在整个团队中不断要求和灌输“测试价值”的理念,使得开发和测试工程师都能认识到单纯的以“发现缺陷”为目标的测试文化是很难在现有环境中产生价值的。

自动化推进

这里所说的自动化,并非仅仅意味着“自动化测试”。诚然,自动化测试是敏捷测试的基础,但采用自动化技术让产品发布自动化、让不同层次的测试都存在执行的基础,这样才可以将开发和测试工程师纳入到敏捷测试的同一阵营中来。

  1. 为项目建立自动化的构建环境和持续集成环境
  2. 每个项目最少需要有自动化的构建环境和持续集成环境。哪怕持续集成中仅包含一个测试用例,持续集成也至少可以让整个开发组织能够建立基于反馈(持续集成结果)的开发方式。而自动化的构建环境则允许开发和测试之间的协同工作变得简单,且减少了构建过程中出错的可能。能够用于建立自动化的构建环境和持续集成环境的工具非常多,这里就不再赘述具体过程。

  3. 建立初步的代码质量体系
  4. 高 质量的代码是高质量软件的基础。除了对产品的测试外,从源头开始控制代码的质量对促进和提高产品质量也非常关键。Code Review是极好的进行代码质量控制的手段,基于H公司的svn代码库,我们通过钩子,加上开源的一些Code Review Dashboard工具建立了一套强制的Code Review流程,要求所有代码必须经过Code Review后才能被check in到代码库。另外,Code Review系统中集成了静态代码检查工具,Reviewer在评审代码的时候可以直接看到提交代码的静态检查结果报告。

  5. 自动化测试
  6. 敏 捷测试中,自动化测试是必不可少的重要环节。但是,在组织中推进自动化测试并不是一件轻松的事情。首先,如果组织的测试目标已经被固定成了“尽可能发现最多的缺陷”,如果开发工程师、甚至测试工程师自己已经习惯了把发现缺陷和工作时间当成自己唯一的评价标准,在这种情况下推动自动化测试,结果不言而喻。

    组织首先要有自己明确的自动化测试可达成的目标。在我的理解中,自动化测试的最大贡献在于两个:1,让全体工程师(测试和开发)都可以成为测试的执行者和设计者,让验证可以在尽可能小的周期内发生(快速反馈);2,自动化测试不以流程为中心,可以持续演化并适应快速的需要。对H公司来说,显然,通过自动化测试可以达成的,与团队期望最契合的目标应该是“通过自动化测试尽可能在短的测试周期内达到更高的覆盖率”。因此,在我们的自动化测试推进中,该目标成为了自动化测试需要达成的最首要的目标。

    对于任何应用来说,从技术角度来看,最好的自动化测试都应该是在产品设计时引入可测试性,这样可以在不同层次上对应用进行验证。但如果对一个已有产品已经比较固定,且很难对其进行大规模重构的组织来说,对这些已经固定的产品进行重构以便于自动化测试的开展显然是不现实的。在自动化推进时,我们并没有把自动化测试建立在革命,而是革新的基础上。虽然我本人是坚定的大规模UI自动化的反对者,但在对H公司的产品(游戏类应用)进行了详细了解,以及对开发过程进行了详细了解后,我还是不得不承认,在现阶段,使用主要基于UI的自动化测试是更适合H公司现状的方式。目前我们选用的自动化测试工具是Sikuli工具,基于该工具设计了一套适合H公司游戏产品的自动化测试框架,通过mock本地环境等手段,目前UI自动化测试的稳定性可以达到95%以上,对于游戏的测试是一个很好的提升手段。

其他

以上就是我们在3个月内为敏捷测试推进工作进行的改进。不得不说,到目前为止,这才是在前进的道路上迈进了一小步。真正的组织级的敏捷需要持续建立更好的沟通、建立自承诺的团队,以及持续改进。不管怎样,在这3个月的时间内,我们通过这些工作,测试团队的氛围开始发生了变化,开发工程师开始愿意配合测试团队,为其提供更好的测试接口,所有的测试成员都开始意识到交付价值比交付bug重要…… 这是我们向敏捷推进的一小步,但相信是坚定的一步。

接下来的一段时间内,敏捷的核心价值观仍然是指导我们的法则,持改变的勇气,不断检讨,不断优化;保持简单,把资源投入到最值得提高的地方;建立更好的沟通方式,更好的信任与尊重,相信一段时间后,我们能看到接下来的仍然坚定的下一步。


感谢张凯峰对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

疑问一下 by 陈 国栋

你在推行敏捷之前,说到“H公司的测试团队有15人,几乎全部成员都没有什么技术背景”。我想知道,在你推行敏捷之后,这15个人的团队组织关系有什么变化,他们每天的工作内容、所使用到的工具、工作伙伴之间的交流方式有什么变化?从你文章看来,除了你为“Tools/Automation”team新招的4个人之外,原来做纯手工测试的QA,还是继续在做纯手工测试。

段念您好,您的联系方式是?我有些问题想和您单独讨论一下 by Robert White

段念您好,您的联系方式是?我有些问题想和您单独讨论一下。

尤其是对于sikuli工具的使用,我想和您交流一下。

Re: 段念您好,您的联系方式是?我有些问题想和您单独讨论一下 by 段 念

我的email是dennis.duan@gmail.com,欢迎讨论

Re: 疑问一下 by 段 念

有变化。大体上来说是三个方面:1,其中某些有意愿和兴趣,且能够培养的人员承担了一部分自动化的任务;2,他们与伙伴的工作方式和工作目标发生了变化。工作内容只能说在逐渐发生改变,只有纯手工测试技能的仍然在做纯手工测试,在工作方式上通过目标要求引导其转变;3,少部分确实不能接受这种方式的人员离职。

非常感谢您的分享,期待下一期 by flashow flashow

您的经历非常值得学习,希望能看到更多解决现实矛盾的经历。
谢谢!

中小企业的敏捷测试实践 by jiang cay

离开了Google高高在上的精英测试团队,在平民化的中小企业团队中如何开展推进敏捷测试?非常幸运能去跟踪段老师的实践过程,其中很多问题在成熟的大企业中是不会碰到的。

Re: 中小企业的敏捷测试实践 by 段 念

Google的测试团队倒也说不上是高高在上,不过google测试团队的人员技能和意识确实是很容易接纳和实践敏捷的。在人员技能水平相对不那么突出的小团队中遇到的很多问题的确很有特点,解决这些问题需要不断的试探,进两步退一步,需要不停的推动和调整策略,的确很有挑战性。

如何游戏前段的自动化测试投入产出比? by Wang Wilson

跟段老师的经历太相似了,我也在一个游戏公司推动Scrum的改革,但在游戏的前段自动化遇到了一个非常棘手的问题,就是游戏的前端功能变化太快,而自动化的代价很高,导致我们的自动化主要实施在服务器端,不知道段老师是否遇到过这个问题,如何解决的?

Re: 如何游戏前段的自动化测试投入产出比? by 段 念

我们使用前端UI自动化验证游戏的核心功能,而不期望将其作为发现缺陷的主要手段。因此,我们仅选择了P0和P1的用例包含在我们的UI自动化测试中。目前看起来,稳定性还不错,通过在日构建中包含这些测试可以及时发现最主要功能的问题。

Re: 如何游戏前段的自动化测试投入产出比? by Wang Wilson

谢谢段老师的回复~

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

10 讨论

深度内容

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT