51Testing软件测试论坛

标题: 谈测试体系规范的推行-Zee [打印本页]

作者: Zee    时间: 2009-6-3 13:54
标题: 谈测试体系规范的推行-Zee
转载请注明出处。


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

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

2.        利润驱动的影响

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

3.        领导支持不力

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

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

5.        人治还是体系方法治?

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

6.        什么是适合的体系?

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

7.        总结
   当有了整体的测试体系概述之后,即使有利润驱动,也应该与此同时关注一下体系的建立。因为客户对公司的测试需求也是在测试体系之内的。再加上有领导的支持和一批有执行力的人推广整个体系,测试体系才会有可能发展起来。而在这一过程中,尽可能避免人治的手段。只有这样才能使体系有生存的空间,否则将使苦心建立的体系很快就荡然无存。
作者: luckflying    时间: 2009-6-3 15:14
CMMI还是好东西,前面的帖子我提到过,技术上我们和国际同步,人才也不比他们少,可成果却差太多。其中对于体系结构的认知,是拖后腿的环节之一。

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

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

至于领导的支持,呵呵,当你每半月提交给他一份准确量化的报告,他才不会选择现有模式不断的询问,感性认识测试过程呢。
作者: 板砖    时间: 2009-6-3 16:02
楼主的想法很好.
但实际情况是小公司没办法应用测试体系,这个是管理问题不是技术问题.大公司根本就不需要你的测试体系,公司内部已经有成熟的测试体系了.
作者: 我是别人的马甲    时间: 2009-6-3 17:11
新手抢先顶
作者: tiannianyong    时间: 2009-6-3 19:23
好想法,昨天也跟一质量管理部头谈到这点。
作者: heqingbluesky    时间: 2009-6-4 16:21
有多少公司能够用制度的管理和完善来替代领导的意见,客户的意见。




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2