quality means meeting requirements, not maximum polish

In a project context, quality means the deliverable meets the requirements and acceptance criteria that were actually agreed to — not "as good as it could possibly be." A deliverable that exceeds what was asked for isn't automatically higher quality; if it wasn't in scope, it's gold-plating — time and budget spent on something nobody requested, at the expense of what was.

quality assurance vs. quality control

These two terms get used interchangeably in casual conversation but describe different activities:
  • Quality Assurance (QA) — process-focused and proactive. It improves how work gets done so defects are less likely to happen in the first place: coding standards, defined review processes, training, process audits.
  • Quality Control (QC) — product-focused and reactive. It inspects the actual output for defects after the fact: testing, inspection, checking a deliverable against its spec.
A simple way to keep them straight: QA is about the process, QC is about the product. A mature quality program needs both — QA to prevent defects, QC to catch the ones that get through anyway.

the cost of quality

The cost of quality framework splits spending into prevention (training, good process — keeping defects from happening), appraisal (testing, inspection — finding defects that did happen), and failure costs. Failure costs come in two very different sizes: an internal failure caught before delivery (a bug found in testing) is comparatively cheap to fix; an external failure caught by the customer after delivery is far more expensive — not just to fix, but in trust, rework, and sometimes reputation. The earlier a defect is caught, the cheaper it is to deal with, which is the whole argument for investing in QA and QC rather than skipping straight to "we'll fix what customers report."

dmaic: improving an existing process

DMAIC is Six Sigma's structured framework for improving a process that already exists and is producing defects at an unacceptable rate — it's a diagnosis-and-fix cycle, not a build-something-new methodology:
  • Define — what's the problem, and what does an acceptable outcome look like?
  • Measure — collect real data on current performance; don't rely on impressions.
  • Analyze — find the root cause, not just the symptom.
  • Improve — implement and test a fix targeting that root cause.
  • Control — put monitoring in place so the improvement holds and the old problem doesn't quietly creep back.

user acceptance testing (uat)

User Acceptance Testing is the final quality checkpoint, and it's different from everything above in one key way: it's performed by the actual end users or business stakeholders, not the project team, against real-world scenarios rather than technical specs. QA and QC ask "did we build it right?"; UAT asks "did we build the right thing, and does it actually work for the people who'll use it?" A deliverable can pass every internal QC test and still fail UAT if it doesn't fit how people actually work.

a short example

A team building a new warehouse inventory system applies all four ideas. QA: a code review checklist and a defined testing process agreed at kickoff, meant to prevent bugs before they're written. QC: the team's own testers run through the checklist before each release, finding and fixing issues internally. Weeks later, a batch of new barcode scanners keeps misreading labels; a DMAIC investigation traces the root cause to a supplier soldering defect on a specific component batch, not a software bug. UAT: before go-live, actual warehouse staff run real putaway and picking scenarios on the finished system — catching a workflow issue (a required field they'd never actually have the data for at that step) that no internal test had surfaced, because internal testers didn't know the real process well enough to hit it.

practical notes

Quality that isn't defined up front in the acceptance criteria can't really be tested for — "make it good" isn't a testable requirement; "handles 500 concurrent scans without error" is.
Gold-plating feels generous but is a quality failure in disguise: it consumes budget and schedule that belonged to the actual scope, on something nobody asked for or validated as needed.

related topics

reference