Gmail测试工程经理Ankit Mehta的访谈(2)

发表于:2014-02-25来源:Csdn作者:志敏点击数: 标签:测试经理
HGTS:大家都知道Google的每个经理都有很多直接下属,而且经理自己还需要从技术上有所贡献。你怎么平衡这些事情?能告诉我们你自己是怎么完成那些技术

  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里富含着创新精神。测试团队也应该被看做创新者。发现重要的问题并能创造性地提出解决方案。

  HGTS:你有发现技术团队可能遇到哪些陷阱吗?

  Ankit:有的。假设我们知道用户的需求,然后进行了大规模的改动或编写了大量的代码提供新特性,却没有进行小规模的试验。如果用户不喜欢这些改动,麻烦就大了,而针对这些特性构造的测试框架再好也是浪费。因此,要先为少量用户放出一个版本,获得必要的反馈,然后再为大量的自动化测试进行投资。

  另外,试图构造完美的解决方案可能花费太长的时间,到时候市场的发展早已超出你的想象了。应该快速迭代,展现阶段性成果。

  最后,就像开车一样,你必须找到测试的离合点。过早编写测试,有可能由于架构的变化导致全部工作作废。若等待太久,则又可能错失测试良机而导致没有充分测试。测试驱动开发是不错的方法。

  HGTS:对于个人来说有什么陷阱吗?年轻的测试工程师和测试开发工程师在新项目里会犯哪些错误?

  Ankit:是的。他们可能一上来就开始干,不明所以。他们写了很多测试,但忘记思考为什么要写这些测试,怎么让这些测试为整体目标服务。编写测试的时候,他们往往没有意识到他们还要负责维护这些测试。测试开发工程师应该牢记测试应该是开发人员的工作而他们自己应该专心让测试成为开发人员工作中的一环。我们通过编写工具帮助开发人员做到这点,而且应该让开发人员在维护开发代码的同时也负责维护测试代码。这样一来,测试开发工程师才能集中精力让测试执行得更快,更容易分析。

  测试工程师有时候会迷失方向,做起测试开发工程师的工作。我们希望测试工程师更全局地看待整个系统,全面地掌控整个产品。他们的重点应该是从最终用户角度考虑的测试,帮助测试开发工程师和开发工程师确保所有的测试和底层测试框架都被正确有效地使用。测试工程师编写的工具和对问题的诊断应该能够影响整个产品。

  HGTS:除了你前面提到的性能方面的自动化测试以外,还有什么测试方面的工作让Gmail获得了巨大的收益吗?

  Ankit:JavaScript自动化测试。我们为Gmail本身加入了一个用于自动化测试的servlet。通过它,开发人员就可以使用与前端开发一致的编程语言编写端到端的测试(译注:端到端的测试是指涉及整个应用系统环境,在现实世界使用时的情形模拟的测试。)。因为它使用很多相同的函数和程序库,开发人员对于如何编写测试代码很熟悉,没有学习曲线。他们可以很容易地写出一些测试,来检验他们的新代码是否影响了Gmail的正常功能,也能够更好地保护他们开发的特性不被其他开发人员破坏。现在,Gmail的每个新特性都至少会有一个通过这个servlet编写的测试。最棒的是,在我现在负责的社交产品里面我也在用这个方法。我们已经有了大约两万个自动化测试!

原文转自:http://blog.csdn.net/zuoninger/article/details/17409325