随着CMMI3的推进，测试组的分工越来越明确，开发方的文档质量越来越高。终于带来了负面效果－－测试出的BUG极少，但上线后BUG却仍然存在，很多BUG根本没有测试出来，另外test leader这个位于腰部的关键人物，越来越体现不出应有的作用。目前的工作体系是这样的：

        下面先来来说说，测试不出BUG的问题：

        对于测试不出BUG的原因，问题的关键在于，开发方提供的需求实在是很“完美”，用看图说话的形势，把所有的测试点都给写了出来，包含了几乎全部路径。测试人员那到这样一个文档，做起来十分轻松，但同时也被限制在这个文档的行程的一个圈里，无法发挥发散性思维，使得测试变的不全面。在正式测试之前，程序员会根据需求文档自测，然后在提交。也就是说，文档里提到的测试点，程序员自己都测试过，拿到测试组这边，只不过是在重复程序员的测试，使得这样的测试变得毫无价值可言。目前来说，如果想解决这个问题，我认为如果让test leader同时参与需求调研，重新确定测试范围，这种方法未必有效果。原因有以下几点：1.test leader本身并不熟悉所有系统业务，也不太可能熟悉所有系统业务，在这种情况下去参与调研，怕是很难明确问题所在，确定下的测试范围会不准确。2.test leader本身并不参加测试，这一个人对需求理解的在透彻，也不可能手把手去带着测试员去完成任务，把范围划出来，给下面的人员执行起来效果如何，还很难说。

        我始终认为，测试做的好与不好，关键在于对测试的认识，对项目的认识和做事的态度。目前给我的感觉就是，SRS里写上的东西就测，一些其他的旁支末节的东西，看到了也不会去测，完成分内事而已。当初一直抱怨SRS写的不好，测试不到，现在看来，写的不好，到不如写的好。文档不清楚，会导致测试员不停的去研究究竟是怎么回事，去和开发沟通确认很多细节，而这些细节，就是非常关键的东西，在文档写的不是很好的情况下，很多细节都是测试员自己想象出来的。而现在在文档十分清晰的情况下，测试员丧失了这种思维，固定在这些界面操作上，思维被文档所诱导，实在是很悲哀又很有意思的一件事情。

        我老觉得管理层都把下面的人给惯坏了，好像太重视每一个人的得失。就一个团队而言，我始终认为是以公司利益为首，完成任务，保证质量是第一；什么个人发展啊之类，从公司管理层面不客气的说，那是次要的。虽然团队整体的综合实力需要提高，但是那也是在有这样一个需求的情况下，由管理层有目的的培养个别人而产生的。如果公司根本不需要做性能测试，我要底下的人学什么LOADRUNNER啊，纯粹浪费时间。

        现在组里没有什么朝气，原因可能有这么几个：1.工作重复太无聊；2.领导对他们太客气；3.压力不大；4.综合因素导致他们个人思想占主导地位，安排的任务喜欢做就做，不喜欢做就拖。5.综合实力不高，导致对未来发展不明，外加人的天生惰性，导致比较懒散，一个带一个，搞的基本都是无精打采。

        造成这种情况不是一朝一夕，想改变也不是一时半会。我自己自恃也没那么强的能力，带动所有人改变，这个牵涉的因素太多，有的我无权决定，有的是人的基本思想观念问题，想改变很难。目前李凯辉的积极性很高，不过如果整体大环境不改变，这种积极性也会慢慢的泯灭。良好的局面不是单靠几个人的努力就可以形成，有一个良性循环很难，寻求一个公司利益与个人发展共进步的局面也很难。人总是要靠自己，想自己良好的发展，必须自己积极，而不是靠别人来安排你，让你取的进步。

        就需求这点来看，目前我也没想出什么更好的方法去改变现状，可以先按调研的方法去尝试一下。

        在来说说这个组织架构的问题。

        从整体项目流程来说，提交测试后，基本都会交付组长负责处理，test leader 本身不会接触到项目具体的事宜，这样就导致了很多问题都是组长直接去和开发那边处理，这个腰部的位置，其实是一个累赘。从职责上来说，目前leader其实扮演着测试经理的角色，而组长是leader的角色。而这个四层体系的最高层有一个相当于高级经理的人，而这个人才是对整个项目有决定权的人。这个概念等于就是一个项目经理上面有一个高级经理，而项目经理没权利去决定项目本身的一些事宜，组员有时有的事情也不像项目经理汇报，而是向高级经理汇报，形成一个混乱的管理局面。目前组内差不多就是这样，好像职责不清的感觉，有些事情，经理知道leader不知道，有些leader知道而组长不知道，对某些问题处理起来就没那么顺畅。

        目前基于这种四层体系，我也不清楚处于腰部，应该做些什么，哪些应该我做，哪些应该组长做，而长此以往，我自己的进步也是微乎其微。

        就管理本身而言，我觉得强硬的作风并不是不可取，软硬兼施才是合适的谋略。对做的有问题的人要严厉处罚，对做的杰出的人要给予奖励。不过说到底，不管是组长还是leader，都没有相应的权利，今天除了测试经理站出来要这样那样，组里人会听听外之外，如果要把我们的管理理念和方法应用到他们身上，怕是没人搭理我们。给我感触很深的就是，号召大家去开会的时候，不管是经理号召还是我号召，一个个都慢慢吞吞，慢条斯理的过来，这种小事就直接反映了目前的状况和问题。XWL的管理作风之所以吃的开，很大原因是因为他有权直接处理一些事，而并不是他人格魅力有多高。

        公司在逐渐改变，高层对这个组的支持程度也是十分关键，就目前来看，不管是抽调人手还是对培训的态度，感觉都满随意的，所以给我感觉就不太好。可能有些事情大家都看在眼里，所以积极性就会比较低。

        这其实是一个恶性的循环，就我本身而言，对没什么积极性的人，我更没积极性去督促帮助他们进步。我觉得其实团队本身并不是十分稳定，包括人员，制度，职责，能力，配比，测试质量等等，在这样的情况下，应该先稳稳，在寻求更进一步的发展。

        大致先写这么多，对团队发展起到影响的因素很多，我的感觉有两句话说的很好： 1.世上不存在完美。 2. 细节决定成败。关于组织架构方面，不知道想法是不是正确，如果这种架构不变，腰部这个关键点的职责又是什么?