软件测试管理

当前位置:首页 > 软件测试管理

《Google软件测试之道》第四章 续1

4.4 Gmail测试工程经理Ankit Mehta的访谈


Ankit Mehta在成为测试工程经理之前是一名测试工程师(TE)。在最初的几年,AnkitMehta一直在和测试自动化代码打交道。他作为技术经理的第一个大项目正是Gmail。


Gmail是个巨大挑战。它非常庞大,涉及很多快速发展的部分.Gmail整合了很多Google的产品,如Buzz、Docs、 Calendar 等。它需要处理那些已经站稳脚跟的竞争对手所支持的邮件格式。Gmail 有非常庞大的后台系统。要知道Gmail 是一个云服务,用户可以通过任意一种主流浏览器进行访问。有数亿用户在使用Gmail,他们希望打开浏览器后Gmail就能工作,这从某种意义上也增加了复杂性。用户需要快速、可靠、安全的服务,并且还能包括自动处理垃圾邮件。增加新特性必须保证之前的功能持续可用,这使得测试任务变得非常复杂。一旦Gmail出现问题,全世界的人就会在第一时间发现。因此,测试工程经理

责任重大。


我们对Ankit进行了采访,了解Gmail是如何测试的。


HGTS:告诉我们你是怎么接手一个新测试项目的吧。你首先会做什么事,问哪些问题? 


Ankit:加入一个新项目的头几个星期,我主要用来倾听而不是发表意见。深入理解团队非常重要,要学习产品的架构,了解团队的最新动态。我不能接受一位医生在观察 我不到五分钟的时间就给我开具抗生素类的药品。同样地,我也不期望一个测试团队可以接受我一开始就提出的什么解决方案。在进行诊断之前你必须先要学习。


HGTS:我们和你一起工作过,你可不是那种安静的类型啊。我估计你是不开口则已,一开口就会滔滔不绝,如黄河泛滥般一发而不可收拾!


Ankit:噢,是的!不过我也不会什么都说。多年来,通过不断地聆听,我发现最有力的问题就是“为什么”。为什么你会进行这些测试?为什么你会想到这个用例?为什么你选择把这个任务自动化而不是那个任务?为什么我们要投入做这个工具?


我感觉人们有时候做事只是因为看到别人这么做,或者他们测试某个特性的时候只是做那些他们知道怎么做的东西。如果你不问他们为什么,他们自己也不会费心思考这事儿,因为他们已经把那些作为了一种习惯。


HGTS:那什么样的答案算好答案呢?


An kit:第一,因为它能够提高产品的质量;第二,因为它能提高工程师开发产品的效率。其他答案都没这些重要。


HGTS: Gmail 团队注重生产效率是出了名的,所以我理解你会这么说。不过除了质量和效率之外,你对测试工程经理还有什么建议来建立一个健康的工作氛围呢?


Ankit:团队的气氛非常重要。我深信优秀的产品和优秀的测试团队紧密相关。你必须要有拥有合适技能的人,正确的工作态度,并做正确的事情。特别是团队中资深的人,因为团队的文化和氛围很大程度上来源于这些人。拿Gmail来说,我花了三到六个月来建立团队,让团队具有凝聚力,每个人都能理解其他人的角色。当你有了一个好团队,就不会由于一两个人的不适应而出现问题。测试团队和开发团队的关系也是一种非常重要的气氛。当我刚加入的时候,这种气氛并不好。测试团队自顾自的工作,而开发团队也不认可测试团队,这是非常不好的。


HGTS:你肯定把这个问题解决了,能具体谈谈你是怎么处理的吗?


Ankit:我刚加入Gmail的时候,测试团队只是专注于执行一系列WebDriver的测试,每个版本执行一次。每次执行测试结果都会由绿(成功)变红(失败),然后再花大力气修复这些测试,让他们能够再变绿。开发团队没有过多质疑这种做法,由于这些测试通常还是能发现一些重要问题的,因此这种做法就一直延续下来了。但是曾经有好几回代码变化很大,测试代码根本来不及修改。整个过程非常脆弱,不能适应Gmail的变化。这是一种过度投入,因为要让它最终发挥作用所需的工作太多了。


可能是因为我新加入的这个项目,所以能发现一些其他人不能发现的事情。在我看来处理延迟是Gmail最大的问题。严格来说,从用户的角度来说,Gmail 最大的特性就是它的速度。我料想如果我们为开发团队解决了这个问题,我们就能赢得他们的尊重并开始建立平等的关系。


这是个难题。我们必须测试Gmail老版本和新版本速度上的差异,当新版本的速度下降时及时发现。然后我们需要检查所有新版本里改动的代码,并找到速度变慢的原因,从而修复这个问题。这是一个痛苦的过程,非常耗时,并伴随大量的尝试和失败。


我曾经和一位测试开发工程师一起想办法,想让Gmail的速度变慢,以便于我们能更好地观察前端和后台数据中心的通讯,从而发现造成性能下降的原因。我们最后到处找了些旧机器,弄了一大堆512M内存、40GB硬盘和低速CPU的机器。Gmail 在这些机器上运行速度慢了很多,我们可以把所需的信号分辨出来,然后开始运行长时间的压力测试。头几个月特别艰苦,我们有几次误报。我们花费了大量的精力搭建基础设施,可没有什么产出。但是后来,回归测试的需求滚滚而来。我们可以测量到毫秒级的性能损耗并把数据记录下来。开发工程师能在几小时内就发现产生延迟的问题,而不是以前的几个星期。这样就可以趁问题刚出现的时候就开始调试,而不像以前得在几个星期以后才能开始。这件事立即为测试团队赢得了尊重,以至于在我们着手开展接下来的重要任务(修复端到端的测试和搭建高效的负载测试平台)时,开发工程师实际上还自发地帮助我们。整个团队发现了高效测试带来的价值。Gmail的发布周期从每三个月缩短到每周,再到每天都能向我们的部分用户发布新的版本。


HGTS:所以经验就是解决掉一些难题来赢得尊重。我喜欢这点。不过做完这些之后你还做了什么?


Ankit:其实,难题永远也解决不完!不过你说的对,基本思路就是关注最重要的事。我们确定Gmail最紧要的问题,然后一起解决它们。通过团队配合,你会发现这些问题并不那么困难。当然,我还是坚信只应该关注最重要的事情。每当我发现团队打算做太多的东西的时候,就好像你要同时做五件事情,但是每件只能完成80%的时候,我就会要求他们退回来重新安排优先级。把你需要做的事情减少到两到三件,但都能完成到100%。这样团队才能获得真正的成就感,而不是好多事情在他们手里没有完成。如果这些工作最后都能积极地影响到产品质量,那么我也会感到特别高兴。


HGTS:大家都知道Google的每个经理都有很多直接下属,而且经理自已还需要从技术上有所贡献。你怎么平衡这些事情?能告诉我们你自己是怎么完成那些技术工作的吗?


Ankit:管理下属和与其他人沟通确实是一种干扰。我其实总结了两个办法来让自己能保持技术敏锐度并像工程师一样参与其中。


第一,在与开发工程师和测试开发工程师团队沟通的过程中,有好多事情可以做,我可以选择留下一部分自己来完成。我在设计阶段会积极地参与,持续地跟进项目并且自己也编写测试。


第二,其实这才是关键的部分。如果你想做一些技术工作,就必须尽量排除管理方面带来的干扰。起先,我每周都花一两天的时间做我自己的工作。 我有一个项目是把Google ;Feedback整合到Gmail里,这个工作让我能从开发的角度来看待测试。当我碰到一个脆弱的测试,或者测试架构的某些部分拖慢了我的测试进度时,我就能够理解那些全职的开发工程师怎么看待我们的测试工作了。尽管如此,只要我在Google总部的办公室,人们总能想办法找到我,所以我就跑到苏黎世Gmail团队的办公室去。虽然在那儿有九个小时的时差,但是环境就安静多了,我在那里也不是谁的经理。我可以混进一个技术团队而不怎么引人注目。我在苏黎世干了好多活儿!


HGTS:你对测试项目的人员配备有什么建议吗?开发测试比是多少会比较好? SET和TE的比例呢?


Ankit:人员的问题其实很简单,那就是绝不妥协。选用不合适的人来填充名额永远要比等待合适的人员要糟糕。只选用最好的人,不能动摇。Google不让公布人员比例数据,不过以前我们团队中测试人员的比例比正常水平高很多。自从我们解决了很多最初的问题,并得到开发工程师的支持以后,我们的比例就降到和Google的标准水平差不多了。从技能分配的角度来说,Gmail的经验是用20%的测试人员进行探索式测试。任何关注用户体验的产品都需要探索式测试。还有30%的测试工程师关注于产品的整体性测试,他们和测试开发工程师一起来保证测试的效果。另外50%的工作,是测试开发工程师开发相关的自动化测试和工具,以保持代码库的健壮和提高开发人员的工作效率。我不敢说我在下一个项目还会按照这样的比例分配,但是这个比例对Gmail来说是有效的。


HGTS:我知道你现在开始负责Google+的测试了。在新项目中你发现哪些在Gmail的经验是最有价值的?


Ankit:首先,不要把你所有的精力都放到前端。Gmail拥有最庞大的分布式后台系统,那里还有很多的测试问题我们尚未解决。除此之外,还有很多经验教训值得吸取。


●使用与应用程序开发语言相同的编程语言来编写测试。

●让负责开发新特性的人同时负责相应测试的执行,他需要对漏掉的测试负责。

●关注测试基础设施的建设,让测试的编写和执行非常容易,甚至比忽略它们还要容易。

●20%的用例覆盖了80%的使用场景(可能会有些出入)。把这20%自动化而别管剩下的。把那些测试通过手工完成。

●这里是Google,速度才是王道。如果用户只在乎一件事,那就是速度。确保我们的产品足够快。进行性能分析以便于可以证明给所有人看。

●与开发团队的沟通至关重要。如果这点做的不好,你就会疲于应付,那可不是什么好事。

●Google的DNA里富含着创新精神。测试团队也应该被看做创新者。发现重要的问题并能创造性地提出解决方案。



相关内容

文章评论

表情

共 0 条评论,查看全部
  • 这篇文章还没有收到评论,赶紧来抢沙发吧~