软件测试中CMM评估中存在的若干问题
前言：本文部分内容参考了2000年2月IEEE杂志上的一篇文章。该文作者从采购方和软件企业方分析了SCE中存在的若干问题，最后发问：“CMM评估还可信吗？” 中国软件企业的CMM评估，一开始就充满了浮躁、做秀和功利的气息。整个CMM评估的过程，我们看到的是好大喜功的政府行业主管部门、一贯爱凑热闹的新闻媒体、有赚白不赚的中介机构、证书随身带的主任评估师和愿意花钱买吆喝的软件企业。CMM评估的这种浓厚的功利性，使得“Gaming the Assessment”成为软件企业上上下下的共识和“不宣之秘”。希望本文对国内软件业界正确对待CMM起到应有作用，不要像某些软件企业一样找个“证书随身带”、“一手交钱，一手交证”的主任评估师。毕竟，提高企业的核心竞争力是最重要的。
1 评估人员的资质SEI对主任评估师的资质要求比较严格，但是评估是由一个评估小组来进行的。
问题1：评估组员的资质很难满足。
通常，评估组员很难达到SEI所要求的软件工程的技术和管理背景。
问题2：评估人员多是管理人员，技术素质普遍较弱。
这个问题也包括主任评估师，由于多年脱离软件开发实践工作，主任评估师甚至在提问时有意回避技术问题，而是反复询问管理问题。因为评估人员的技术素质普遍较弱，因此对于CMM中涉及工程部分的关键实践解释能力很差。甚至在对企业员工面试时，当员工提到技术方面问题时，评估人员会将话题岔开，又转到管理问题上。
2 评估的时间压力一般评估的时间都在一周左右，要执行的工作相当多，时间压力很大。原来的评估方法中要求单个面试的方式，后来迫于时间压力，新版本中增加了“Group Interview”（团体面试）。
问题3：团体面试本来是为了节省时间，实际上往往掩盖了问题，不能发现真实情况。
联想测试部门的面试，就是团体面试的方式。
对于评估小组而言，由于时间紧张，他们往往不愿意运用自己的洞察力和专业判断力，而是满足于在检查清单上一项一项划勾，也就是俗称的“Checklist强迫症”。
问题4：“Checklist强迫症”也给了软件企业一个钻空子的机会。
软件企业可以努力使文档做得更加“方便评估小组的工作”。
3 CMM问卷在CMM评估中，用到的是同一套问卷。连美国人都批评到，“不可想像对于医生、建筑师或者律师采用同一套试卷来考察，而对于软件企业的评估使用的确实一套不变的问卷。想想看，这些软件企业可能是在为我们的国防系统进行开发！”
问题5：同一套成熟度问卷。
CMM评估允许企业在评估前对员工作出培训，而这个培训的作用往往被扭曲了。很多软件企业甚至“教唆”员工在成熟度问卷上如何回答的“更成熟”一点。
4 文档因为CMM评估要求文档应该有在线版本（这样才可以被配置管理软件所管理和控制），所以企业在将文档转换为在线版本时，就可以对文档作出修饰。因为知道评估小组的时间很紧张，软件企业可以把文档弄得故意非常复杂，评估小组有时候看到复杂得文档，会不愿意去深究，认为既然写了这么多，看在页数得份上，也应该满足要求。
问题6：过分依赖文档。
5 项目的选择选择什么项目给评估小组看，这里大有学问。软件企业可以把自己最“成熟”的项目、最优秀的员工组成一个“Goldern Project”来供评估小组检查。那么，这样的评估可信性就大打折扣。比如，国内某软件企业明明是自己一个20多人的“中央研究院”过了CMM某个级别，在媒体宣传时却故意混淆视听，有意无意造成整个企业通过某个级别的错觉。
问题7：选择什么项目，选择什么部门，这其中太多猫腻。
6 事先“培训”员工甚至有这样的现象，员工在接受面试之前，塞给他一本企业的CMM指导手册，甚至要求他故意在手册上作点笔记、把手册弄得脏一点，以显得认真阅读过了。
问题8：“培训”员工作假。
这里最严重的问题，实际上是主任评估师的技术素质。计算机技术领域日新月异的发展，很多主任评估师是只知道“管理”，对于技术的理解可能仅仅限于5－10年前的技术。IEEE杂志文章的作者建议，在评估时应该同时“Conduct on-site technical evaluations”，观察企业的开发人员实际完成技术工作的方式。作者特别举了一个企业的例子，纸面上的同行评审与实际中的同行评审的天渊之别。
Paul在给联想评估时，竟然没有向测试部门提问，这个事实太令我失望了。其他领域不论，我真的不信对于测试领域竟然无话可问！
文章来源于领测软件测试网 https://www.ltesting.net/