ITPub博客

首页 > 应用开发 > IT综合 > 6种测试组织模式,你看好哪一种? | IDCF

6种测试组织模式,你看好哪一种? | IDCF

IT综合 作者:DevOps订阅号 时间:2021-05-20 09:23:40 1 删除 编辑


来源:软件测试那些事

最近流行“三问”。对于测试团队来说,也可以有三个问题,测试团队是如何建立和发展起来的?以后又会向何种模式发展?最终会消亡么?
本文尝试梳理在企业发展过程中可能存在的各种测试资源的组织形式,并认为“无测试”是测试组织对内职责发展的高级形态,测试组织对外提供服务,成为“前台部门”的这种“第三方模式”是另一种高级形态。

一、集中模式



这是一种线性发展的模式。随着公司从初创到发展壮大,测试人员也从无到有,再壮大成立测试小组,并一路发展成为测试部门,然后在内部继续分化出不同的职能分工。
通常存在一个统一的测试部门或者测试中心,负责整个公司层面或者业务BU层面的测试和质量相关的工作。在一些大型的测试组织中,进而会进一步派生出功能测试、自动化测试、性能测试、安全测试等专项的测试团队,以及流程与质量控制等角色。
可以说在进入互联网时代之前,这种集中模式是一种主流的测试资源组织模式。这种模式可以高效地利用测试资源,对测试人员的专业性发展也提供了深度。在一些处于强监管的金融行业,强调职责之间的隔离,也通常采用这种形式。

二、分散制



这在一线的互联网公司以及拥有多条产品线的传统IT公司非常常见。随着公司成为一个集团公司,跨入众多的行业和领域,集中式的研发团队甚至也不再是一个选项。IT资源被分散到各个BU,而相应的,测试团队也伴随着IT团队进入业务BU,互相独立决策和独立管理,彼此之间互不隶属,不再有一个统一的集团总部,来统一领导这些测试组织。
可能有些公司还会设置顾问角色或者建立松散的俱乐部等实现跨BU或者部门之间的测试流程、质量标准等通用性测试基础设施的协同。

三、混合模式



从IT治理的角度,集中和分散两种模式都存在一定的局限性。过于集中导致IT作为一种治理手段,没能发挥应有的作用(silo,仓桶),而过于分散的后果往往是对IT的控制力度不够,产生各种成本和安全的问题。
因此也有很多企业选择了集中与分散相结合的测试组织结构,即存在一个集中的测试团队,来负责产品或者产品线的整体交付质量,包括测试基础设施的建设以及各类型专项测试甚至用户验收测试的实施。而分散的测试资源往往是存在于各个开发团队内部,更为主动地融入团队,提供更为及时有效的质量沟通和反馈。似乎走上了一条资源共享、统一规划、紧密结合的道路。
另外一种典型的是很多采取项目制的公司,集中式测试组织成为一个测试资源池,为项目团队不断地培养和输出测试资源,提供培训和指导。

四、第三方模式



在某些大型集团,会将其部分测试职能以外包或者内包的形式转移到第三方,从而能够利用第三方的资源,更好地解决企业内部面临的测试与质量的需求。
采用外包模式的关键是企业和第三方需要签订相关的服务水平协议(SLA),一些常规而又需要一定专业技能和基础设施的项目,如安全测试、性能、App测试等,可以由专业第三方公司提供支持服务。
而一些集团公司为了降低每个分支机构的成本、集中优势人力资源,会成立卓越测试中心(TCOE),共同为各分支机构提供服务,其定位相当于是内部乙方,各分支机构按照服务工作量结算或者虚拟结算。而这样的测试中心如果再往前走一步,就是单独公司化运作,即可以为企业内部提供全面的测试和质量服务,又为外部客户提供服务。进而从一个公司的技术后台部门走向前台,成为一个“业务”部门。

五、“去测试”模式



敏捷宣言给IT业界带来了新的思维,一时风头无二,对测试团队也带来了非常大的冲击。《Agile Testing 敏捷测试》和《How Google Test》相继问世后,一种“新”的测试组织结构被很多公司采用,既所谓的“去测试”风潮,后者在书中宣称,“测试经理是一个没有前途的职业”。很多,实施“敏捷”的公司,拆散了统一的测试团队,将测试人员并入开发团队,与开发人员一样汇报给相同的管理者,譬如开发组长或者项目经理。
这种模式一度非常流行,不少公司辞退了测试总监/经理,或者让其转型带来敏捷团队,成为一线领导者。《How Google Test》甚至在书中宣称,“测试经理是一个没有前途的职业”。实施敏捷最终演变成了“去测试管理岗位”,对于一线测试员工来说,只是换了一个团队和汇报对象,其工作内容并没有发生实质性改变。
这种模式的优势,是开发和测试人员在同一个团队工作,沟通合作会顺畅很多。少了跨团队/部门的测试交接,对于产品交付来说也会更加顺畅。当然,通过笔者的观察,这种测试进入团队的模式是一种很容易被打破的非平衡态。那些在这种非稳态下成功转型的团队,会进入下一个阶段。

六、“无测试”模式



根据《How Google Test》的描述,进入这个阶段的团队,基本上是这样的一种模式。

  1. 团队负责微服务整个生命周期。
  2. 团队拥有一大笔Old Money,既一套覆盖较为全面的自动化测试用例。
  3. 新增特性/代码得到了较为充分的测试,当然这些测试都是团队中的开发人员做的,也就是通过代码实现的。

综合起来就是说,团队成员中不再有全职的测试人员,但是人人都在做测试。质量意识成为了大家的一种职业习惯,也体现在一个个活的测试用例中。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31558019/viewspace-2773047/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-10-12

  • 博文量
    64
  • 访问量
    46986