《软件同级评审》学习有感

2010-02-23  金鑫 

      Karl E.Wiegers在《软件同级评审》中说:“如果你没有时间采用同级评审来提高产品质量,则将需要更多的时间去纠正测试人员或客户发现的缺陷。……评审的最主要障碍来自开发人员没有意识到他们已经犯了多少错误,因此他们也看不到查找或减少错误的必要性。”

      所以为了有效地提高软件质量,我们很有必要用他人的眼睛来审视自己。邀请不同背景的评审人员从不同的角度检查,弥补个人的不足,及时发现并解决自己发现不了的错误,即使是两次发现同一个错误总比把它漏掉好。需求与设计评审就是在进行下一步工作之前“互相用他人的眼睛来审视自己”,必然会提高项目的成本。而这种成本是质量成本的一部分——预防成本,其目的是减少失败成本(包括返工、维护、变更、重新测试、满意度下降、形象损坏,以及顾客流失造成的损失)。

      其实评审制度有很多分类,了解CMMI认证的企业相对规范,国内中小软件企业能做到、做好评审,并形成文档化的其实不多,尽管很多测试同行(很多公司未设置过程控制人员)在有意推进,但是收效甚微。
     
      往往“客户至上”的主导、需求频繁变更、详设文档的更新停滞、过程控制的失控等现象无时无刻不在困扰着测试人员或SQA,尽管大家都知道“磨刀不误砍柴工”的道理...
595°/5893 人阅读/6 条评论 发表评论

吴卓扬  2010-02-23

国内,怎一个“杯具”了得啊~~


王爱莉  2010-02-23

我现在的公司都不做评审


田静  2010-02-23

我认为要达到最佳评审效果几乎是一种理想状态。。。
很多时候需求、开发、测试之间有种微妙的对立。
需求对开发:你写的什么东西,跟我要的完全不一样;
开发对需求:你这个需求目前技术不可能达到,脱离实际;
测试夹在中间更难,地球人都知道,就不说了。


金鑫  2010-02-23

田静: 我认为要达到最佳评审效果几乎是一种理想状态。。。
很多时候需求、开发、测试之间有种微妙的对立。
需求对开发:你写的什么东西,跟我要的完全不一样;
开发对需求:你
有理


田庆希  2010-02-23

唉 怎一个杯具了得


张海军  2010-06-18

其实不管是软件同级评审还是上级评审,往往是执行不到位的。原因多种多样,譬如:很多的项目经理本身就不是一个合格的项目经理,在权衡项目风险的优先级时,往往是将领导压迫的紧一些的条件作为优先考虑对象,那么项目经理就会遇到进度、成本、范围等各种约束条件,如果没有QA、再加上客户不看重、领导不重视,那么软件评审这个最佳的最有效的最搞笑的发现缺陷的方式往往会被忽视。
道理大家的领导们都懂,可是毕竟大多数领导还是刚起步状态,目前还是在追求短期效益的状态,又有多少人能够用放大镜去看劣质成本呢,就算看到了,又有多少人真正能够去解决这个问题呢?
既然组织上没有强迫的要解决这个问题的命令,而且还在不断地加大追求短期利益的要求,那普通的测试工程师、项目经理、QA又有多少能够真正放开手脚去实施软件评审呢。种种如此的反问,自然能够知道,要实施完备的软件评审,是很不易的。
以上,个人感受,仅供参考,欢迎拍砖。
平时比较忙,没有经常来,今天才看了这个帖子并回复,大家不要觉得我很Out。


登录 后发表评论