Writing a report someone can act on.
WHAT A DEFECT REPORT NEEDS
A title describing the problem Steps to reproduce, exactly What happened What was expected The environment and version Evidence
WHAT MAKES A TITLE GOOD
Specific enough to identify the defect in a list.
WHAT MAKES ONE POOR
"Does not work", or a description of the screen rather than the problem.
WHAT MAKES REPRODUCTION STEPS GOOD
Starting from a known state Every action listed No assumed knowledge The exact data used
WHY EXACT DATA MATTERS
Many defects depend on specific values.
WHAT TO STATE ABOUT EXPECTATION
Why that was expected: a requirement, a convention, or an inconsistency.
WHY
Otherwise it may be a disagreement rather than a defect.
WHAT EVIDENCE TO ATTACH
Screenshots or recordings Error messages, in full Relevant log extracts Request and response detail, where applicable
WHAT TO ESTABLISH BEFORE REPORTING
Whether it reproduces Whether it is already reported Whether it is environment-specific
WHAT TO INCLUDE IF IT IS INTERMITTENT
How often, and under what conditions it seemed to occur.
WHAT TO NEVER DO
Report several problems in one item.
WHY
They cannot be triaged, assigned or closed separately.
