测试管理和组织结构的关系

一个测试管理者在考虑提升组织的测试能力、进行一系列测试变革时，除了考虑测试技术本身的因素外，还有一项不能忽略，那就是测试的组织结构，今天就来谈谈这个话题。MILY: 'Times New Roman'">

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

而谈到测试的组织结构时，势必要先参考开发的组织结构。一般而言，一个产品会划分为几个模块来实现，开发的组织结构基本上是和模块一一对应的，我们就拿这种典型的情况讨论一下相应的测试组织结构应该如何划分。

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

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

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

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