Root Cause Analysis
Can anyone throw light on the term "Root Cause Analysis" and its effective techniques.I am quite new to this terminology and quite naive about how to go about it. I have some very fundamental doubts on this topic.
1.Is root cause analysis applicable to only projects which have the same user specifications.
2.how can i effectively employ this stratergy to reduce the number of bugs in my projects.for example if a project which is completed has around 100 bugs in various categories like functionality, performance,cosmetic defects etc and another similar project but with different team is going on, how would i be able to educate the developers and forecast the type of bugs and critical areas where special attention has to be paid.what is the most effective and widely practiced methodology to implement this?
I would be pleased with ur inputs on this issue.Thanks a lot.This forum is helping me in a big way!
Re: Root Cause Analysis
A good tool for RootCause analysis is ProbeRunner, and it integrated with WinRunner and TestDirector if you use them, but they are not required. http://www.proberunner.com
Rocky Dean Pulley
Email for a FREE demo of ProbeRunner!
The most unique software testing tool on
the market! <A HREF="http://proberunner.com
Re: Root Cause Analysis
rpulley is obviously confused about what root cause analysis is and what a test tool is used for.
I have a large amount of experience with root cause analysis involving operations at nuclear facilities. Root cause analysis does not have to be a complex subject that that's crammed into a two week course. All it takes to perform a root cause analysis is a moderate amount of technical competence is the applicable area(s), a large amount of common sense, and the willingness to to ask "why" when people are giving you exasperated looks. The most important thing to remember is that what happened is not the root cause. That is the "immediate cause". The root cause is what allowed (or looking at it another way - what could have prevented) the immediate cause to occur. An example is:
Your program crashes. You write a defect report on it and the next day a developer tells you that the crash was caused by a memory leak. The memory leak is the immediate cause. You ask why it was observed in system test. You are told that no unit tests were performed specifically to detect memory leaks. This didn't cause the problem, but it allowed to have a greater impact. So inadequate unit testing would be a contributing cause. You then ask what caused the memory leak. You are told it is bad code. You should then ask why there was bad code. You are told it was human error. Human error is not a very good root cause because there is very little that can be done to make humans perfect! So a better root cause would be not using a tool to analyze and detect memory leaks or an inadequate code review.
What usually happens is most root causes end up being a lack of a management control of some sort. These kinds of root causes are favored because it means you can do something about it. Two other common kinds of root causes are:
1. Deviant behavior (i.e. a programmer is secretly a member of a hacking club and he writes trap doors in the code). I it is a large enough concern, you install management controls to prevent concequences arising from deviant behavior.
2. Management accepted risk. An example would be a light bulb burning out. If it's the light bulb in your bathroom, you don't want to spend a bunch of time and money preventing it from burning out. If it's a warning light in an aircraft, you might want redundant lights and perform a check of it before every flight.
Now for the big question...how do you employ this strategy? Well my first suggestion is to be careful and not step on too many egos. Nobody likes to be blamed for something, and the amount of energy spent on blame avoidance is enormous. The other thing to be careful of is since almost all of the root causes are related to inadequate or missing management control systems, it is very easy to think that if you could somehow shotgun a bunch of controls, policies, and systems in place, you would never have another defect. It isn't easy to make a bunch of new policies work correctly, particularly if they are instituted at the same time. If it were easy, most organizations would be CMM level 5. A better approach might be to prioritize which systems will be implemented in a given time frame, and gradually work your way up.