关于测试:6种测试组织模式你看好哪一种-IDCF

39次阅读

共计 2262 个字符,预计需要花费 6 分钟才能阅读完成。

最近风行“三问”。对于测试团队来说,也能够有三个问题,测试团队是如何建设和倒退起来的?当前又会向何种模式倒退?最终会沦亡么?

本文尝试梳理在企业倒退过程中可能存在的各种测试资源的组织模式,并认为“无测试”是测试组织对内职责倒退的高级状态,而测试组织对外提供服务,成为“前台部门”的这种“第三方模式”是另一种高级状态。

一、集中模式

这是一种线性倒退的模式。随着公司从初创到发展壮大,测试人员也从无到有,再壮大成立测试小组,并一路倒退成为测试部门,而后在外部持续分化出不同的职能分工。

通常存在一个对立的测试部门或者测试中心,负责整个公司层面或者业务 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》的形容,进入这个阶段的团队,基本上是这样的一种模式。

  • 团队负责微服务整个生命周期。
  • 团队领有一大笔 Old Money, 既一套笼罩较为全面的自动化测试用例。
  • 新增个性 / 代码失去了较为充沛的测试,当然这些测试都是团队中的开发人员做的,也就是通过代码实现的。

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

起源:软件测试那些事
申明:文章取得作者受权在 IDCF 社区公众号(devopshub)转发。优质内容共享给思否平台的技术伙伴,如原作者有其余思考请分割小编删除,致谢。

5 月每周四晚 8 点,【冬哥有话说】品质与测试专场。公众号留言“品质”可获取地址

  • 0506 朱少民《如何最大化软件测试效力》
  • 0513 陈琦《数据驱动测试》
  • 0520 陈霁《没错,去 QA 是提高质量最无效的办法!》
  • 0527 施慧斌《DevOps 实际之继续测试》
正文完
 0