Quality and release
A release-readiness standard you can steal
The shape of the firm's release standard: a sectioned checklist, a severity model, a marking convention that treats a blank as untested, a GO/NO-GO gate and a regression rule. Take it.
By Brevard Nelson · · 1 min read
Most software is released on a feeling. The feeling is usually 'we have run out of time'. A release standard replaces the feeling with a decision, made against evidence, that someone signs. This is the shape of ours. It is published in full on the quality page, and the standard itself is free; what we sell is applying it.
A checklist with blocking sections
The checklist has 32 checklist sections, seven of which block a release. A blocking section that fails stops the release regardless of everything else. The rest inform the decision; they do not by themselves prevent it.
A marking convention
Every item is marked Pass, Fail, Blocked or N/A. A blank means Not Tested, and a blank blocks sign-off. N/A never means untested: it carries a reason. This one rule removes the most common way a checklist lies.
A severity model
Findings are graded S1 to S4 with evidence. S1 and S2 findings are closed, or formally waived with a named owner and a date, before a GO.
A gate and a regression rule
The pass ends in a GO or NO-GO recommendation with the exact gating list. On every subsequent pass, every previously fixed item and every security control is re-verified. A fix that is not re-tested is a hope.
The firm has run seven numbered QA passes on a single product, with fix verification and regression re-testing on each. On one of them a finding was formally withdrawn when its premise proved wrong. That is recorded too. A standard that cannot admit its own errors is not one worth publishing.