Ankit Mehta在成为测试工程经理之前是一名测试工程师（TE）。在最初的几年，Ankit Mehta一直在和测试自动化代码打交道。他作为技术经理的第一个大项目正是Gmail。
Gmail是个巨大挑战。它非常庞大，涉及很多快速发展的部分。Gmail整合了很多Google的产品，如Buzz、Docs、Calendar等。它需要处理那些已经站稳脚跟的竞争对手所支持的邮件格式。Gmail有非常庞大的后台系统。要知道Gmail是一个云服务，用户可以通过任意一种主流浏览器进行访问。有数亿用户在使用Gmail，他们希望打开浏览器后Gmail就能工作，这从某种意义上也增加了复杂性。用户需要快速、可靠、安全的服务，并且还能包括自动处理垃圾邮件。增加新特性必须保证之前的功能持续可用，这使得测试任务变得非常复杂。一旦Gmail出现问题，全世界的人就会在第一时间发现。因此，测试工程经理责任重大。
我们对Ankit进行了采访，了解Gmail是如何测试的。
HGTS：告诉我们你是怎么接手一个新测试项目的吧。你首先会做什么事，问哪些问题？
Ankit：加入一个新项目的头几个星期，我主要用来倾听而不是发表意见。深入理解团队非常重要，要学习产品的架构，了解团队的最新动态。我不能接受一位医生在观察我不到五分钟的时间就给我开具抗生素类的药品。同样的，我也不期望一个测试团队可以接受我一开始就提出的什么解决方案。在进行诊断之前你必须先要学习。
HGTS：我们和你一起工作过，你可不是那种安静的类型啊。我估计你是不开口则已，一开口就会滔滔不绝，如黄河泛滥般一发而不可收拾!
Ankit：噢，是的！不过我也不会什么都说。多年来，通过不断地聆听，我发现最有力的问题就是“为什么”。为什么你会进行这些测试？为什么你会想到这个用例？为什么你选择把这个任务自动化而不是那个任务？为什么我们要投入做这个工具？
我感觉人们有时候做事只是因为看到别人这么做，或者他们测试某个特性的时候只是做那些他们知道怎么做的东西。如果你不问他们为什么，他们自己也不会费心思考这事儿，因为他们已经把那些作为了一种习惯。
HGTS：那什么样的答案算好答案呢？
Ankit：第一，因为它能够提高产品的质量；第二，因为它能提高工程师开发产品的效率。其他答案都没这些重要。
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里富含着创新精神。测试团队也应该被看做创新者。发现重要的问题并能创造性地提出解决方案。
HGTS：你有发现技术团队可能遇到哪些陷阱吗？
Ankit：有的。假设我们知道用户的需求，然后进行了大规模的改动或编写了大量的代码提供新特性，却没有进行小规模的试验。如果用户不喜欢这些改动，麻烦就大了，而针对这些特性构造的测试框架再好也是浪费。因此，要先为少量用户放出一个版本，获得必要的反馈，然后再为大量的自动化测试进行投资。
另外，试图构造完美的解决方案可能花费太长的时间，到时候市场的发展早已超出你的想象了。应该快速迭代，展现阶段性成果。
最后，就像开车一样，你必须找到测试的离合点。过早编写测试，有可能由于架构的变化导致全部工作作废。若等待太久，则又可能错失测试良机而导致没有充分测试。测试驱动开发是不错的方法。
HGTS：对于个人来说有什么陷阱吗？年轻的测试工程师和测试开发工程师在新项目里会犯哪些错误？
Ankit：是的。他们可能一上来就开始干，不明所以。他们写了很多测试，但忘记思考为什么要写这些测试，怎么让这些测试为整体目标服务。编写测试的时候，他们往往没有意识到他们还要负责维护这些测试。测试开发工程师应该牢记测试应该是开发人员的工作而他们自己应该专心让测试成为开发人员工作中的一环。我们通过编写工具帮助开发人员做到这点，而且应该让开发人员在维护开发代码的同时也负责维护测试代码。这样一来，测试开发工程师才能集中精力让测试执行得更快，更容易分析。
测试工程师有时候会迷失方向，做起测试开发工程师的工作。我们希望测试工程师更全局地看待整个系统，全面地掌控整个产品。他们的重点应该是从最终用户角度考虑的测试，帮助测试开发工程师和开发工程师确保所有的测试和底层测试框架都被正确有效地使用。测试工程师编写的工具和对问题的诊断应该能够影响整个产品。
HGTS：除了你前面提到的性能方面的自动化测试以外，还有什么测试方面的工作让Gmail获得了巨大的收益吗？
Ankit：JavaScript自动化测试。我们为Gmail本身加入了一个用于自动化测试的servlet。通过它，开发人员就可以使用与前端开发一致的编程语言编写端到端的测试（译注：端到端的测试是指涉及整个应用系统环境，在现实世界使用时的情形模拟的测试。）。因为它使用很多相同的函数和程序库，开发人员对于如何编写测试代码很熟悉，没有学习曲线。他们可以很容易地写出一些测试，来检验他们的新代码是否影响了Gmail的正常功能，也能够更好地保护他们开发的特性不被其他开发人员破坏。现在，Gmail的每个新特性都至少会有一个通过这个servlet编写的测试。最棒的是，在我现在负责的社交产品里面我也在用这个方法。我们已经有了大约两万个自动化测试！
还有压力测试。在Google你不做压力测试不可能蒙混过关，因为我们的所有应用都有大量的用户，后台数据中心的负载会非常大。我们基本上必须复制一份线上环境并引入真实用户流量。我们花费了几个月的时间分析线上系统的使用情况，构建了一个代表用户的使用模型。接下来，为了数据更为真实，我们使用和真实的Gmail数据中心一样的机器来运行我们的压力测试。然后，我们观察测试环境和被监控的真实环境上的结果差异。我们发现了很多性能退化的问题，并帮助开发人员细化和定位了这些问题。
最后，我们更专注于预防bug而不是检测bug，这为我们带来了巨大收益。我们推动自动化测试在代码提交之前更早地执行，避免了大量质量不佳的代码污染项目。这让测试团队随时保持在最前沿，支持项目产出高质量的版本。这也给我们的探索式测试人员提出了更大的挑战。
HGTS：在选用人才方面你已经很有经验了。你现在转到社交产品项目上，你的测试团队需要找什么样的人呢？
Ankit：我需要寻找那些不会沉迷于系统的复杂性、遇到困难的问题时能够分解为可执行的步骤并能最终解决的人。我需要有执行力的人，他们会被紧迫感激发而不是吓跑。我需要能够在创新和质量中掌握平衡的人，他们不应该只满足于发现更多的bug。但最重要的是，我需要能看到他们的激情。我需要那些真正想做测试的人。
HGTS：这也是我们最后一个问题。在测试领域什么东西会引发你的激情呢？
Ankit：我喜欢由快速迭代和高质量带来的挑战。这两者相互矛盾但又都很重要。这个经典的矛盾迫使我为这两个目标不断优化，而又不会伤害我自己或我的团队。创建一个产品不难，但要快速创建一个高质量的产品会有相当大的难度，而这正是使我的工作——富于挑战又充满乐趣。