Root Cause Analysis (RCA) Techniques
Root Cause Analysis (RCA) is the practice of investigating WHY a defect occurred - not just what the defect was - so that the underlying process failure can be fixed and the same class of defect prevented in future projects. RCA elevates QA from a defect-finding function to a defect-prevention function, delivering exponentially more value to the organization.
The 5 Whys Technique
The 5 Whys is the simplest and most widely used RCA technique. Ask 'Why did this happen?' then ask 'Why?' again for each answer, up to 5 times. The goal: reach the root cause - the process failure that, if fixed, prevents recurrence. Example: Bug: Payment processing fails for international credit cards. Why 1: The payment service doesn't handle non-US card formats. Why 2: The payment service was written only for US card formats. Why 3: The original requirements specified only US customers. Why 4: International expansion was decided after requirements were finalized, and the payment service wasn't updated. Why 5: There's no change management process that reviews existing systems when business scope expands. Root Cause: No process for assessing technical impact of business scope changes. Fix: Create an impact assessment checklist for all business scope changes. This prevents every future feature gap from scope changes - not just payment processing.
Technical diagram.
Fishbone (Ishikawa) Diagram and RCA Process
- Fishbone Diagram: Visual tool for complex defects with multiple contributing causes. The 'head' of the fish is the defect. The 'bones' are cause categories: People (training, experience, communication), Process (missing steps, unclear procedures), Technology (tools, systems, infrastructure), Environment (test/prod differences), Materials/Data (requirements, specifications)
- For each category, brainstorm contributing factors. This structured approach prevents the natural human tendency to blame the person closest to the failure while ignoring systemic causes
- RCA Process steps: Describe the defect precisely. Identify all contributing factors (5 Whys or Fishbone). Identify the root cause (the deepest 'why' that, if addressed, prevents recurrence). Define corrective actions (what process will change?). Assign owners and deadlines for corrective actions. Verify effectiveness after implementation
- RCA doesn't mean blame: 'John missed this defect' is not an RCA - it's blame that changes nothing. 'The requirement lacked a clear edge case specification, and there's no review checkpoint that would have caught it' is an RCA that produces a process improvement
- When to do RCA: For every Critical/High production defect, for defect clusters (multiple defects in the same module suggesting systemic issues), at sprint retrospectives (review all defects found in the sprint for patterns), and as part of the Test Summary Report closure
Tip
Tip
Practice Root Cause Analysis RCA Techniques in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Practice Task
Note
Practice Task - (1) Write a working example of Root Cause Analysis RCA Techniques from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Root Cause Analysis RCA Techniques is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready qa engineering code.
Key Takeaways
- Root Cause Analysis (RCA) is the practice of investigating WHY a defect occurred - not just what the defect was - so that the underlying process failure can be fixed and the same class of defect prevented in future projects.
- Fishbone Diagram: Visual tool for complex defects with multiple contributing causes. The 'head' of the fish is the defect. The 'bones' are cause categories: People (training, experience, communication), Process (missing steps, unclear procedures), Technology (tools, systems, infrastructure), Environment (test/prod differences), Materials/Data (requirements, specifications)
- For each category, brainstorm contributing factors. This structured approach prevents the natural human tendency to blame the person closest to the failure while ignoring systemic causes
- RCA Process steps: Describe the defect precisely. Identify all contributing factors (5 Whys or Fishbone). Identify the root cause (the deepest 'why' that, if addressed, prevents recurrence). Define corrective actions (what process will change?). Assign owners and deadlines for corrective actions. Verify effectiveness after implementation