How to Conduct a Failure Mode and Effects Analysis (FMEA) in QA

What is FMEA?

Failure Mode and Effects Analysis (FMEA) is a structured, systematic technique for identifying all the ways a system could fail, analyzing the effects of those failures, and prioritizing them by risk so teams can focus preventive efforts where they matter most.

Developed by the U.S. military in the 1940s and widely used in automotive and aerospace manufacturing (NASA used it for the Apollo program), FMEA is increasingly recognized as a powerful tool in software quality engineering.

The core question FMEA asks is: "What could go wrong, how likely is it, and how bad would it be?"

The Three Pillars of FMEA Scoring

Every potential failure is scored on three dimensions, each on a scale of 1 to 10:

1. Severity (S)

How bad is the impact if this failure occurs?

| Score | Description | |---|---| | 10 | Catastrophic: Data loss, security breach, complete system failure | | 7-9 | High: Major feature broken, significant user impact | | 4-6 | Medium: Feature degraded but workaround exists | | 1-3 | Low: Cosmetic issue, minor inconvenience |

2. Occurrence (O)

How likely is this failure to happen?

| Score | Description | |---|---| | 10 | Almost certain: Happens consistently | | 7-9 | High: Happens frequently, known edge case | | 4-6 | Moderate: Occasional, under specific conditions | | 1-3 | Low: Remote, rarely experienced |

3. Detection (D)

How difficult is it to detect this failure before it reaches users?

| Score | Description | |---|---| | 10 | Undetectable: No existing test or monitor would catch it | | 7-9 | Hard to detect: Only caught by specific exploratory testing | | 4-6 | Moderate: Caught by regression tests if they run | | 1-3 | Easy to detect: Immediately obvious, covered by automated tests |

The Risk Priority Number (RPN)

RPN = Severity × Occurrence × Detection

A failure with an RPN of 1,000 (10×10×10) is your worst nightmare: catastrophic, almost certain to happen, and nearly impossible to detect. A failure with an RPN of 1 (1×1×1) is a trivially low-risk issue.

In practice, focus your testing efforts on failures with the highest RPN scores.

Conducting an FMEA for a Software Feature: A Worked Example

Let's apply FMEA to a Payment Processing feature in an e-commerce application.

Step 1: Assemble the Team

Don't conduct FMEA alone. Bring together:

• The QA engineer
• The developer who built the feature
• The product manager
• (Optionally) a DevOps or security engineer

Group knowledge identifies failures that no single person would catch.

Step 2: Identify All Potential Failure Modes

Brainstorm every possible way the payment feature could fail:

1. Credit card number is stored in plain text in the database
2. Payment is charged but order is not created in the system
3. User is charged twice due to a network timeout retry
4. Payment API returns an error but user sees a success message
5. Coupon discount is applied but the amount doesn't reduce correctly
6. Payment form is accessible without HTTPS
7. Session expires mid-checkout, losing cart data

Step 3: Score Each Failure Mode

| Failure Mode | S | O | D | RPN | |---|---|---|---|---| | Card stored in plain text | 10 | 3 | 8 | 240 | | Double charge on retry | 9 | 5 | 7 | 315 | | Charged but no order created | 9 | 3 | 6 | 162 | | Error shown as success | 8 | 2 | 5 | 80 | | Coupon discount wrong | 5 | 4 | 3 | 60 | | No HTTPS on payment form | 10 | 2 | 4 | 80 | | Session expiry during checkout | 4 | 6 | 3 | 72 |

Step 4: Prioritize and Act

Highest RPN: Double charge on retry (315)

Action: Write an integration test that simulates a network timeout during payment processing and verifies idempotency keys prevent double-charging. Implement an idempotency key pattern in the payment API.

Second Highest: Card stored in plain text (240)

Action: Immediate security audit of database storage. All card data should be tokenized via Stripe/Braintree and never stored locally.

Continue down the RPN list, defining concrete actions (new test cases, code changes, monitoring alerts) for each high-risk failure mode.

FMEA in Agile Sprints

You don't need a 3-day workshop to apply FMEA. In an agile context:

• Incorporate a lightweight FMEA into your sprint planning or backlog refinement sessions.
• For each new story, spend 10-15 minutes brainstorming failure modes.
• Use a simple spreadsheet to score and track them.
• Translate high-RPN items directly into test cases in your test management tool.

Benefits Beyond Test Prioritization

• Shared risk ownership: The FMEA process forces developers, QA, and product to jointly own risk. Nobody can say "that's a QA problem."
• Knowledge transfer: The FMEA document captures institutional knowledge about why specific tests exist, invaluable for onboarding new team members.
• Compliance evidence: In regulated industries (healthcare, finance), FMEA documentation can serve as evidence that risk was systematically analyzed and mitigated.
• Continuous improvement: Revisit your FMEA after incidents. If a production bug escaped, add it to the FMEA, score it, and strengthen detection.

FMEA transforms testing from a reactive "find the bugs" activity into a proactive "prevent the most damaging failures" discipline. Start with your highest-risk feature, gather your team, and score your failure modes. The process itself — the structured conversation about risk — is as valuable as the resulting spreadsheet.