What must a defect report contain for someone else to reproduce and fix it?
answer
- Someone else must see it again
- Two jobs: reproduce, and decide
- Which build, which environment, which data
- Two statements, not one sentence
- Evidence: logs, traces, identifiers, timestamps
basics
~10 sAn unambiguous one-line title, the exact build identifier and environment, numbered preconditions and steps, the expected result and the actual result written separately, and evidence such as logs, screenshots or traces.
solid answer
~40 sEvery field serves one of two jobs: letting a stranger reproduce the failure, or letting a triager decide what to do without asking you. For reproduction you need the exact build string, not "latest"; the environment and data state, including whether the tier is shared; numbered preconditions and steps with one action each; and the expected and actual results as two separate statements, with the expected pointing at the requirement or rule it comes from. For the decision you need evidence - the log window around the failure, a stack trace, a correlation identifier, a timestamp with time zone, a cropped screenshot - plus enough about impact and frequency to weigh it. Before filing, search existing reports, including closed ones, for the same symptom. File the observation, not a guess at the cause.
go deeper
Be ready to list the fields from memory - title, build, environment, preconditions, numbered steps, expected, actual, evidence - and to walk through filing one small real defect using all of them.
Explain why each field exists: which ones serve reproduction and which serve the triage decision, and what specifically goes wrong downstream when the build identifier or the expected result is missing.
Show judgement about evidence: what to attach and what to redact, which identifiers make a failure findable in aggregated logs, and how you stop a shared tier from becoming an unstated precondition.
Own the cost argument - round trips, unreproducible reports and duplicate filings measured against a fixed release cadence - and be able to say which reporting habits you would hold teams to and which you would leave to judgement.
## What the report is actually for A defect report has two jobs, and every field earns its place against one of them. The first is **reproduction**: someone who did not see the failure must be able to see it again. The second is **decision**: whoever triages it must be able to judge impact and route the work without opening a conversation with you. A field that serves neither is ceremony; a missing field that serves either one is a round trip. On a 3-week release train, one "cannot reproduce, please clarify" round trip can push a fix past the branch cut and into the next train, which is why an unreproducible report often costs more than no report at all. ## The one-line title The title is the only part most readers ever see - in a triage list, in a search result, in a scan of what changed. An unambiguous title names three things: the artefact, the trigger, and the observed symptom. "Export broken" names none of them. "Points ledger export truncates at 8,192 rows when a member has more than one tier history" names all three and is findable by the next person who hits the same symptom. Prefer the system's own vocabulary - the screen name, the job name, the literal error text - over your paraphrase, because that is what someone will type into the search box. ## Build and environment "Latest" is not a build identifier. Record the exact version string of the component under test, plus anything else in the picture whose version can move: the client, the platform, the data set, the configuration flags. Record which deployed tier you were on and whether it is shared - on a shared tier, another person's actions are silently part of your preconditions, and that alone explains a great many "works on mine" arguments. Locale, time zone and clock matter whenever formatting, scheduling or expiry is involved: a points balance that expires at midnight behaves differently depending on which midnight. ## Preconditions and numbered steps Preconditions are the state the system must be in before step 1: which account, which data, which flags, which prior activity. Steps are numbered, one action each, and phrased so that two people executing them do the same thing. "Log in as a user with some points" is not a step; "Open the ledger for a member holding 4,180 points with 3 pending accruals" is. Numbering is not decoration - it lets the developer and the confirming tester say "it diverges at step 6" instead of re-describing the whole path. ## Expected versus actual Write them as two separate statements, never as one sentence joined by "but". The expected result is your oracle - the thing that says the behaviour is wrong - and it should point at its source: a requirement, an acceptance criterion, a documented rule, or a consistent behaviour elsewhere in the product. The actual result is what the system did, quoted verbatim where possible, including error text and codes. Separating them separates two different arguments: a reader can dispute your expected result, which is a requirements conversation, without disputing your observation, which is a facts conversation. Reports that merge the two tend to lose both. ## Evidence Evidence shortens diagnosis and proves you saw what you say you saw. Useful evidence is specific: the log window around the failure rather than the whole file; a stack trace or error identifier; a correlation identifier that lets the developer find the same request in aggregated logs; a timestamp with its time zone; a screenshot cropped to the wrong value but with enough surroundings to locate it; a short recording when the failure is about sequence or timing. Redact secrets and personal data as you attach. ## A worked example On build 7.4.219, the nightly accrual job for a loyalty-points ledger failed part-way through. The weak report is "accrual job crashes". The actionable one names the build, states that the job ran against the 12,400-member fixture set on the shared integration tier, gives the numbered steps that trigger a run, states expected ("all 12,400 members accrued, job exits successfully") and actual ("job aborts at member 1,873; log shows the connection pool at its ceiling of 24 with none released"), and attaches the log window plus the pool metric for the ten minutes before the abort. That report carries a diagnosis for free: it is a resource exhaustion, and the reader can see the resource. ## What makes a report worthless A report nobody can reproduce consumes triage time, is closed unresolved, and if the defect is real it comes back later with less context. Two habits prevent most of that. Search for an existing report before filing, using the symptom's own words and the literal error text, and include closed reports. And file the observation, not your guess at the cause: a suspected root cause in the title anchors everyone on the wrong component, and it is the easiest way to make a well-evidenced report useless.
- Before filing, how do you check whether the same defect is already reported?Search with the symptom's own vocabulary rather than your title - the literal error text, the screen or job name, an identifier from the trace - and include closed and rejected reports, not just open ones. Widen to the affected component if the exact wording finds nothing. When you find a match, add your build, environment and evidence to it rather than opening a second report; a closed "could not reproduce" that suddenly acquires a reliable reproduction is far more useful than a fresh duplicate.
- What do you do when the expected result is not written down anywhere?Say so explicitly in the report. State what you observed, what you believe the behaviour should be, and the basis for that belief - a consistent behaviour elsewhere in the product, an established convention, a plain user expectation. Filing it as a question about intended behaviour is legitimate. Filing it as a defect while hiding that the oracle is your own judgement is not, because triage will treat your assumption as a requirement and argue about the wrong thing.
- Why is putting your suspected root cause in the title risky?Because the title is what everyone reads and searches, so a wrong guess anchors the whole thread on the wrong component and the report gets routed to a team that cannot act on it. It also makes the report unfindable by anyone who hits the symptom, since they will search for what they saw, not for your theory. Put the observable symptom in the title and your hypothesis in the body, clearly labelled as a hypothesis with the evidence behind it.
A defect report is a recipe, not a restaurant review: the reader has to be able to cook the same dish and get the same burnt result.
saying these in an interview costs you the question
- Files a title like "it does not work"
- Says the build is "latest" instead of a version
- Writes the steps as prose with no numbering or preconditions
- Gives only the actual result and leaves expected implied
- Attaches no evidence because the failure looked obvious
- Puts a guessed root cause in the title