软件测试管理与组织结构

软件测试管理与组织结构

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

　　《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）无论选取上述的哪一种，甚或是第三种、第四种，组织结构都不是一成不变的。实际上，有的组织会经常在这两种组织结构形式之间来回变换，以适应不同的历史形势。