Fix-List, Retest & the 10-Minute Audit — Anti-Patterns III & Self-Test

Finding a problem is not the same as fixing it, and saying a fix is done is not the same as proving it. A fix-list, a retest, and a short audit are three simple controls that close that gap. They turn vague confidence into visible evidence: what was wrong, who changed it, how it was checked, and whether the remaining risk is acceptable.

Start with the purpose: controlled closure

Any product, service, system, or process can have defects. A defect is a gap between what was expected and what was observed. It may be a broken button in software, a missing label on a shipment, a wrong value in a report, or an unclear instruction in a procedure.

The goal of a fix-list is not to collect blame. The goal is controlled closure. Controlled closure means every known defect has one clear status: not started, being fixed, ready to retest, verified, accepted as-is, or deliberately deferred. Without that control, teams rely on memory, meetings, and optimism.

A retest is the act of checking whether a specific fix actually solved the specific defect it was meant to solve. A 10-minute audit is a short, disciplined look at the fix-list and retest evidence before a decision such as release, shipment, handover, or sign-off.

📌

First principle. A fix is a claim; a retest is the evidence that supports or rejects that claim.

What a fix-list must contain

A useful fix-list is small enough to maintain and complete enough to trust. It should answer the basic questions a careful reviewer would ask without needing to chase private messages or remember a meeting.

Each item should identify the defect, its expected result, its actual result, its severity, its owner, its current status, the change made, the retest result, and any decision to accept or defer remaining risk. The exact tool does not matter. A spreadsheet, ticket system, checklist, or quality management system can all work if the information is clear and current.

The most common failure is a list that records activity instead of outcome. Notes such as “looked at,” “updated,” or “should be fine now” do not close a defect. The list must make the condition of closure visible.

Use one identifier for each defect so conversations, fixes, and test evidence point to the same thing.
State expected and actual results in plain language, not just screenshots or error codes.
Assign one owner, even when several people help.
Separate status from sentiment; “verified” means checked, not merely believed.
Record the retest evidence close to the item, or link to it unambiguously.

Each fix-list item records the defect, its severity, its owner, and its closure status.

Severity, priority, and the trap of equal defects

Not all defects deserve the same response. Severity describes the harm if the defect remains. Priority describes how soon the team should act. A minor spelling error on a rarely used screen may be low severity and low priority. A pricing error that charges customers incorrectly may be high severity and urgent priority.

Teams get into trouble when they use one long list without sorting by consequence. Low-risk items crowd out high-risk items, and progress looks better than it is because many small items close while the dangerous ones remain open.

A simple classification is often enough: critical, high, medium, and low. The labels matter less than the shared meaning behind them. Critical should mean the product, process, or decision should not proceed unless there is a specific, documented acceptance of risk.

Critical: unsafe, unlawful, financially material, security-sensitive, or blocking the main purpose.
High: serious user impact, likely operational failure, or major rework if ignored.
Medium: noticeable problem with a workaround or limited exposure.
Low: cosmetic, rare, or inconvenient but not harmful.

⚠️

Do not average risk. Ten low-severity fixes do not cancel one unresolved critical defect.

Sorting defects by severity and priority keeps dangerous items from hiding behind minor ones.

Retest the defect, then look for side effects

A retest should repeat the condition that exposed the defect, or a better version of that condition if the original was incomplete. If a report showed the wrong total when a discount was applied, the retest must include a discounted case. If a form failed with a long name, the retest must use a long name.

After the targeted retest, the team should consider regression. Regression means a change fixed one thing but broke another thing that used to work. Not every fix needs a full system test, but every fix deserves a short question: what nearby behavior could this change have affected?

Good retest evidence is not theatrical. It can be a test result, a screenshot, a log entry, a measured value, a signed checklist, or a short note from a qualified reviewer. What matters is that another competent person can understand what was checked and why the conclusion follows.

Reproduce the defect, retest the fix, check nearby behavior, then log the evidence.

The 10-minute audit

A 10-minute audit is a short, focused review before a decision point. It is not a full investigation and not a ceremony. Its purpose is to catch obvious gaps while there is still time to act.

The reviewer asks whether the fix-list is current, whether severe items are visible, whether closed items have retest evidence, whether deferred items have an explicit risk decision, and whether any pattern suggests a deeper problem. Ten minutes is enough when the list is well kept; if it is not enough, that is itself a finding.

The audit works best when performed by someone close enough to understand the work but not so close that they are defending it. In software this may be a quality assurance reviewer, where quality assurance means the practices used to prevent and detect defects. In operations it may be a supervisor, lead technician, peer reviewer, or release manager.

Scan all open critical and high-severity items.
Sample recently closed items and confirm each has retest evidence.
Check whether any item is marked done without an owner, date, or result.
Review deferred items for an explicit reason and accountable approver.
Look for repeated defects that point to a common cause.
State the decision: proceed, proceed with named risk, or stop.

The leadership decision: ship, hold, or accept risk

The fix-list is not only a technical artifact. It supports a management decision. A leader may need to decide whether to release a product, ship an order, approve a process, accept a handover, or delay work. The list should make that decision clearer, not bury it in detail.

Three questions usually matter most. What severe defects remain? What evidence supports the claim that fixed defects are truly fixed? What risk is being accepted if the work proceeds today? If those questions cannot be answered plainly, the decision is not ready.

Practitioners face a related choice: whether to spend time polishing minor items or testing the fixes that protect the main outcome. A healthy process gives them permission to focus on risk. The point is not to close the most tickets; it is to reduce the chance of meaningful failure.

✅

Good decision. A sound release decision can include known defects if the remaining risk is visible, deliberate, and owned.

The fix-list drives one decision: ship, hold, or accept documented risk.

Common failure modes and how to prevent them

The first failure mode is ghost closure: an item is marked closed because someone made a change, not because the change was verified. Prevent it by requiring retest evidence before the status becomes verified or closed.

The second is list drift: the fix-list stops matching reality. Items are fixed but not updated, new defects are discussed but not recorded, and owners change informally. Prevent it with one source of truth and a brief daily or pre-decision cleanup.

The third is silent risk acceptance. A defect is left open because the deadline is near, but nobody says who accepted the risk or why. Prevent it by giving deferred items their own status and requiring a reason, an owner, and a review date.

The fourth is over-auditing. If every small change needs a courtroom-level record, people stop trusting the process and start working around it. The discipline should be proportional: stronger evidence for higher risk, lighter evidence for lower risk.

Key takeaways

A fix-list is a control for closing known defects, not a place to store blame.
A defect is not truly closed until a retest shows the expected result.
Severity and priority help teams focus on meaningful risk instead of raw item counts.
A 10-minute audit checks list currency, retest evidence, severe open items, and accepted risk.
Leaders can proceed with known defects only when the remaining risk is explicit and owned.
The right amount of evidence is proportional to the harm a defect could cause.

Glossary

Defect: A defect is a gap between what was expected and what was actually observed.
Fix-list: A fix-list is a tracked set of defects, owners, statuses, fixes, retest results, and closure decisions.
Retest: A retest is a check that a specific fix solved the specific defect it was intended to solve.
Regression: Regression is a new or returning failure caused by a change that was made to fix something else.
Severity: Severity is a judgment of how much harm a defect could cause if it remains.
Priority: Priority is a judgment of how soon a defect should be addressed.
Owner: An owner is the person accountable for moving an item to its next clear state.
Audit: An audit is a structured review of evidence against a defined expectation.
Quality assurance: Quality assurance is the set of practices used to prevent defects and confirm that required work has been done.