原创翻译：James Whittaker系列——Google是如何测试的（1）

原创翻译，请勿转载！！！！

  （注：翻译这部分Blog文章的初衷有两点，第一，这部分blog作为书google测试之道的起源，里面的内容有部分被书中舍弃的；第二，网上很多流传翻译版本，不足以合胃口）     

       此篇Blog是系列文章的开篇。

       我被问得最多的一个问题是“Google是怎么测试的”，接下来我会零零碎碎地回答这个问题，之后也会持续更新。我这一系列的文章，既谈到了我们现在做的，也有我们未来要发展的方向。

      我们先来看看google的组织架构，也许你会大吃一惊。Google并没有专门的测试部门。测试归属于一个称为”工程生产力“（Engineering Productivity，EP）的中心组织部门。这个部门横跨很多研发分支，测试是其中最大的部分。工程生产力由下面的部分组成：
      1、产品团队：负责公司内部使用的和开源工具的开发，包括代码分析工具、IDE、测试用例管理工具、自动化测试工具、编译工具、编译系统、代码版本控制系统、代码评审工具、Bug数据库等。这些工具会让工程师的工作更加的高效。比起用来发现错误，工具在预防错误上更具有战略意义。
      2、服务团队：为上述产品团队开发的各种工具提供最大支持，包括工具、文档、测试、发布管理、培训等等，也涵盖了稳定性、安全性、国际化，同时也给生产团队解决特定产品的功能问题。

      3、注入工程师：它可被外借到Google的产品团队中。有的工程师可能在一个产品团队一待就是好多年，有的工程师会轮换到最需要他们的团队中去。Google鼓励工程师在产品团队中切换，这可以保持工作的新鲜感、浓厚的兴趣和立场的客观。测试人员并没有什么不同，但是切换团队的步调由测试人员自行掌握。比如我所在的Chrome团队，有些工程师待了很多年，有些加入有18个月了。还有些已经离开。如何在产品稳定性与注入新生活力之间保持良好的平衡，是测试经理需要高度关注的点。

     这种测试组织方式就意味着测试人员属于一个产品团队，如搜索引擎、Gmail或Chrome，但却直接向EP经理汇报工作，他们身在产品团队，参与计划、日常工作、分享奖金、被其他团队成员完全当成组员并获得信任。这种汇报模式分离方式的好处，就是给测试人员提供了分享信息的平台。不论测试人员身处哪个产品组，好的测试理念都会很容易在整个EP中推广，并让公司能获得最好的技术。

     这种项目和工作汇报分离的模式，也是有风险的。目前为止，最大的风险就是，测试人员是外部资源。产品团队不能把测试人员放到很重要的位置上，但同时又必须保证产品的高质量。是的，这是正确的：在Google，产品团队对产品质量全权负责，而不是测试人员。每一个开发人员都被希望能进行自我测试。而测试人员的工作是确保产品团队有自动测试框架，并能实施下去。测试人员就是“驱动开发人员来测试的”。

   

     我喜欢这种研发模式，它能把开发和测试人员放到平等的位置上，让整个团队在产品质量保证方面站在了同一战线上。另一个好处就是，它让开发与测试比例，为多对一。开发人员多于测试人员，在测试方面，他们就会做得更好。产品团队应该为这种高比例而自豪！

    

     我想你们已经发现了这种模式的一个漏洞。开发人员是不能测试的！是的，我能否认这个吗？

     Google对这一问题的解决方法是，分离角色。在Google，我们有不同类型的测试角色，这是我下一节要谈到的内容。