测试体系规范推行有多难？-Zee

原文请见：http://www.7dtest.com/bbs

这几天在考虑这么一个问题，就是测试被慢慢的认可了之后，为什么测试的价值还得不到体现？为什么测试体系还是得不到广泛的推广？以下是我个人的一些分析。

１.  测试体系的整体概念

　　一直以来，我都觉得这个问题挺概念的。就是说了后让人抓不住重点的感觉。要说某个具体的技术细节，很明确。比如，要说weblogic的调优，可能会有人很快联想到：连接池、jvm、线程数等等。但是测试体系是什么？有点虚。在多次听测试人员的报怨之后，我觉得现在的规范可能是影响测试体系建设的第一要素。而在这个具体的技术要素之前，需要的就是领导是不是强力支持的。先说测试规范，下面再说其他因素的影响。首先，把软件测试和质量保证分开来，尽管现在大部分的公司把测试人员叫做QA工程师，尽管这一叫法是错的（个人认为是错的），还是被一些人屁颠屁颠接受并推广去了。好吧，这些概念性的问题，我们先不认真的追究了。测试体系在我的意识里是：为了尽可能找到系统的缺陷的和评估系统，对应测试需求，使用相应的管理方式，按照流程和方法进行系列的测试动作，并最终产生符合规范的测试产品的过程描述。在这一过程中，有几个词是要体现在测试体系里的，就是：管理、流程、规范、方法。要推广测试体系，首先要求的个人素质就是要有整体的体系概念。这样说起来好像有点太正式了，有点累。换个角度说，现在有没有太多的人有测试体系的整体概念？如果有，知道不知道，自己在这个体系中处在什么位置？职责是什么？曾经看到一些公司和人生套ＣＭＭＩ、ＲＵＰ、ＩＳＯ之类的（这几套东西的角度是不一样的），但是由于推广的方式太生硬而导致人的意识转换不过来。最后不了了之。尽管过了什么认证，也是推倒重来，恢复旧制。理由很简单：这些体系不适合我们，还是我们自己体系比较清楚。针对测试体系也同样如此。精髓没有领会到，就生套，是不可能推广开的。记得有人说，进一家公司是一个“固化-僵化-优化”的过程。而我觉得大部分人连固化还没走出第一步，就觉得回头才是岸了。

２.  利润驱动的影响

无可厚非，利润永远是公司的第一要务。在很多时候，我们不得不为利润让路。就是因为一直是这样，才导致了我们的测试体系是不可能建立起来的。我们只能绕着客户转。最近大领导组织开了一个会，就是建立一套完整的测试体系，在这个体系的各个部分，都有相应的文档来支持。最后我画了一个大概的思维框架图，包括的内容广泛，每个职位上的人在什么样的阶段，按照什么流程和规范，做什么样的事情，做成什么样子，等等。都有相关的模块来维护其完整性。领导一看，觉得不错。最后，就提到如何落地。在参考了很多意见之后，落实成为一种可以按时间推移而实行的方法。做事是需要时间的，而在某些时候，一个人要兼顾好几个事情的时候，就不得不为与客户有关的事情让路。自从年后，我画了一个小范围内的ＰＤＣＡ流程图之后，就开始为客户的一个方案而不停的打字。这件事情，也就此放下。这是一段时间现象，还是大部分时候都是这样？我想在其位的人一定深有体会。

个人认为，从长远的发展来看，这种做法是会降低利润的。没有完整的体系，很多时候，我们做一件事情，可能重复了好多次，都没有历史资源可以借鉴。其实是有的，只是没有人去整理。没有形成知识管理库。大部分公司以目录式的结构来管理文档，这也没有什么。但是文档散乱的不成样子，就让人接受不了了。如果下定决定去做一个体系的建立，可能会导致的一个结果是当前的事情会有些滞后，但是会让后面的工作很顺利的进行。可能有人提出异议，即使这样也不见得能提高多少工作效率，于是举出ＸＸＸ个例子来说明。我只能说，创建的体系有问题，要变更。利润驱动的一个最大误区就是，太关注眼前的利益而放弃了长远的利益。这和人生的规划如出一辙。有些人花了四年的时候，好好的学习大学课程，毕业后找工作，可以很快上手；而有些人玩了四年，出来后，找工作处处碰壁。

　　所以个人认为，在利润驱动的时候，不要忘记长远的利益规划。

３.  领导支持不力

　　昨天在群里聊天的时候，很多人说公司里的测试人员不足，测试不被重视的现象（老生常谈的话题）。并且有很多人报怨，领导是如何如何的不理解测试，如何如何的不理解测试的重要性，等等。有个问题他们没有描述到的就是：测试究竟带来的直接和间接的利润是多少？这是个比较难确定的问题。但是如果这个问题回答不好，或者让领导们感觉不到利润的提升，想让他们重视测试还是比较难的。还有一个大环境的问题就是，我们都知道测试行业的发展没有几年，或者说普遍的认识到测试还没有几年，以前只有少数人在做，而现在大部分的人都意识到了应该做测试。但，仅是意识到，并没有形成测试必做的传统。那就意味着，可能是意识到了，但不知如何发展下去。80年左右的人现在也差不多30岁左右了，这些人在接受的教育和在工作时做的测试可能稍微多一些，但是他们大部分是中层领导（普遍的情况），或者说更多的是干活的人。中层领导要想推广测试体系几乎是不可能的事情。他们能做的只是局部的更新。这是不是意味着，只有这一代中有测试体系的概念并且力行的人做了上层领导后，才有可能推动全面的测试体系？如果是这样的话，恐怕还要等几年了。商鞅变法成功是因为有秦孝公的支持，做为历史的评判：秦孝公是个天才领袖。而测试的天才领袖在哪儿？同样有了天才领袖和可堪大用的人，还是要面对老世族的攻击。而这场战争至少要打两代人的时间。软件测试体系如果要推行，纵然有人可以做，在大部分的企业里，估计也要等到媳妇熬成婆。

４.  执行不力

这个问题出现的前提是３中的描述已经不是问题。执行碰到的最大的问题是与旧制度的冲突。要知道，让人改变一种习惯是很难的事情。要让一个企业改变习惯，是更难的事情。还记得在以前的公司里推行ISO这个体系时，只有开始的事情，每个人学按照ISO来做些事情。可是突然改变这种习惯很难受。终于难受到了不能承担的时候，还是恢复了旧制度。而ISO相关的内容成了市场上的一个说辞。但是为了满足这个体系，公司在每到要再次评审的时候，要耗费大量的人力来再次修正。执行不力的另一个大的问题是意识不到体系的重要性。从而得不到广泛的支持。很多人在报怨的同时，没有考虑到一个本质的问题就是自己处在什么样的位置上，应该负什么样的责任，这件事情是这个职位上做得了的事情吗？这一点我反复强调就是因为现在很多的职位的责任不清晰。导致了很多人都觉得做了自己不应该做的事。这一点在体系中会有清楚的描述就是角色职责。所以让每个人理解到整个体系存在的必要性，再来理解个人的角色职责就不会出现这个问题。从而使体系的执行更有中坚基础。

５.  人治还是体系方法治？

此部分只描述软件测试方面的内容，不妄言公司的全面管理。我们知道具体的技术细节是有方法可能参考的，比如测试用例的覆盖率，是可以从技术角度来计算出来的（计算是需要时间和相应的知识来支撑的）。但是，在大部分情况下，我们碰到的现象还是：领导分配哪个模块让谁来负责测试，这个测试人员只从业务角度来写瀑布似的用例描述，最后执行这个测试用例。这样的覆盖率是没办法计算的。而有些人还妄图从这样的执行结果中去计算覆盖率。最后只能不了了之。这里导致了一个后果就是测试的充分性得不到保障，发布后的系统又出现新问题并且没有人为此承担责任。这里描述的是拍脑袋形成的现象。

上面描述了一种人治的结局，下面还是回到主题来描述人治的问题。我们知道，人治是一种主观的判断。我觉得你不行，我是领导，你就是不行。这样的描述让人清晰的感觉到，一个人的职位和他的主观判断严重影响到后续的质量。我记得看过一句话：一个公司的老板的个人素质决定了这个公司的企业文化和前途。暂不说这句话的合理性，应该有很多人同意这句话说的是对的。所谓仁政，周礼，井田制，已经在很多人的潜意识里扎下了根。

那体系方法治呢，明确了一些扯不清的职责，也让人在项目的各个阶段中，知道了自己应该做什么，做成什么样子。做不到，要么是能力不行，要么是规范有问题，需要变更。在经过裁决之后，如果是前者，可以通过换人、培训等手段解决；如果是后者就是变更。不会出现头脑一晕，停滞不动的现象。就不会出现像有些人说的，我现在脑子都大了，不知道领导到底要我做什么，也不知道做成什么样子，才算是领导满意了。这里说的是公司内部，如果涉及到客户，其判断的规范标准就是客户的满意度。从大结构上理解各个层面，然后去做，这是我认为有效的控制质量的办法。

那是不是说体系治就万无一失了呢？当然不是，因为事是人做的，而涉及到人，变数就很大的。还是需要人治的辅助。灵活的综合运用，才能见实效。

６.  什么是适合的体系？

　　在交流中我发现很多人把体系看的很死，好像说到CMMI就应该按初始级、管理级、已定义级、量化管理级、最佳化级一层层的发展上去，或者说到RUP就得先启、精化、构造、移交的来做。我想说的是，如果你要过CMMI的认证，完全有按照要求做的必要。而如果，我们觉得他们都不适合，完全可以自己去制定一个体系，借鉴是没有问题的，只要符合就行。并且，这些建议采纳不采纳，也是我们自己决定的。要做，就落到实地来做。别空摆一个架子。而有些人有着无知的潜意识里的排斥心理：我们要有自己的流程，我们不按照任何成熟的流程来做。好像自己拍拍脑袋，体系就出来了的样子。而搞到最后，依旧是不了了之。我相信那些从规划到实现的人，不管是对的错的，如果只有规划没有实现，听着就恼火。