1.3 组织结构
在我过去曾经工作过的多数组织中，开发人员和测试人员都一起隶属于同一个工程产品团队。从组织架构上讲，开发人员和测试人员汇报给同一个产品团队的管理者。这样看起来，同一个产品、同一个团队、所有参与的人都在一起，应该可以做到平等相处、患难与共。
但不幸的是，我还从来没见过有团队能真正做到这样。资深管理者一般都是产品经理或开发经理，而不是来自于测试团队。在产品发布时，优先考虑的是功能是否完整和易用性方面是否足够简单，却很少考虑质量问题。作为同一个团队，测试总是在为开发让路。为何我们这个行业里总是充斥着各种有缺陷的、早产的产品，或许这就是问题所在。不行就再发布一个补丁包。
注意 资深管理者一般是产品经理或开发经理，而不是来自于测试团队。在产品发布时，优先考虑的是功能是否完整和易用性方面是否足够简单，却很少考虑质量。作为同一个团队，测试总是在为开发让路。
Google的组织汇报架构被划分为不同的专注领域（Focus Areas）。这些专注领域包括客户端（Chrome、Google工具栏等）、地理（地图、Google Earth等）、广告、Apps、移动，等等。所有的开发工程师汇报给这些专注领域的管理者、总监或副总裁。
但SET和TE并没有遵循这个模式。测试是独立存在的部门，是与专注领域部门平行的部门（横跨各个产品专注领域），我们称之为工程生产力团队。测试人员基本上以租借的方式进入到产品团队，去做提高质量相关的事情，寻找一些测试不足的地方，或者公开一些不可接受的缺陷率数据。由于测试人员并不是直接向产品团队进行汇报，因此我们并不是简单地被告之某个项目急需发布就可以通过测试。我们有自己选择决定的优先级，在可靠性、安全性等问题上都不会妥协，除非碰到更重要的事情。如果开发团队想要我们在测试上放他们一马，他们必须事先和我们协商，但一般情况下都会被拒绝。
这样的组织结构也可以帮助我们保持数量较少的测试人员。一个产品团队不能任意降低测试人员招聘的技术要求，从而雇佣更多的测试人员，然后再让他们做一些简单和琐碎的脏活累活。这些功能相关的脏活累活本应是开发人员的工作，不能简单地扔给倒霉的测试人员。工程生产力团队会根据不同产品团队的优先级、复杂度和其他产品的实际比较后，再来分配测试人员。显然，有时候我们可能搞错，实际上也确实出过错，但总体上来说，这样会保持实际的需求与不明确的需求之间的某种平衡。
注意 工程生产力团队会根据不同产品团队的优先级、复杂度和其他产品的实际比较后，再来分配测试人员。显然，有时候我们可能搞错，实际上也确实出过错，但总体上来说，这样会保持实际的需求与不明确的需求之间的某种平衡。
这种测试人员在不同项目之间的借调模式，可以让SET和TE时刻保持新鲜感并且总是很忙碌，另外还能保证一个好的测试想法可以快速在公司内部蔓延。一个在Geo产品上运用很好的测试技术或工具，很有可能在Chrome产品中也得到使用。推广测试技术方面创新的最佳方式，莫过于把这个创新的发明者直接借调过来。
在Google有一个广泛被接受的做法：对于一个测试人员，如果在某个产品中工作满18个月之后，就可以无理由地自愿转岗到其他产品，当然这个转岗并不是强制的。可以想象一个产品失去优秀测试专家而带来的悲痛，但从整个公司的角度来看，需要保持对各个产品与技术都了解的测试人员的存在。Google的测试工程师在客户端、web、浏览器、移动技术等领域都有所涉猎，可以高效地使用不同的语言和平台。由于Google的产品和服务很大程度上有比较强的集成关联关系，测试人员可以很容易地保持相关的专业技能，并在公司范围内的产品之间自由穿梭。
本文选自《Google软件测试之道》第一章，本站经人民邮电出版社和作者的授权，近期将进行部分章节的连载，敬请期待！
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
相关文章：
