Ankit Mehta在成为测试工程经理之前是一名测试工程师（TE）。在最初的几年，Ankit Mehta一直在和测试自动化代码打交道。他作为技术经理的第一个大项目正是Gmail。
Gmail是个巨大挑战。它非常庞大，涉及很多快速发展的部分。Gmail整合了很多Google的产品，如Buzz、Docs、Calendar等。它需要处理那些已经站稳脚跟的竞争对手所支持的邮件格式。Gmail有非常庞大的后台系统。要知道Gmail是一个云服务，用户可以通过任意一种主流浏览器进行访问。有数亿用户在使用Gmail，他们希望打开浏览器后Gmail就能工作，这从某种意义上也增加了复杂性。用户需要快速、可靠、安全的服务，并且还能包括自动处理垃圾邮件。增加新特性必须保证之前的功能持续可用，这使得测试任务变得非常复杂。一旦Gmail出现问题，全世界的人就会在第一时间发现。因此，测试工程经理责任重大。
小编对Ankit进行了采访，了解Gmail是如何测试的。
小编：告诉我们你是怎么接手一个新测试项目的吧。你首先会做什么事，问哪些问题？
Ankit：加入一个新项目的头几个星期，我主要用来倾听而不是发表意见。深入理解团队非常重要，要学习产品的架构，了解团队的最新动态。我不能接受一位医生在观察我不到五分钟的时间就给我开具抗生素类的药品。同样的，我也不期望一个测试团队可以接受我一开始就提出的什么解决方案。在进行诊断之前你必须先要学习。
小编：我们和你一起工作过，你可不是那种安静的类型啊。我估计你是不开口则已，一开口就会滔滔不绝，如黄河泛滥般一发而不可收拾!
Ankit：噢，是的！不过我也不会什么都说。多年来，通过不断地聆听，我发现最有力的问题就是“为什么”。为什么你会进行这些测试？为什么你会想到这个用例？为什么你选择把这个任务自动化而不是那个任务？为什么我们要投入做这个工具？
我感觉人们有时候做事只是因为看到别人这么做，或者他们测试某个特性的时候只是做那些他们知道怎么做的东西。如果你不问他们为什么，他们自己也不会费心思考这事儿，因为他们已经把那些作为了一种习惯。
小编：那什么样的答案算好答案呢？
Ankit：第一，因为它能够提高产品的质量；第二，因为它能提高工程师开发产品的效率。其他答案都没这些重要。
小编：Gmail团队注重生产效率是出了名的，所以我理解你会这么说。不过除了质量和效率之外，你对测试工程经理还有什么建议来建立一个健康的工作氛围呢？
Ankit：团队的气氛非常重要。我深信优秀的产品和优秀的测试团队紧密相关。你必须要有拥有合适技能的人，正确的工作态度，并做正确的事情。特别是团队中资深的人，因为团队的文化和氛围很大程度上来源于这些人。拿Gmail来说，我花了三到六个月来建立团队，让团队具有凝聚力，每个人都能理解其他人的角色。当你有了一个好团队，就不会由于一两个人的不适应而出现问题。测试团队和开发团队的关系也是一种非常重要的气氛。当我刚加入的时候，这种气氛并不好。测试团队自顾自的工作，而开发团队也不认可测试团队，这是非常不好的。
小编：你肯定把这个问题解决了，能具体谈谈你是怎么处理的吗？
Ankit：我刚加入Gmail的时候，测试团队只是专注于执行一系列WebDriver的测试，每个版本执行一次。每次执行测试结果都会由绿（成功）变红（失败），然后再花大力气修复这些测试，让他们能够再变绿。开发团队没有过多质疑这种做法，由于这些测试通常还是能发现一些重要问题的，因此这种做法就一直延续下来了。但是曾经有好几回代码变化很大，测试代码根本来不及修改。整个过程非常脆弱，不能适应Gmail的变化。这是一种过度投入，因为要让它最终发挥作用所需的工作太多了。
可能是因为我新加入的这个项目，所以能发现一些其他人不能发现的事情。在我看来处理延迟是Gmail最大的问题。严格来说，从用户的角度来说，Gmail最大的特性就是它的速度。我料想如果我们为开发团队解决了这个问题，我们就能赢得他们的尊重并开始建立平等的关系。
这是个难题。我们必须测试Gmail老版本和新版本速度上的差异，当新版本的速度下降时及时发现。然后我们需要检查所有新版本里改动的代码，并找到速度变慢的原因，从而修复这个问题。这是一个痛苦的过程，非常耗时，并伴随大量的尝试和失败。
我曾经和一位测试开发工程师一起想办法，想让Gmail的速度变慢，以便于我们能更好地观察前端和后台数据中心的通讯，从而发现造成性能下降的原因。我们最后到处找了些旧机器，弄了一大堆512M内存、40GB硬盘和低速CPU的机器。Gmail在这些机器上运行速度慢了很多，我们可以把所需的信号分辨出来，然后开始运行长时间的压力测试。头几个月特别艰苦，我们有几次误报。我们花费了大量的精力搭建基础设施，可没有什么产出。但是后来，回归测试的需求滚滚而来。我们可以测量到毫秒级的性能损耗并把数据记录下来。开发工程师能在几小时内就发现产生延迟的问题，而不是以前的几个星期。这样就可以趁问题刚出现的时候就开始调试，而不像以前得在几个星期以后才能开始。这件事立即为测试团队赢得了尊重，以至于在我们着手开展接下来的重要任务（修复端到端的测试和搭建高效的负载测试平台）时，开发工程师实际上还自发地帮助我们。整个团队发现了高效测试带来的价值。Gmail的发布周期从每三个月缩短到每周，再到每天都能向我们的部分用户发布新的版本。
