Defect report template
A defect report is read by two audiences. Product reads the title and the impact and decides whether it matters. Engineering reads the conditions, the steps and the evidence and decides whether it can be fixed. The template gives each of them their part.
A defect template along these lines cut the number of tickets developers sent back to me by about 40% on one programme, mainly by making the expected result and the conditions impossible to leave out.
DEFECT Title: <who> cannot <do what> when <condition> Journey: <the journey this interrupts> Severity: <blocker / critical / major / minor> — <one line of reasoning from the journey> Who and where <which users or accounts, which surface, which step> Conditions Build / environment: <...> Account and data: <role, test account, record state> Device / browser: <...> Steps 1. <the user's route, from a known starting point> 2. <...> 3. <...> Actual: <what happened, as the user sees it> Expected: <what should happen> Source: <acceptance criterion / business rule / design / previous release> Impact <what the user loses; what it costs the business; how often it happens> Workaround: <steps a real user could take, or "none"> Asking for: <fix before release / decide / clarify> Evidence: <screenshot or recording, request and response, log reference>
Free to use and adapt. No sign-up, no attribution needed.
How to use it
- Write the title so someone outside the team understands it: who, what they cannot do, under which condition.
- Give the expected result a source. Without one, the ticket is an opinion.
- Say how often it happens and for whom. “Three times in five attempts on a slow connection” is evidence; “sometimes” is not.
- If it is a suggestion and not a fault, raise it as a story or a question. Forcing everything into a defect teaches people to ignore you.
Terms used here: Defect report, Test oracle, Defect severity and priority.