Writing a Software Bug Report
When reporting bugs, please follow the format and criteria below. Each report should contain the following information:
- Bug Description
- System Information
- Reproduction Steps
- Expected Result
- Actual Result
- Additional Notes
Provide a very descriptive title for your bug that details the unexpected behavior. The bug description should be used as the title when creating a new bug topic.
- Software version and build
- Computer OS version and build
- Storage media brand/type (USB/SD card brand, speed, size) *if relevant to bug
The exact steps required for a bug to be reproduced consistently. This must be direct with no superfluous steps listed as order of operations. This is vital in determining if something can be reproduced. Consider including screenshots or video of the bug to help support your report.
Example of a good repro:
- Open Engine Prime.
- Load track from a Crate to Deck 1.
- Click Loop options menu button.
- Set loop size to 8 beats.
- Click the word LOOP to set loop region.
- Switch from HOT CUE to LOOP pad mode.
- Click unused loop pad 1 to save active loop.
The example above outlines in detail, the required steps that lead to the bug behavior.
Example of a bad repro:
- Load a track.
- Set a loop.
- Save the loop.
The example above fails to outline important details required to easily reproduce the bug behavior without requesting further information.
What should actually be happening if everything is functioning correctly?
What improper state or behavior is being displayed by the application?
How often do you encounter the bug behavior? Every time you perform the repro, 3 out of 10 times. A bug that cannot be reproduced cannot be fixed. Please consider this before posting a topic for a bug you cannot reproduce easily.
Are there any caveats for this to occur. Does it only happen after first install/boot? Does it only happen if this 3rd party device is connected? etc…
Please Consider the Following When Writing Bugs
Make sure that the reproduction listed is the simplest way to encounter the issue. If your repro has many steps, try to find the simplest scenario in which the bug occurs before posting the issue.
Provide as much information as possible in the initial bug post. Try to avoid anyone having to ask questions about the bug.
Write additional repros in the comments of a bug topic. This leads to the bug post becoming large and its purpose shifting. This makes it incredibly difficult for developers to resolve the issue and for testers to pass or fail the issue in the future. Assume that what caused one issue causes another, leave it to the developer to determine whether the bugs are actually the same as one another.