缺陷预防说

    之前听闻公司要做CMMI，其实很早就耳闻了CMMI，只是具体内容还不甚了解，多少有点觉得莫测高深，又加上听闻一个CMMI3评级就得耗资数十万，顿时觉得这东西一定是个好东西，就像香饽饽一样的抢手。当然，每个去做CMMI的公司它们的领导层都有自己的想法，这种种想法我们无从知晓，不过作为CMMI评级公司的员工或者即将要评级公司的员工，CMMI评级不应该仅仅成为我们提升自己标签价值的一个附属品，起码领导层不希望如此。
    虽然CMMI是公司的，但是它同样也是要落实到部门、团队甚至个人的。个人觉得它还是有很多值得我们去学习、实施和总结的。比如说关于CMMI五个级别它们的PA（Process Areas）以及KPA（Key Process Area、关键过程域）。个人觉得我们公司如果geilivable的话可以在CMMI3左右徘徊，但是CMMI4则是一个暂不可逾越的鸿沟，那么关于CMMI4的KPA是什么呢，CMMI4级即【量化管理级】，对应的KPA是【缺陷预防】，具体级别定义是：【分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。】
    在这里就不得不谈谈QC和测试了，我有问过我们到底是质量测试部还是质量控制部，老大很肯定的说是质量控制部。我们都知道测试更多的倾向于产品的，而控制不仅包涵了测试，里头还存在一定的缺陷预防成分。我想起有位老师跟我说过的话，软件测试不是为了发现更多的bug，而是要做到缺陷的预防。想到这，我茅塞顿开，恍惚如隔世般。
    其实我们部门关于缺陷的预防是有过雏形的，比如我们在bugzilla中建立的缺陷模型就是一个很好的模板，只可惜应用起来还是有一定的困难。在这里我就得讲下最近的一个项目：会员管理系统。它与影院的接口需要影院那边进行二次开发，并有一定的功能新增。我在缺陷模型中有两个模型是关于影院系统的，原本我根据那模型提早跟开发说有此风险的话，开发那边就可以避免这风险，那就会成为缺陷预防的一个很好实例。但可惜的是我是在送测的时候才想起这档子事，bug还是如预期般的发现了，但这个bug却让我心情有些许低落，它不应该是我的成果，而是我的失职。我天天在外宣扬缺陷放大模型，但在实际工作上自己做的并不好。
    这是一个不好的例子，但也许它会演变成一个好的方向，我们努力尝试着让测试用例重用，那我们也可能可以去尝试着让缺陷复用，有可能我们现在只能总结特殊的、类似项目的，但是没准以后我们可以总结常用的、通用项目的。我们不是要评CMMI么，那我们是不是先做好它的PA才行呢。

转载于:https://www.cnblogs.com/medoraemon/archive/2011/03/11/1981059.html