缺陷预防之RCA实践小记

RCA背景、概念、开展目的 IOWA 州立大学质量管理学 院认为:很多公司在设备发生故障后,都能够很快修复,但往往很难发现哪些是引起这些故障的根本原因,这样会导致故障会再次发生。这里所说的根本原因,是指 导致设备失效的基本原因,如果该原因得到纠正,将会避免该事故重发。根本原因分析技术是一个发现和消除根本原因的过程,能够有效防止这些问题的发生,只有 当这个根本原因被发现和消除后,这个问题才能够被彻底解决。

  而美国能源部1992年发布的《根本原因分析指南》(DOE-NE- STD-1004-92)中,把根本原因定义为:指一种原因,当这种原因被纠正以后,将会防止此类事故或者类似事故的再次发生。根本原因并不是一种仅仅导 致这次事故发生的原因,在更大的范围内,极有可能对发生的其他事故还存在着影响。根本原因最基本的特征应该是:从逻辑上能够被识别并能够被纠正。可能会有 一系列的原因都能够被识别,从一个导致另一个,但是这一系列的原因应该能够被追溯到最基本的,并且能够被识别和纠正的原因。

  在我国大亚 湾核电站的建设和运行过程中,由美国PII(performance improved international)公司提供了RCA方法,该公司把RCA定义为:通过一整套系统化、逻辑化客观化和规范化的分析方法,找出设备故障的故障机理 和根本原因,并通过制定合理的纠正行动彻底消除这些根本原因,从而恢复设备功能,防止同样或者类似故障重复发生的一种解决设备故障问题的分析技术。

  同样,RCA分析也早已在航空航天、医疗领域、应急处理等行业中广泛使用。

   根本原因分析(Root Cause Analysis 后简称RCA),本原因分析(RCA)是一项结构化的问题处理法,用以逐步找出问题的根本原因并加以解决,而不是仅仅关注问题的表象。根本原因分析是一个 系统化的问题处理过程,包括确定和分析问题原因,找出问题解决办法,并制定问题预防措施。在组织管理领域内,根本原因分析能够帮助相关者发现组织问题的症 结,并找出根本性的解决方案。

  笔者建议在软件测试相对成熟或流程清晰的质量团队或公司,可以有意识的开展RCA工作项RCA方法在软件产品质量管理中应用的目的在于:

  a、从缺陷与问题中进行学习

  b、系统化的确定需要改进的区域或过程;

  c、防止重复犯错

  拒绝空谈,为了让好的方法,更加具有执行力。笔者将阅读了国内、台湾、医疗行业的相关资料,整理如下,其中罗列准入与验收标准,方便大家可量化的执行。

  RCA验收目标

  1、RCA活动是有计划的,控制分析成本;

  2、RCA应包含缺陷分类分析与过程管理问题整理;

  3、RCA应包含对缺陷与问题的根本问题的分析与推理,结合不同角色收集得出;

  4、RCA的结果是一个或多个纠正操作建议(在开发过程中进行一些更改与优化,以消除产生错误的原因)

  5、应保持RCA结果的准确记录与跟踪;

  RCA进出标准与有效输入/出

  进入标准(缺陷分类分析与过程管理问题整理)

  1、缺陷分类分析进入;

  a、单次测试的缺陷计数,如  缺陷数≥X个需进行RCA分析;

  b、遗留缺陷计数;如  遗留缺陷数≥X个需进行RCA分析;

  c、按缺陷分类(缺陷严重等级、缺陷类型、) ;如  遗留性能缺陷数、遗留界面缺陷等需进行RCA分析;

  2、或事件触发;

  a、违背当前周期的质量目标的;

  b、重要“事件”或哨兵“事件”(如现场反馈严重缺陷、重复出现的缺陷等,又称单一缺陷或整整一类缺陷);

  c、过程管理发现问题(如提交质量低、迭代次数超计划、需求理解不一致、需求确认问题多)

  有效输入

  1、事件报告

  2、事件相关数据

  3、测量结论(以往RCA分析所确定的措施的实施情况);

  有效输出

  根本原因分析(Root Cause Analysis)应用XXX事件分析报告

  退出标准

  完成RCA应用XXX事件分析报告并经QA Manager确认;

  导致类似事件的同类原因未再次产生;

  笔者结合自身实践,整理出,可执行的RCA分析流程。简言之,算是个“最佳实践”分享给大家。

  RCA活动实施流程

  RCA活动角色划分(示例)








====================================分割线================================



最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-09-22 17:50:27

缺陷预防之RCA实践小记的相关文章

【转】 Scrum 过程实践小记

严格来说,不能算是真正的scrum实践,但实践敏捷的过程本身也是一种"敏捷方法",所以就算是"敏捷实践之敏捷开发方法-scrum过程"吧. 一.理论参考:Scrum的实践(该部分摘自网络) 1.Scrum团队(5-7个人的小项目组). 2. Backlog: 急待完成的一系列任务,包括:未细化的产品功能要求.Bugs.缺陷.用户提出的改进.具竞争力的功能及技术升级等,按优先级定义出来,这些任务可能不是完整的,甚至可能随时会更改或添加. 3. Sprint(冲刺):

《Cucumber:行为驱动开发指南》——6.4 停掉生产线和缺陷预防

6.4 停掉生产线和缺陷预防 在团队的所有活动中,哪一件是你觉得最重要的:为新特性编写代码?修复测试中发现的bug?修复生产环境中发现的bug?加速新特性的开发? 令人遗憾的是,在大多数软件团队的优先级列表中,测试的维护都不会出现在靠前的位置.如果办公室大楼里的升降梯坏了,可以确信立刻会有人给设备团队的人打电话.而当测试变得缓慢或脆弱时,除了依赖于它的程序员和测试人员,其他人都不会看到问题的存在.如果你多少还做些测试维护的工作,通常也只在事情坏到令你无法继续忍受,或者因为测试被严重破坏以致产品无

《系统分析与设计方法及实践》一2.5 能力成熟度模型CMM

2.5 能力成熟度模型CMM 2.5.1 什么是能力成熟度模型 CMM(Capability Maturity Model)是指"能力成熟度模型",是对软件组织在定义.实施.度量.控制和改善其软件过程的实践中各个发展阶段的描述.CMM是国际公认的对软件公司进行成熟度等级认证的重要标准.CMM的核心是把软件开发视为一个过程,并根据这一原则对软件开发和维护进行过程监控与研究,以使其更加科学化.标准化,使企业能够更好地实现商业目标. CMM是由美国卡内基-梅隆大学的软件工程研究所(SEI)开

讨论四种关键的质量保证实践在软件开发中的重要性

软件开发和工程被视为非常年轻的职业:但是,它们得到了广泛应用,并且正以比以往更快的速度增长.在许多国家,软件行业目前通常被视为经济增长的主要支柱之一.软件公司常常面临着提供高质量软件的许多困难挑战,而他们也在竭尽所能地让客户满意. 软件质量不可或缺 随着软件变成日常生活中不可或缺的一部分,对软件的需求也明显增长.相应地,高软件质量目前被视为是 "必须具备的" 而不是 "应该具备的".让质量保证团队从一开始就参与到项目规划和执行中,这一点至关重要.然而,仍然有一些公司

敏捷软件测试常见误区

转自 ThoughtWorks 敏捷软件开发是从1990年代开始逐渐引起广泛关注的一种新型软件开发方法,是能够应对快速变化的需求的一种软件开发能力,它作为一种新型的开发模式,被越来越多地应用到软件项目中. 敏捷软件测试指的是在敏捷软件开发过程中跟质量相关的一系列活动,和传统意义上的软件测试有很多区别,因为敏捷软件测试的概念一直比较模糊,所以经常会有人走入误区,我曾经在瀑布型的软件开发模式下做过几年的测试人员,所以在刚刚接触敏捷项目的时候也曾有过一些误解,但是在敏捷软件开发团队工作将近5年后,对很

如果做好测试项目组管理者

1 如何认识测试 测试是一个方法论而不是一个技术论: 2 软件测试的误区 * 软件开发完成后进行软件测试: *软件质量问题是测试人员的错误,软件发布后如果发现问题,那是软件策划四人员的错: *测试技术要求不高比编程容易,随便找一个人就可以完成: *测试跟着开发动,有时间就多测试,没时间就少测. * 测试是测试人员的事,与开发人员无关: 软件测试从这里开始 * 需求测试和设计测试也是软件测试的一种: * 软件测试应该涵盖整个软件生命周期.同时软件测试本身也应被测试. * 测试要执行所有可能测输入:

软件项目质量管理与度量

软件项目/产品的质量问题一直困扰软件企业.监理方和甲方,如何预防.发现.治理软件项目/产品质量问题,是目前我国it发展面临巨大的挑战,这也是it发展过程中关注的主要问题.软件企业.甲方和监理方在研发过程中常常要面临很多难题: 1.软件质量管理基础 (1)质量的概念与定义:(2)软件的质量要素:(3)软件质量评价的准则:(4)iso 9000软件质量体系结构:(5)软件质量保证过程:(6)质量管理大师简介:(7)质量管理的发展历程: 2.软件质量与质量管理 (1)软件质量面临的挑战及模糊认识:(2

让我们区分质量保证与测试

概念与思辨深度 一个行业的发展似乎总伴随着更多的概念被塑造出来.拿测试来说,我们有单元测试.集成测试.系统测试.回归测试.冒烟测试,等等.我们缘何塑造如此多的概念来"为难"自己呢?答案可以用我从@李智勇SZ老师那学到的"概念越纯粹表示思辨深度越深"这句话加以解释,而这一切又为了提高同行间的沟通效率.需要特别指出的是,多个相似但不同的概念想表达的是各自的不同之处,而非共同之处.为此,如果人家在讨论单元测试时,你冒出一句"写好程序,编译完,跑一跑,看看写得对不

软件测试用例对于测试进度的可控性建议——理论篇

从接触软件测试工作开始,相信所有人都希望减少软件测试后漏测的问题(tester希望,开发经理希望,老板希望),但事实是一直以来都没有很好的真正解决产品漏测的问题以及如何减少功能组合爆炸的问题.过去几年因为工作任务的缘故,我在历经几年自动化测试.系统测试和缺陷预防工作后,又回到测试的本源开始思考功能缺陷的测试应该如何做好?从2011年版本到2012年版本直到2013年终于优化完善出了自己的功能测试方法体系,没想到居然在软件测试行业从业近10年时才搞明白了10年前就开始的问题.过去的5年通过实践补充