Learning Objectives
By the end of this lesson you will be able to:
- Explain what a post-mortem analysis is and when it is conducted
- Apply the 5 Whys technique to a real date-handling incident
- Distinguish root cause from symptom and contributing factor
- Understand the goal of post-mortem analysis in a QA context
What Is a Post-Mortem Analysis?
A post-mortem analysis (also called an incident review or retrospective) is a structured examination conducted after a production incident, bug cluster, or significant test failure. Its purpose is to understand not just what happened, but why — and to identify actionable changes that prevent recurrence.
In QA, post-mortems are typically triggered by:
- A production bug that reached end users
- A critical bug that was not caught by the existing test suite
- An incident that caused data loss or system downtime
The output is a written document — the post-mortem report — that captures the timeline, the root cause, contributing factors, and follow-up actions.
Root Cause vs. Symptom vs. Contributing Factor
These three terms are frequently confused:
- Symptom: the observable effect — what users or testers saw. Example: "The API returned 500 errors for bookings with start dates in European format."
- Root cause: the single deepest reason the problem could occur. Example: "The API accepted date strings without specifying a parsing locale, defaulting to US format on the production server."
- Contributing factor: a condition that made the problem worse or more likely, but was not the sole cause. Example: "The development server used a different default locale than the production server, masking the bug during testing."
A good post-mortem reaches the root cause, not just the symptom. Fixing only the symptom leads to recurrence.
The 5 Whys Technique
The 5 Whys is the most widely used tool for reaching root cause. You start from the symptom and ask "Why?" repeatedly until you arrive at a cause that, if fixed, prevents the problem from recurring. The technique is named for the typical depth required — five iterations — though some issues require fewer or more.
Applied to a real date-parsing incident:
Problem: The production API returned 500 errors for booking requests submitted by users in Ukraine.
Why 1: Why did the API return 500 errors? → It threw an unhandled DateTimeParseException.
Why 2: Why did it throw a DateTimeParseException? → The date string "14.11.2024" (day.month.year, European format) could not be parsed by the parser expecting "yyyy-MM-dd".
Why 3: Why did the parser expect ISO 8601 when Ukrainian users send European format? → The API had no locale-aware date parsing and accepted any string without validating the format first.
Why 4: Why was locale-aware parsing not implemented? → The original requirements did not specify supported date formats, and the development team assumed ISO 8601.
Why 5: Why was this assumption not caught in testing? → The test suite only used ISO 8601 date strings; no test used European or locale-specific formats.
Root cause: The test suite lacked locale-format coverage, and the requirements did not specify expected date input formats.
Fix: Define accepted date formats in the API contract, add validation, and add test cases for European and Ukrainian date formats.
What to Do With a Root Cause
Identifying the root cause leads to two categories of action:
- Corrective action: fix the immediate bug (add format validation, return 400 instead of 500).
- Preventive action: prevent the class of bug from recurring (update API contract to specify formats, add locale-format tests to the regression suite, add a date-format lint rule).
Preventive actions are what give post-mortems their value. A post-mortem that only fixes the symptom produces the same type of bug again in a different feature.
Summary
Post-mortem analysis is a discipline of asking "why" until the answer is deep enough to be actionable. The 5 Whys technique turns an observed production failure into a systematic root cause that, once addressed, prevents an entire category of bugs — not just the single instance that triggered the investigation.