Process · Quality Risk Analysis

Prioritize risk before you prioritize tests.Six steps from stakeholder consensus to approved risk register.

Testing without a prioritized quality risk analysis is testing by politics. This six-step process produces a risk register with explicit stakeholder consensus, the basis for every downstream testing decision.

Steps
6
Output
Prioritized register
Compatible with
FMEA, informal QA
Any test effort that cannot point to an agreed-upon list of risks is really a test effort that nobody has agreed upon.

Key takeaways

Four things to remember.

  1. 01

    Start from stakeholders, not from features

    Identify who cares about quality and commit them to participate. Without their ideas in the room, the register is yours alone to defend.

  2. 02

    Pick the technique, then stick to it

    FMEA, informal QA, or something in between, match the technique to the team. The wrong technique picked well is better than the right one applied inconsistently.

  3. 03

    Capture incipient bugs as you go

    The analysis surfaces bad requirements, design flaws, and missing specs. File them; do not let them wait for test execution.

  4. 04

    Close the loop with configuration management

    A quality risk analysis that is not under change control is a document that will drift. Check it in and require change requests to alter it.

Why this exists

The problem this process fixes.

When the schedule compresses (and it always compresses) the test team needs a defensible ordering of what to test first, what to test less, and what to cut. That ordering is the quality risk analysis.

These six steps produce that ordering. Every subsequent decision in the testing process (estimation, case design, execution sequencing, release criteria) traces back to the register built here.

The checklist

6 steps, in order.

  1. 1

    Identify the key testing and quality stakeholders. Obtain stakeholder commitment to participate in a quality risk analysis.

  2. 2

    Survey the key stakeholders about the techniques and methods for quality risks analysis. If appropriate, propose a technique. Obtain consensus on the technique and the method selected.

  3. 3

    Gather ideas from the key stakeholders about the quality risks, the failure modes associated with those risks, the quality impact of such failures, and the priority of the risks. Identify the recommended action to mitigate each risk.

  4. 4

    Report any incipient bugs identified in other project documents during the analysis, such as bad or missing requirements, design problems, and so forth.

  5. 5

    Document the quality risks as appropriate for the technique used. Circulate the document to the stakeholders for approval. Iterate steps three, four, and five as necessary to finalize the quality risks, their priorities, and the recommended actions.

  6. 6

    Check the quality risks analysis document(s) into the project library or configuration management system. Place the document under change control.

One more thing

The quality risk analysis is the single most-cited document in a healthy test program. Release criteria point back to it. Test estimates are justified by it. Change requests are re-prioritized against it. Treat it as load-bearing.

Take it with you

Download the piece you just read.

The library is free. Tell us who you are so we can send you updated versions. One form; this browser remembers you after that.

In the library

Pair this with.

Keep reading

Related reading

Practices

Where this leads

Working on something like this?Talk to the people who wrote it.

Book a call