Who should sign off that a defect is fixed, and what makes that sign-off a rubber stamp?
answer
- A closure is a claim about a build
- Not the person who wrote the fix
- Run the original steps, not a paraphrase
- Check what the fix touched nearby
- Reopen rate exposes hollow closure
basics
~20 sSomeone other than the author, who reproduces the original steps against a build containing the fix and records what they saw. It becomes a rubber stamp when the approver only reads the change description, never runs the case, and approves in seconds.
solid answer
~50 sClosing a defect is a verification act, not an administrative one. The person who closes it should be someone other than the author, working from the **original reproduction steps** against a build that actually contains the fix, and should also check the immediate neighbourhood the fix touched — a fix that stops a wrong value often creates a new wrong path. Whoever closes it records what was run and where, so the next person can tell verification from assertion. Two decisions must not be confused with it: **deciding not to fix** is a product risk decision, not a tester's call, and **reopening** must stay available to anyone who reproduces the symptom. The rubber-stamp signals are recognisable: approvals seconds after the request, whole batches closed at period end, closure by someone with no access to the environment, and a closure note that says only "fixed".
go deeper
Be ready to say that closing a defect means someone other than the author reproduced the reported steps on a build with the fix and wrote down what they saw. Knowing where your team records that is enough at this level.
Explain the mechanics: the original steps, the right build and environment, a check of what the fix touched nearby, and a closure note specific enough that a future reader can tell verification from assertion.
Show that you read closure patterns structurally. Point at approvals arriving in seconds, batch closure at period end, or a rising reopen rate, and trace them to the pressure or missing access that produced them.
Own the incentive design. Be ready to argue why an open-defect count as a reported target manufactures rubber-stamping, what you would report instead, and where the authority to accept a known defect properly sits.
## Sign-off is a claim, and claims need evidence When someone closes a defect they are making a public claim: *this symptom no longer occurs in a build we are shipping*. The whole value of the claim lies in the evidence behind it. Ownership models differ in who is entitled to make it, but not in what makes it true. ## Who should make the claim **Not the author alone.** Not because authors are dishonest, but because an author verifies against the model in their head — the same model that produced the defect. The author knows what they changed, so they check what they changed. A second person works from the report, which is what the user actually experienced. Who that second person is depends on the model. With an independent group, a tester from the group closes it. With an embedded tester, that tester closes it. With whole-team quality, another engineer on the team closes it, which requires an explicit convention or it silently becomes self-closure. A coaching function should not be closing defects at all — doing so turns an enabling group into an approval queue. The reporter deserves a distinct role. When a defect came from a support channel or from another team, the reporter is often the only person who can confirm the real-world symptom is gone, and closing without telling them is how the same defect gets reported three times. ## What honest verification involves Four elements, all cheap: 1. **The original steps, not a paraphrase.** Verification runs the reproduction from the report. If those steps were never good enough to reproduce with, that is the first defect to fix. 2. **A build that contains the fix, in an environment that matters.** Surprisingly often a defect is verified against a build that does not include the change, or in an environment configured differently from the one where it was seen. 3. **The neighbourhood, not just the symptom.** Ask what else touches the code path. Consider a quote engine for insurance policies where a retried submission wrote the applicant's quote record twice: the obvious verification is that a retry now produces one record. The neighbourhood question is what the deduplication does to a customer who legitimately requests two quotes in the same minute, and whether anything downstream already counted the duplicate. 4. **A note that says what was checked.** "Reproduced the original steps on build 7 in the shared environment; single record written on retry; also checked two legitimate quotes in one minute still produce two." That sentence is the difference between verification and assertion, and it is what a future reader needs when the symptom returns. ## Decisions that are not sign-off **Deciding not to fix** is a business risk decision. A tester can and should state the technical impact and how a user encounters it, but choosing to live with a known defect belongs to whoever owns the product outcome. Testers who make that call absorb accountability they were never given; product owners who make it without hearing the impact are deciding blind. **Severity and priority** are separate axes and confusing them corrupts closure. Technical impact is one judgement; business urgency is another. A cosmetic defect on a signup path can outrank a crash in an unused administrative screen, and vice versa. **Reopening** must stay open to anyone who reproduces the symptom, including the original reporter. An organisation where reopening requires permission will get quiet reports of "the old problem, again" instead. ## How sign-off degenerates into a rubber stamp Rubber-stamping is what happens when the ceremony outlives the verification. It is recognisable by pattern, not by intent: - Closure moments after the request, with no time to run anything. - Batch closure at the end of a period, often driven by a target for open defects. - Closure by someone with no access to the environment or the build in question. - Closure notes containing only "fixed", "works now" or a change reference. - The same defect reopened repeatedly, which is the strongest evidence available. The causes are structural rather than personal. If the number of open defects is a reported target, closing becomes the goal. If sign-off is the only remaining gate before a deadline, pressure lands entirely on the approver. If the approver cannot reach the environment, the only thing they *can* do is read the description. Fix the structure: give approvers access and time, stop reporting open-defect counts as a scoreboard, and track reopen rate, which measures the quality of closure directly and is much harder to game than the count of things closed.
- Your team practises whole-team quality with no dedicated tester. How do you keep defect closure honest?Make the second pair of eyes explicit, because without a convention closure quietly becomes self-closure. Require that someone other than the author runs the reported steps and writes what they saw, keep the reporter in the loop when the defect came from outside the team, and watch the reopen rate rather than the number closed. The discipline, not the role, is what was doing the work.
- Who decides that a known defect ships unfixed?Whoever owns the product outcome, informed by a clear statement of technical impact and how a user meets it. A tester supplies that statement and can escalate if they think the risk is misread, but taking the decision themselves means absorbing accountability nobody delegated to them. The decision should be recorded with its reasoning, because the next person to meet the symptom needs to know it was chosen rather than missed.
- What single measure best exposes rubber-stamped closure?Reopen rate: the share of closed defects that come back with the same symptom. Closure counts and open-defect totals both improve when people close things carelessly, so they cannot detect the problem they are caused by. Reopen rate gets worse instead, and it is hard to game without simply refusing to reopen — which is itself a visible and diagnosable behaviour.
saying these in an interview costs you the question
- Lets the author of the fix close their own defect
- Verifies against a paraphrase instead of the reported steps
- Closes without confirming the build contains the fix
- Treats deciding not to fix as a tester's call
- Reports open-defect counts as the closure scoreboard
- Confuses technical impact with business urgency when closing