Reviews and Root Cause Analysis

Software Testing is an important phase of SDLC and for the testing team it’s all about testing application/product and find out more defects as early as possible and do not leave anything to Business (UAT) or into the production. The question arises – is ‘finding defects’ to deliver the quality product is a job of only ‘testers’? Defects/Bugs can only be found in testing phase? The answer is quite straightforward – NO. As a project team, it is the responsibility of entire team (BAs, PMs, Architects, Dev, Test) to deliver a quality product to end user/customer. Defects are bound to arise right from Requirements phase and if not found at the right time, could creep to later stages and maybe into production. Fixing these bugs at later stages would be costly and in turn, increase the cost of the project. These are process gaps and would be overcome if we employ best practices.

What are the best ways to avoid such process gaps to improve the quality? There could be many but simple and effective ways to overcome the above scenarios is Reviews at each phase and RCA for each bug/defect leaked.

Reviews are the simple mechanism to find and remove the defects at the earlier stages. Reviews should be routine for artifacts we create at various phases of SDLC and should be conducted periodically at each phase. Few effective review methods are Review Meetings (formal review), Inspections, and Walkthroughs.

There are cases even after following best practices such as reviews at each phase of SDLC does not guarantee defect-free software/application/product. Defects are leaked to later stages and even to production but believe me they will few in numbers.

What is next? What we should do if we still see defects creeping to later stages or production?

We should ask below simple questions

* Why did it occur?

* When did it occur?

* What made it occur?

* How best can it be avoided further?

Yes, asking simple questions for each of the defects would give us solutions and the mechanism is called Root Cause Analysis.

In simple terms, Root Cause Analysis (RCA) is the mechanism of analyzing the defects and identifying the main cause whether the defect was due to unclear requirement(s) or design interpreted wrongly or a coding mistake or miss by the tester.

And to help this we have various tools – Cause-effect diagram (Fish Bone Chart), Pareto Analysis (80:20 analysis), Run Chart, 5 Why’s, Brainstorming and voting, and Check list. Aim of these tools is to find the cause and let the team know where they can improve and not let such things occur in future.