Trying to figure out what's broken when someone reports a bug can sometimes be one of the biggest pains for a software developer. Helpful information can be few and far between and it could be a lot better. Ralph Schindler has a new post to his blog today to show how you can create a good, helpful reproduction script that can make the live of the project's developers much simpler.

"There is a problem with component Fooey-Bar-Bazzy, I think it's related to Nanny-Nanny-Neener. Please Fix Now." If you've written a bug/issue report like that in the past with no other details - shame on you! This may come as a shock, but as great as some developers might be, they cannot read minds.

He recommends a few things that can help make your report clearer - listing out your assumptions, creating a short use case, documentation on expected and actual results and how to make the script as generic as possible. To further illustrate, he also includes a sample reproduction script for a Zend Framework bug based on this issue with plenty of commenting, reproduction code and setup/assertion methods to show where the problem lies.

Using this method does not only make it easier for the developers to find the bug, but it also means that the person finding the bug doesn't have to know the internals of the application to point out where the issue lies.