What you add
The automatic record shows what was run, not what was seen. That part is yours, and whether a report is accepted mostly rests on it.
What you attach
Screenshots and recordings
The moment the bug shows. A recording is preferred, because it also shows the two steps before it.
Log files
Console output, application logs, and for embedded work the serial console dump. Uploaded as raw files, not as screenshots of them.
Reproduction steps
Clear enough for someone else to reach the same result. Expected and actual behaviour written separately.
A photo of the device
For embedded work, the device and its serial number. Where a physical measurement is asked for, a shot of the measurement itself.
What accepted reports have in common
Most rejected reports are rejected for thin evidence, not for testing the wrong thing. Testers with high acceptance rates tend to do these:
- Leave a short note on cases where nothing was found
- Start the recording before the bug and cut it after
- Upload the log uncut, and point at the relevant line separately
- Write the expected behaviour in the job's own words
Limits
A single file can be 200 MB and a report 2 GB in total. A screen recording is enough for video; raw camera footage is only asked for in embedded work. Screenshots containing personal data have to be masked before you upload them.
Get the first report right
Once you are approved we walk you through a sample report and what goes where.