谈测试体系规范的推行-Zee

Zee

转载请注明出处。


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

1.        测试体系的整体概念
　　　一直以来，我都觉得这个问题挺概念化的，就是说出来后让人抓不住重点的感觉。要说某个具体的技术细节，很明确。比如说Weblogic的调优，可能会有人很快联想到：连接池、JVM、线程数等等。但是测试体系是什么？有点虚。
　　　在多次听测试人员的报怨之后，我觉得现有规范可能是影响测试体系建设的第一要素。当然，领导还要强力支持。先说测试规范，后面再说其他因素的影响。
　　　首先，要把软件测试和质量保证分开来。尽管现在大部分公司把测试人员叫做QA工程师，尽管这一叫法是错的（个人认为是错的），还是被一些人屁颠屁颠接受并推广去了。好吧，这些概念性的问题，我们先不认真的追究了。测试体系在我的意识里是：为了尽可能找到系统的缺陷的和评估系统，对应测试需求，使用相应的管理方式，按照流程和方法进行系列的测试动作，并最终产生符合规范的测试产品的过程描述。在这一过程中，有几个词是要体现在测试体系里的，就是：管理、流 程、规范、方法。
要推广测试体系，首先要求的个人素质，就是要有整体的体系概念。这样说起来好像有点太正式了，有点累。换个角度说：现在有没有太多的人有测试体系的整体概念？如果有，知道不知道自己在这个体系中处在什么位置？职责是什么？
　　　曾经看到一些公司和人生套CMMI、RUP、ISO之类的规范标准（这几套东西的角度是不一样的），但是由于推广的方式太生硬而导致人的意识转换不过来。最后不了了之。尽管过了什么认证，也是推倒重来，恢复旧制。理由很简单：这些体系不适合我们，还是我们自己对体系比较清楚。测试体系也同样如此。精髓没有领会到，就生套，是不可能推广开的。记得有人说，进一家公司是一个“固化—僵化—优化”的过程。而我觉得大部分人连固化还没走出第一步，就觉得回头才是岸了。
　　　前一阵子为一个客户推行测试体系，其实从技术角度来说，基本上都可以实现了。但是通过反复沟通，才知道客户想要的体系只是要一个可控制的PDCA过程，于是我把体系整个给缩小了，客户才觉得这是他要的。实际上很多内容已经删减了。如果做一个项目的话，我觉得客户要的这种是可以直接和做事相关的。而如果要为一个公司建立一套完整的体系，显然这样只能留下记录，而留不下体系中其他的关键部分。
　　　要让相关人员有测试体系的整体概念。向与推行体系必然相关的人培训体系概念，阐述体系的优点。当然也会有缺点，所以才需要变更流程。

2.        利润驱动的影响
　　　无可厚非，追求利润永远是公司的第一要务。在很多时候，我们不得不为利润让路。有时候就是因为一直是这样，才导致了我们的测试体系不可能完全建立起来。我们只能绕着客户转。
　　　最近大领导组织开了一个会，就是建立一套完整的测试体系。在这个体系的各个部分，都有相应的文档来支持。当时我画了一个大概的思维框架图，包括的内容很广泛；其中有每个职位上的人在什么样的阶段、按照什么流程和规范、做什么样的事情、做成什么样子，等等。都有相关的模块来维护其完整性。领导一看，觉得不错。接下来就要提到如何落地。在参考了很多意见之后，决定落实成为一种可以按时间推移而实行的方法。但后来实际情况是：做事是需要时间的，在某些时候，一个人要兼顾好几个事情，就不得不为与客户有关的事情让路。自从年后，我画了一个小范围内的ＰＤＣＡ流程图之后，就开始为客户的一个方案而不停打字。这件事情，也就此放下。
　　　这是暂时现象，还是大部分时候都是这样？我想在其位的人一定深有体会。我们经常可以看到听到或者亲身经历需求经常变更的事情，不仅是业务需求，测试需求也是这样。做事情的人不知道上层的人怎么想的，但是只有做事情的人知道怎么才能做得更完善。有时，有些客户只是要一个自己认为重要的结果。其实对整个系统来说，这个结果意义并不大。我曾经做过一些以客户为核心的业务。比如，客户只需要知道系统在当前配置下的性能状态。也许客户只需要响应时间，认为用户数是很关键的数据。于是他们迫切地想得到这个数据，但是没有考虑到整个系统的性能表现应该是从不同角度来关注的。在这个过程中，其实我们可以关注一下如何做得更完善，从而逐步丰富体系。
　　　如果仅从当前项目出发，个人认为：从长远的发展来看，这种做法是会降低利润的。当然，没有完整的体系。很多时候，我们做一件事情，可能重复了好多次，前后都没有历史资源可以借鉴。其实是有的，只是没有人去整理。没有形成知识管理库。大部分公司以目录式的结构来管理文档，这也没有什么。但是文档散乱得不成样子，就让人接受不了了。如果下定决心去做一个体系的建立，可能会导致当前的事情会有些滞后，但是会让后面的工作顺利进行。可能有人提出异议，认为即使这样也不见得能提高多少工作效率，于是举出N个例子来说明。我只能说：创建的体系有问题，要变更。利润驱动的一个最大误区就是：太关注眼前的利益而放弃了长远的利益。这和人生的规划如出一辙。有些人花了四年的时候，好好学习大学课程，毕业后找工作，可以很快上手；而有些人玩了四年，出来后，找工作处处碰壁。
　　所以个人认为，在利润驱动时，不要忘记长远的利益规划。在近期利润可以平衡的前提下，应该尽量以长远的眼光来看事情，一点一点积累。按流程说明来控制近期要做的事情，往往也不会增加太多工作量。只是需要在平时工作中灌输体系控制的思想。

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

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

5.        人治还是体系方法治？
　　　此部分只讲述软件测试方面的内容，不妄言公司的全面管理。
　　　我们知道具体的技术细节是有方法可以参考的，比如测试用例的覆盖率，是可以从技术角度来计算出来的（计算需要时间和相应知识支撑）。但是，在大部分情况下，我们碰到的现象还是：领导分配哪个模块让谁来负责测试，这个测试人员只从业务角度来写瀑布似的用例描述，最后执行这个测试用例。这样的覆盖率是没办法计算的。而有些人还妄图从这样的执行结果中去计算覆盖率。最后只能不了了之。这里导致了一个后果就是测试的充分性得不到保障，发布后的系统又出现新问题并且没有人为此承担责任。这就是拍脑袋形成的现象。
　　　我们知道，人治是一种主观的判断。我觉得你不行，我是领导，你就是不行。这样的描述让人清晰地感觉到：一个人的职位和他的主观判断严重影响到后续的质量。我记得看过一句话：一个公司的老板的个人素质决定了这个公司的企业文化和前途。暂不说这句话的合理性，应该有很多人同意这句话说的是对的。所谓仁政、周礼、井田制，已经在很多人的潜意识里扎下了根。
　　　那体系方法治呢，明确了一些扯不清的职责，也让人在项目的各个阶段中，知道了自己应该做什么，做成什么样子。做不到，要么是能力不行，要么是规范有问题，需要变更。在经过裁决之后，如果是前者，可以通过换人、培训等手段解决；如果是后者变更体系方法就好了。不会出现头脑一晕、停滞不动的现象。也不会出现像有些人说的，我现在脑子都大了，不知道领导到底要我做什么，也不知道做成什么样子，才算是领导满意了。这里说的是公司内部，如果涉及到客户，其判断的规范标准就是客户的满意度。从大结构上理解各个层面，然后去做，这是我认为有效的控制质量的办法。
　　　那是不是说体系治就万无一失了呢？当然不是，因为事是人做的，而涉及到人，变数就很大的。还是需要人治的辅助。灵活综合运用，才能见实效。建议固化体系制度为根本。当形成强大的体系传统时才考虑人治参与其中，但一定要有所侧重，并在见到实效后立即回归体系制度。

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

7.        总结
　　　当有了整体的测试体系概述之后，即使有利润驱动，也应该与此同时关注一下体系的建立。因为客户对公司的测试需求也是在测试体系之内的。再加上有领导的支持和一批有执行力的人推广整个体系，测试体系才会有可能发展起来。而在这一过程中，尽可能避免人治的手段。只有这样才能使体系有生存的空间，否则将使苦心建立的体系很快就荡然无存。

luckflying

CMMI还是好东西，前面的帖子我提到过，技术上我们和国际同步，人才也不比他们少，可成果却差太多。其中对于体系结构的认知，是拖后腿的环节之一。

你描述的情况很像我前面待过的国内公司，想当年全民齐“作假”，补了很多文档后通过CMM2。到后来证拿到后又慢慢恢复原样。后来去了外企，的确很不同，他们几乎没有准备的情况下过了CMM5，楼主所困扰的东西在这个公司里却少了很多，我想这就是差距吧。

其实管理不是控制个人就完了，里面有大量的技术细节。要实现“测试体系”话的管理：
1）理论体系的支持，楼主觉得难，因为你试图根据经验去完善之，其实不必，现成的已经有。
2）工具，以及角色的支持：成熟的测试管理需要控制到每个具体点，并且要做到量化！这都需要很多工具的支持才可以，否则空谈。

至于领导的支持，呵呵，当你每半月提交给他一份准确量化的报告，他才不会选择现有模式不断的询问，感性认识测试过程呢。

板砖

楼主的想法很好.
但实际情况是小公司没办法应用测试体系,这个是管理问题不是技术问题.大公司根本就不需要你的测试体系,公司内部已经有成熟的测试体系了.

我是别人的马甲

新手抢先顶

tiannianyong

好想法，昨天也跟一质量管理部头谈到这点。

heqingbluesky

有多少公司能够用制度的管理和完善来替代领导的意见，客户的意见。