Applying Root Cause Analysis to Software Defects
Prevention is better than the cure
According to an IBM white paper , the cost of fixing a defect in the testing phase is up to 10 times more than if you catch it in the design stage right at the start. The cost to fix that same defect in a post-release product is up to 30 times more. The earlier you catch the defect, the more time and money you can save.
Itís also worth bearing in mind the potential damage you can cause by allowing software to hit the market with defects in it. Customer satisfaction is impaired and a bad experience can do irreparable harm to your reputation. Youíll also still end up having to fix the defect, which means another test cycle to ensure it is fixed and regression testing to ensure that you havenít introduced any new defects.
Cast the net wide
As the champions of quality assurance, the QA department is best placed to drive forward the use of RCA. It is typically employed to investigate major defects and one-off disasters, but if you carry the methodology through to all defects then you can strengthen its accuracy and realize much greater benefits. A little extra effort in the short term will pay large dividends in the long term. Effective statistical analysis requires as great a data pool as possible and provides your best chance of identifying the patterns that betray a real problem. Find those problems, dig up the roots, and address the causes, and you can drastically improve your processes.
The ultimate aim is closely aligned with the remit of QA Ė to stop defects reaching the customer, but the side-effects of that include improvements in your processes throughout the software development chain. This can extend beyond individual projects and will result in more efficient use of your resources and a healthier bottom line.
Pulling everyone together
If you intend to employ RCA in software development then you must get everyone to buy in. Youíll need more than casual approval from the management, the software engineers, and the testers in order for this to work. Identifying the root causes of problems requires an objective analysis and may involve examining the original requirements, poring over design documents, double-checking how code was implemented, and putting both test plans and the execution cycles under a microscope.
You should expect some resistance at first because individuals will be concerned about taking the blame for mistakes or oversights. Make it clear from the outset that the intention is to uncover faults in the processes and not the individuals enacting them. Be very wary of creating a divisive atmosphere and avoid dwelling on the cause when it has been unearthed, instead move quickly on to collaborating on how it could have been prevented. It will be counterproductive if you get bogged down in arguments over who is to blame.
... to read more articles, visit http://sqa.fyicenter.com/art/