Monday, January 3, 2011

Great bug reports

Often the difference between an average bug report and a great one is whether the engineer has to spend a lot of time figuring how to see the reported behavior or if they can reproduce it immediately and find the cause in short order.

I say "short order" as recently I had such a case. The bug had been reported multiple times but none of the reports had any details that led me to the same result as the reporters were seeing. The case in question is Unhandled NilObjectException in FolderItemExtensions.$CreateAliasHandle%o%oo (#15274)
They key thing that finally, after multiple reports, allowed me to resolve the bug was a simple, clear report by one user that stated how to reproduce it 100% reliably.


This report made finding and fixing the bug a very simple task as we could see in the debugger what was going on and why this caused the exception it did. The fix required only 20 minutes once we had this information.

The key here is that user had taken the time to find the steps required to reproduce the issue very reliably and reported them.

THAT's what make s a great bug report.

Having the report of an issue is one thing but having reliable steps to reproduce the bug is great because it makes fixing the bug a lot easier.

2 comments:

Thomas said...

In fact, there's also a bug around the case when, after entering the arguments list for a method, one does an action without first hitting Return or Tab - usually the change then gets lost. I guess fixing that would have magically fixed this particular one as well :)
OTOH, I hope that now this change-committing bug is also fixed.

Norman said...

Actually it wouldn't have.
Different issues that aren't remotely related.