小编：所以经验就是解决掉一些难题来赢得尊重。我喜欢这点。不过做完这些之后你还做了什么？
Ankit：其实，难题永远也解决不完！不过你说的对，基本思路就是关注最重要的事。我们确定Gmail最紧要的问题，然后一起解决它们。通过团队配合，你会发现这些问题并不那么困难。当然，我还是坚信只应该关注最重要的事情。每当我发现团队打算做太多的东西的时候，就好像你要同时做五件事情，但是每件只能完成80%的时候，我就会要求他们退回来重新安排优先级。把你需要做的事情减少到两到三件，但都能完成到100%。这样团队才能获得真正的成就感，而不是好多事情在他们手里没有完成。如果这些工作最后都能积极地影响到产品质量，那么我也会感到特别高兴。
小编：大家都知道Google的每个经理都有很多直接下属，而且经理自己还需要从技术上有所贡献。你怎么平衡这些事情？能告诉我们你自己是怎么完成那些技术工作的吗？
Ankit：管理下属和与其他人沟通确实是一种干扰。我其实总结了两个办法来让自己能保持技术敏锐度并像工程师一样参与其中。
第一，在与开发工程师和测试开发工程师团队沟通的过程中，有好多事情可以做，我可以选择留下一部分自己来完成。我在设计阶段会积极地参与，持续地跟进项目并且自己也编写测试。
第二，其实这才是关键的部分。如果你想做一些技术工作，就必须尽量排除管理方面带来的干扰。起先，我每周都花一两天的时间做我自己的工作。我有一个项目是把Google Feedback整合到Gmail里，这个工作让我能从开发的角度来看待测试。当我碰到一个脆弱的测试，或者测试架构的某些部分拖慢了我的测试进度时，我就能够理解那些全职的开发工程师怎么看待我们的测试工作了。尽管如此，只要我在Google总部的办公室，人们总能想办法找到我，所以我就跑到苏黎世Gmail团队的办公室去。虽然在那儿有九个小时的时差，但是环境就安静多了，我在那里也不是谁的经理。我可以混进一个技术团队而不怎么引人注目。我在苏黎世干了好多活儿！
小编：你对测试项目的人员配备有什么建议吗？开发测试比是多少会比较好？SET和TE的比例呢？
Ankit：人员的问题其实很简单，那就是绝不妥协。选用不合适的人来填充名额永远要比等待合适的人员要糟糕。只选用最好的人，不能动摇。Google不让公布人员比例数据，不过以前我们团队中测试人员的比例比正常水平高很多。自从我们解决了很多最初的问题，并得到开发工程师的支持以后，我们的比例就降到和Google的标准水平差不多了。从技能分配的角度来说，Gmail的经验是用20%的测试人员进行探索式测试。任何关注用户体验的产品都需要探索式测试。还有30%的测试工程师关注于产品的整体性测试，他们和测试开发工程师一起来保证测试的效果。另外50%的工作，是测试开发工程师开发相关的自动化测试和工具，以保持代码库的健壮和提高开发人员的工作效率。我不敢说我在下一个项目还会按照这样的比例分配，但是这个比例对Gmail来说是有效的。
小编：我知道你现在开始负责Google+的测试了。在新项目中你发现哪些在Gmail的经验是最有价值的？
Ankit：首先，不要把你所有的精力都放到前端。Gmail拥有可能是最庞大的分布式后台系统，那里还有很多的测试问题我们尚未解决。除此之外，还有很多经验教训值得吸取：
— 使用与应用程序开发语言相同的编程语言来编写测试。
— 让负责开发新特性的人同时负责相应测试的执行，他需要对漏掉的测试负责。
— 关注测试基础设施的建设，让测试的编写和执行非常容易，甚至比忽略它们还要容易。
— 20%的用例覆盖了80%的使用场景（可能会有些出入）。把这20%自动化而别管剩下的。把那些测试通过手工完成。
— 这里是Google，速度才是王道。如果用户只在乎一件事，那就是速度。确保我们的产品足够快。进行性能分析以便于可以证明给所有人看。
— 与开发团队的沟通至关重要。如果这点做的不好，你就会疲于应付，那可不是什么好事。
— Google的DNA里富含着创新精神。测试团队也应该被看做创新者。发现重要的问题并能创造性地提出解决方案。
小编：你有发现技术团队可能遇到哪些陷阱吗？
Ankit：有的。假设我们知道用户的需求，然后进行了大规模的改动或编写了大量的代码提供新特性，却没有进行小规模的试验。如果用户不喜欢这些改动，麻烦就大了，而针对这些特性构造的测试框架再好也是浪费。因此，要先为少量用户放出一个版本，获得必要的反馈，然后再为大量的自动化测试进行投资。
另外，试图构造完美的解决方案可能花费太长的时间，到时候市场的发展早已超出你的想象了。应该快速迭代，展现阶段性成果。
最后，就像开车一样，你必须找到测试的离合点。过早编写测试，有可能由于架构的变化导致全部工作作废。若等待太久，则又可能错失测试良机而导致没有充分测试。测试驱动开发是不错的方法。
小编：对于个人来说有什么陷阱吗？年轻的测试工程师和测试开发工程师在新项目里会犯哪些错误？
Ankit：是的。他们可能一上来就开始干，不明所以。他们写了很多测试，但忘记思考为什么要写这些测试，怎么让这些测试为整体目标服务。编写测试的时候，他们往往没有意识到他们还要负责维护这些测试。测试开发工程师应该牢记测试应该是开发人员的工作而他们自己应该专心让测试成为开发人员工作中的一环。我们通过编写工具帮助开发人员做到这点，而且应该让开发人员在维护开发代码的同时也负责维护测试代码。这样一来，测试开发工程师才能集中精力让测试执行得更快，更容易分析。
测试工程师有时候会迷失方向，做起测试开发工程师的工作。我们希望测试工程师更全局地看待整个系统，全面地掌控整个产品。他们的重点应该是从最终用户角度考虑的测试，帮助测试开发工程师和开发工程师确保所有的测试和底层测试框架都被正确有效地使用。测试工程师编写的工具和对问题的诊断应该能够影响整个产品。
小编：除了你前面提到的性能方面的自动化测试以外，还有什么测试方面的工作让Gmail获得了巨大的收益吗？
Ankit：JavaScript自动化测试。我们为Gmail本身加入了一个用于自动化测试的servlet。通过它，开发人员就可以使用与前端开发一致的编程语言编写端到端的测试（译注：端到端的测试是指涉及整个应用系统环境，在现实世界使用时的情形模拟的测试。）。因为它使用很多相同的函数和程序库，开发人员对于如何编写测试代码很熟悉，没有学习曲线。他们可以很容易地写出一些测试，来检验他们的新代码是否影响了Gmail的正常功能，也能够更好地保护他们开发的特性不被其他开发人员破坏。现在，Gmail的每个新特性都至少会有一个通过这个servlet编写的测试。最棒的是，在我现在负责的社交产品里面我也在用这个方法。我们已经有了大约两万个自动化测试！
还有压力测试。在Google你不做压力测试不可能蒙混过关，因为我们的所有应用都有大量的用户，后台数据中心的负载会非常大。我们基本上必须复制一份线上环境并引入真实用户流量。我们花费了几个月的时间分析线上系统的使用情况，构建了一个代表用户的使用模型。接下来，为了数据更为真实，我们使用和真实的Gmail数据中心一样的机器来运行我们的压力测试。然后，我们观察测试环境和被监控的真实环境上的结果差异。我们发现了很多性能退化的问题，并帮助开发人员细化和定位了这些问题。
最后，我们更专注于预防bug而不是检测bug，这为我们带来了巨大收益。我们推动自动化测试在代码提交之前更早地执行，避免了大量质量不佳的代码污染项目。这让测试团队随时保持在最前沿，支持项目产出高质量的版本。这也给我们的探索式测试人员提出了更大的挑战。
小编：在选用人才方面你已经很有经验了。你现在转到社交产品项目上，你的测试团队需要找什么样的人呢？
Ankit：我需要寻找那些不会沉迷于系统的复杂性、遇到困难的问题时能够分解为可执行的步骤并能最终解决的人。我需要有执行力的人，他们会被紧迫感激发而不是吓跑。我需要能够在创新和质量中掌握平衡的人，他们不应该只满足于发现更多的bug。但最重要的是，我需要能看到他们的激情。我需要那些真正想做测试的人。
小编：这也是我们最后一个问题。在测试领域什么东西会引发你的激情呢？
Ankit：我喜欢由快速迭代和高质量带来的挑战。这两者相互矛盾但又都很重要。这个经典的矛盾迫使我为这两个目标不断优化，而又不会伤害我自己或我的团队。创建一个产品不难，但要快速创建一个高质量的产品会有相当大的难度，而这正是使我的工作——富于挑战又充满乐趣。
