Quality Assurance

The Four Types of Quality: Who Owns What and Why QA Gets Blamed

Published • Apr 2022 • 6 min read

If you are doing QA on any healthcare product (anything from ECG workflow software to clinical decision support to device-adjacent dashboards), you already knew this truth the hard way: everyone says "quality," but they're pointing at different targets. That mismatch is where defects hide, timelines slip, and the riskiest failures happen.

Developer productivity research (the kind that looks beyond "how fast did we ship?") pushes the same message: speed matters, ease matters, but quality is the slippery one because it's multi-stakeholder andmulti-layered. A single "quality score" is fantasy. Better approach: break quality into distinct lenses, then deliberately connect them.

Why does it matters?

Actually in any context, "quality" isn't just "no bugs."

  • A minor UI bug might be annoying in a social app.
  • The same bug in a healthcare workflow might mislead a clinician, distort trend interpretation, or delay action.
  • Even when patient harm doesn't occur, you still risk compliance failures, audit gaps, and loss of clinical trust.

So your QA strategy in 2022 should do two things at once:

  1. Protect the patient + clinician workflow (product reality).
  2. Protect the engineering system that keeps evolving (delivery reality).

That's where the four-lens model becomes useful: process quality → code quality → system quality → product quality (each lens has different owners, metrics, and failure modes).

Velocity is not the goal - safe learning speed is

Yes, teams can “go faster” by cutting reviews, skipping regression, or shipping without hardening. That's not velocity; that's technical debt acceleration.

Real productivity work argues for multi-dimensional measurement, because a single metric incentivizes dumb behavior. The SPACE framework is a strong anchor here: it explicitly warns that productivity cannot be reduced to one number and pushes a balanced view across outcomes, flow, and wellbeing.

In a healthcare project, that warning matters more: your "faster" cannot mean less safe.

Four Lenses of Quality

  1. Process Quality (how work gets done)

    2. Definition in your world: Are we building the right thing, the right way, with evidence? This is where regulated teams win or lose quietly:

    • requirements clarity (clinical intent, contraindications, edge cases)
    • risk management traceability (hazards → mitigations → tests)
    • review discipline (clinical review + technical review)
    • release readiness criteria that don’t crumble under pressure

    QA implication: your test strategy isn’t just test cases. It’s proof of control.

    What to measure (practical):

    • requirement volatility vs escaped defects
    • test coverage mapped to risk (not “% of code”)
    • defect aging in “clinical-critical” categories
    • audit readiness completeness

    If your process quality is weak, your test execution becomes performative theater: lots of activity, low assurance.

  2. Code Quality (maintainability that prevents future clinical risk)

    3. Definition in your world: Can the team change logic without accidentally breaking patient-impacting behavior? Code quality isn't about aesthetic elegance. It's about:

    • testability and deterministic logic (especially for calculations, thresholds, alert rules)
    • readability and reviewability (so clinical intent doesn’t get lost in spaghetti)
    • controlled complexity (so “quick fixes” don’t become latent hazards)

    Research on developer productivity backs the intuition that better perceived code quality supports productivity (and therefore safer iteration cycles).

    QA implication: push for:

    • contract tests around clinical rules
    • unit tests where rounding, units, thresholds, and conversions live
    • “no silent changes” policy on clinical logic (change must include updated test + rationale)

  3. System Quality (the software behaves under real-world constraints)

    4. Definition in your world: Does the system hold up in clinical reality? This is where healthcare products get hit:

    • performance under peak load (clinic day rush, batch imports, device sync windows)
    • reliability and recovery (partial data, dropped connections, retries)
    • interoperability correctness (HL7/FHIR-ish mappings, time zones, unit normalization)
    • observability (can you detect drift, missing data, failed transmissions?)

    QA implication: don't treat performance testing as "nice to have." In cardio workflows, latency can become clinical friction, and clinical friction becomes workaround behavior (which becomes untraceable risk).

  4. Product Quality (the thing the clinician experiences, and the patient depends on)

    5. Definition in your world: Does it deliver safe, usable, trustworthy outcomes? This includes:

    • usability under time pressure
    • clarity of critical information (alerts, trends, abnormal flags)
    • correctness of interpretation support (no misleading defaults)
    • post-release monitoring signals (what happens after deployment)

    QA implication: your acceptance criteria must include clinical context, not just UI behavior:

    • "What does the clinician infer from this screen?"
    • "What happens if data is missing or delayed?"
    • "Could this interaction cause a wrong decision?"

Done reading this sample?

Go back to my Articles page to find topics that might be of interest to you. Let me know if you want me to write about something specific.

Back to article archive