《Google软件测试之道》—第1章1.3节组织结构

本节书摘来自异步社区《Google软件测试之道》一书中的第1章1.3节组织结构,作者【美】James Whittaker , Jason Arbon , Jeff Carollo,更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.3 组织结构
在我过去曾经工作过的多数组织中,开发人员和测试人员都一起隶属于同一个工程产品团队。从组织架构上讲,开发人员和测试人员汇报给同一个产品团队的管理者。这样看起来,同一个产品、同一个团队、所有参与的人都在一起,应该可以做到平等相处、患难与共。

但不幸的是,我还从来没见过有团队能真正做到这样。资深管理者一般都来自产品经理或开发经理,而不是来自于测试团队。在产品发布时,优先考虑的是功能的完备性和易用性方面是否足够简单,却很少考虑质量问题。作为同一个团队,测试总是在为开发让路。为何我们这个行业里总是充斥着各种有缺陷的、早产的产品,或许这就是问题所在。质量不行就再发布一个补丁包。

注意

资深管理者一般都来自产品经理或开发经理,而不是来自于测试团队。在产品发布时,优先考虑的是功能是否完整和易用性方面是否足够简单,却很少考虑质量。作为同一个团队,测试总是在为开发让路。
Google的组织汇报关系被划分为不同的专注领域(Focus Areas)。这些专注领域包括客户端(Chrome、Google工具栏等)、地理(地图、Google Earth等)、广告、Apps、移动,等等。所有的开发工程师都汇报给这些专注领域的管理者、总监或副总裁。

但SET和TE并没有遵循这个模式。测试是独立存在的部门,是与专注领域部门平行的部门(横跨各个产品专注领域),我们称为工程生产力团队。测试人员基本上以租借的方式进入产品团队,去做提高质量相关的事情,寻找一些测试不足的地方,或者公开一些不可接受的缺陷率数据。由于测试人员并不是直接向产品团队进行汇报,因此我们并不是简单地被告之某个项目急需发布就可以通过测试。我们有自己选择决定的优先级,在可靠性、安全性等问题上都不会妥协,除非碰到更重要的事情。如果开发团队想要我们在测试上放他们一马,他们必须事先和我们协商,但一般情况下也都会被拒绝。

这样的组织结构也可以帮助我们保持数量较少的测试人员。一个产品团队不能任意降低测试人员招聘的技术要求,从而雇佣更多的测试人员,然后再让他们做一些简单和琐碎的脏活累活。这些功能相关的脏活累活本应是开发人员的工作,不能简单地扔给倒霉的测试人员。工程生产力团队会根据不同产品团队的优先级、复杂度,并与其他产品实际比较之后,再来分配测试人员。显然,有时候我们可能搞错,实际上也确实出过错,但总体来说,这样会保持实际的需求与不明确的需求之间的某种平衡。

注意

工程生产力团队会根据不同产品团队的优先级、复杂度,并与其他产品实际比较之后,再来分配测试人员。显然,有时候我们可能搞错,实际上也确实出过错,但总体上来说,这样会保持实际的需求与不明确的需求之间的某种平衡。
这种测试人员在不同项目之间的借调模式,可以让SET和TE时刻保持新鲜感并且总是很忙碌,另外还能保证一个好的测试想法可以快速在公司内部蔓延。一个在Geo产品上运用很好的测试技术或工具,很有可能在Chrome产品中也得到使用。推广测试技术方面创新的最佳方式,莫过于把这个创新的发明者直接借调过来。

在Google有一个广泛被接受的做法:对于一个测试人员,如果在某个产品中工作满18个月之后,就可以无理由地自愿转岗到其他产品,当然这个转岗并不是强制的。可以想象一个产品失去优秀测试专家而带来的悲痛,但从整个公司的角度来看,需要保持对各个产品与技术都了解的测试人员的存在。Google的测试工程师在客户端、Web、浏览器、移动技术等领域都有所涉猎,可以高效地使用不同的语言和平台。由于Google的产品和服务很大程度上有比较强的集成关联关系,测试人员可以很容易地保持相关的专业技能,并在公司范围内的产品之间*穿梭。

上一篇:【RecyclerView】 七、RecyclerView.ItemDecoration 条目装饰 ( getItemOffsets 边距设置 )


下一篇:批量Linux 网络安装环境建立工具cobbler/kickstart