Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jdavidb (1361)

jdavidb
  (email not shown publicly)
http://voiceofjohn.blogspot.com/

J. David Blackstone has a Bachelor of Science in Computer Science and Engineering and nine years of experience at a wireless telecommunications company, where he learned Perl and never looked back. J. David has an advantage in that he works really hard, he has a passion for writing good software, and he knows many of the world's best Perl programmers.

Journal of jdavidb (1361)

Thursday June 05, 2003
01:40 PM

The bug report formula

[ #12638 ]

All bug reports should identify the following three items. I don't care what format they're in or what additional meta-data you want, but a bug report has to give me the following:

What did you do? What actions did you take on the system? Tell me everything; what did you click; what did you type? What menu items did you select? What was your exact input data?

What did you expect to happen? When you did this, what was the correct action of the system supposed to be? How could I check to see that that action occurred? What reports or other outputs should have been produced, and what data should be contained in them? What changes should have occurred in data stores? What response messages and codes should you have received from the system?

What did happen? What was the actual result you received? If nothing happened, say so. If you got an error message, give me the exact text of the error message. If you got wrong data in a report or database, what was the actual data you received? (You should have told me the right data in the previous question.)

Astute developers will notice that this is a freeform way of specifying a unit test. I've actually been trying to get people to give me this information for bug reports since long before I learned unit testing. It became apparent that I had to reproduce the bug, and I had to know exactly what to look for and how to know I had fixed the problem, very early on in my career as I received dozens of bug reports from people who thought I knew their jobs and software inside and out saying simply, "It doesn't work."

I spent five years at my last position getting people into the mindset to provide me this information, hopefully without making them think I was browbeating them or antagonizing them. (After all, the reason I want to get the bug report right is so I can help you and fix your bug!) Now I'm in a new environment, and I find the same universal constants hold true: what did you do? What did you expect to happen? What did happen?

Given these three questions and enough time, I feel like I can fix anything.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • That's what you want.. this is what you will (usually) hear..

    • It doesnt work
    • It doesnt work, I want you to fix it now
    • Why isnt it working ? (it could mean anything here... usually, I dont get that filed in the bug report)
    • I pressed this thingummy and my machine crashed.. it must be your application because I had it open at the time too
    • (at 0300 hrs on a Saturday night/Sunday morning, when a data transfer had failed in the background) err.. I cant query the data using your form, what's wrong with your form
    • it could mean anything here... usually, I dont get that filed in the bug report

      Man, no kidding!

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers