测试管理与组织结构

一个测试管理者在考虑提升组织的测试能力、进行一系列测试改进时,除了考虑测试技术本身的因素外,还有一项不能忽略,那就是测试的组织结构。

《TPI Next》里面划分测试关键域时,专门单独划分了一个“test organization”的key area,并且定义“A test organization meets the needs of projects for test resources, test products and test services.”,认为测试组织就是关于“the right people expertise and experience at the right place.”的事情。 本文探讨的测试的组织结构只是“test organization”的一部分,重点探讨测试的组织结构如何与开发的组织结构相对应的问题,基本上对应TPI里的controlled level,即“A test organization enables uniformity in test approach, test products and procedures, agreements and clear test results.”

为什么谈测试管理时,要谈测试的组织结构?其实,组织结构在有关测试管理的探讨中有着不可忽视的作用,它体现着管理思想,也反过来对测试管理有辅助的作用,这就像经济基础决定上层建筑一样,测试管理理念达到了什么层次,就会制定相应的测试组织结构,以更好的落实这个理念。实践证明,很多测试过程中出现的问题最后都与组织结构有关系。

而谈到测试的组织结构时,势必要先参考开发的组织结构。对于传统的瀑布开发模式而言,一个系统有可能会划分为几个模块来实现,开发的组织结构基本上是和模块一一对应的,我们就拿这种典型的情况讨论一下相应的测试组织结构应该如何划分。

一个产品的开发可以分解为多个模块来实现,这个产品的某个功能或特性经常需要多个模块配合实现。假如每个模块对应一个开发项目组,测试项目组的划分经常会有两种选择,一是也按照模块划分,二是按照特性划分,一个特性可以跨多个模块。那么二者各有什么优缺点呢?

按照模块划分的测试项目组,由于和开发项目组存在一一对应的关系,二者关系更为紧密,开发人员和测试人员的交流也更为顺畅,会经常一起探讨模块级的细节和实现,有利于在产品开发阶段(发布给测试前)测试人员的前期介入,这种前期介入包含很多方面,例如测试人员对设计文档的评审检视、测试分析与设计的分工合作、测试人员参与的前期代码走读、集成测试等等,更多地测试前期介入的内容可参考这篇blog。因此,按照模块划分的测试组织对模块会进行比较充分的测试,但这种模式也存在一些弊端,比如对于涉及到多个模块的特性,测试人员在测试分析设计和评审检视中往往考虑欠佳,测试人员对整个系统层面的把握不是很到位,同时测试人员和开发人员的过于“亲密”也造成测试无法扮好“黑脸”的角色。

按照特性划分的测试项目组,对上述弊端可以做到较好的规避。但这个时候常常是测试为了避免受开发思路的太多影响,独立彰显测试的价值,从测试设计到测试执行都会另起一套,更多的从测试的角度、从客户的角度考虑问题,更多的站在特性一级、系统一级考虑问题,测试在把系统当作一个黑盒进行系统测试方面越来越擅长,此时的测试管理者如果不注意把握一个“度”的话,就会出现“测试后移”的现象,测试人员把眼光聚焦在后端,致力于问题发现,渐渐的,代码走读、集成测试等前端测试的活动测试做的偏少了,甚至都移交给了开发人员。可是开发人员“天生”的对问题不敏感,其质量难以保证,很多开发人员认为开发人员所做的测试“测不彻底”是很正常的事,反正后面有测试人员做后盾。那么时间长了,这种模式的弊端也会逐渐暴露:纯黑盒的系统测试周期拉得很长,因为缺陷迟迟不能收敛,开发在版本转测试后也疲于奔命修改问题单使得人力迟迟无法释放;如果产品的需求控制不好的话,新需求的不断合入会加剧问题的恶化,新需求将无法得到有效跟踪、设计和验证;很多本应该在UT、IT发现的问题都遗留到了系统测试阶段,测试部为了保证产品的质量,花费大部分时间验证这些前期遗漏的问题,而没有精力站在客户角度、从组网场景、应用场景开展对需求的系统级验证,导致问题在网上频频爆发;而如果测试人员稳定度不高时,测试人员的不断更新,会导致了解系统内部实现的测试人员越来越少,随着产品的快速更新演进(对比较复杂的产品而言),测试人员在系统架构层面的讨论上显得力不从心,等等。

那么究竟应该选择什么样的组织结构才会最大化测试效率呢?答案是没有定论。这要结合开发的组织结构、开发模式、测试人员构成、产品复杂度、需求稳定度、组织的测试经验积累、当前产品的软肋是模块还是系统等因素综合考虑。

但是至少有两点是可以确定的:

1)上述两类典型的测试组织结构无论选取哪一种,都与测试组织的成熟度没有必然的关系;

2)无论选取上述的哪一种,甚或是第三种、第四种,组织结构都不是一成不变的。实际上,有的组织会经常在这两种组织结构形式之间来回变换,以适应不同的历史形势。

 《测试管理与组织结构》有 6 条评论

  1. bob说:

    最近参与一个项目,作为测试前期介入,目前正在进行测试需求分析。准备做完测试需求分析后,在从开发获取特性方案,从而设计测试用例。但是发现,SE的需求有些都还没定,后期很有可能会进行修改,面对这种情况,测试需求应该怎么做比较好,从而更好地应对后面需求的变化?请教邰老师~~~

    回复

    • 邰晓梅说:

      实际上,测试需求分析或者测试方案设计都不是一次性的活动,建议你迭代地、分层次地、由粗到细地开展。
      比如,对于有可能变更的需求部分,你可以先分析到测试条件(或者叫测试规格)这个层面,而不一定要得出最终的测试用例;在RST中有一个更简单的做法,你可以只简单分析得出一些需要测试覆盖的点,叫做PCO(Product Coverage Outline),以及有可能存在问题的风险点(Risk List),后续根据情况再出具测试用例,或者直接开展探索性测试(ET)。
      当然,你能否这么做,与你的上司可能也有点关系,他可能要求你现在必须出具XX个测试用例,后续不会再给你安排测试分析和测试设计的时间。不过我相信,you can find your own way.

      回复

  2. tester说:

    我倾向于按测试特性来构建测试组织,不同于产品特性,测试特性是完全从测试角度来定义的。属于同一测试特性的所有用例具有相近的测试方法和手段,有利于提高测试效率,技术积累等。例如对于一个测试项目,可能有功能组(如果产品特性比较庞大复杂,也可能按产品特性细分为不同的功能组),可靠性组,性能组。同时在整个产品研发阶段,要特别强调不同层级的测试要充分发挥应用的价值,也即邰老师提到的,UT层级的问题一定要在UT 阶段发现,可通过某些缺陷分析方法来改善这一点。

    回复

  3. tester说:

    更正:要特别强调不同层级的测试应充分发挥其应有的价值

    回复

  4. lessing说:

    我们公司目前使用的是基于模块划分的测试,确实存在您所说的问题,特别在流程、接口方面,经常到系统集成后期的交叉测试时才发现模块上下文出现问题。
    但我有一点疑问:
    就是当使用测试特性模型时,难道不会再分模块吗?那么某一位测试人员如何能熟悉整个系统(20+个模块)进行测试呢?基于测试特性模型下还是会分模块的吧?这个细节能说说吗?

    回复

    • 邰晓梅说:

      基于特性划分测试团队,某些情况下,比如集成测试中,测试人员要了解某个特性所涉及的模块和模块间的配合,但不必了解每一个模块的所有细节,而是更关注系统的、特性的、用户的层面。
      一般来说,在这种情况下,为了有效保证模块的质量,最好有一个模块级的架构师,负责拉通考虑模块级的设计和质量。

Comment Box is loading comments...