The value of repro steps and why you should care

Scott Oseychik — Fri, 22 Aug 2008 13:28:00 GMT

I'm gonna skip right over the Tier 1 & Tier 2 troubleshooting stuff, and get into the meat. When an issue lands on my plate, more often than not, it means I have to debug something (and as dry as that sounds, I truly enjoy my job). On top of that, 99% of the time, it's code I've never seen before. So in order for me to isolate where the problem lies, I need a [fairly] consistent path of execution that I can focus on. Otherwise, I'm performing the debugging equivalent of a car salesman randomly trolling the lot looking to fill his monthly quota.

The ability to reproduce the bug not only allows me to narrow my scope and get to the bug quicker, but it gives the Test team concrete steps to use to validate the bug was fixed properly. Oh, and let's not forget the reason we're all here: resolving the customer's issue.

Here's a small example of "Good Repro Steps" (which include both Actual and Expected Results):

1. Start > All Programs > SomeBuggyApp

2. From the File menu, select, Add New ..., then select Participant

3. Enter an e-mail address that contains an underscore (for example: doogalis_bigglesworth@thethird.com)

Actual Results:

SomeBuggyApp will crash, and the following event will be logged in the Application Log:

"Event ID 0; Something went crazy wrong here."

Expected Results:

As per RFC, SomeBuggyApp should properly handle e-mail addresses containing underscores

And now for the "Horrible Repro Steps" ...

Launch SomeBuggyApp and it'll crash

I guess what I'm asking for is that when bringing me an issue, you (the Customer, Engineer, Dev, PM, etc.) supply very specific steps to reproduce the exact problem you're having. I know it sounds like an obvious request, but there are many misconceptions around what we can and cannot do. One thing I definitely can't do is fix a bug I can't get to.

I've worked with many silly geese in my career, and along the lines of this post, here are some of my favorite quotes from 'em:

Silly Goose #1: "Can't you just attach a debugger and fix my problem?"

No, and unfortunately, it would take too long for me to explain why not. Let me put in terms we all understand: you've got a better chance of taking down Chuck Norris.

Silly Goose #2: "How about just reading the code and figuring it out that way?"

This approach might fly if all we shipped was HelloWorld.exe, but more often than not, we tend to have more than five lines of code in the products we ship.

Silly Goose #3: "It crashed, and I gave you a dump file. What more do you want from me?!"

Give me your tears, gypsy. Actually, the crash dump file is quite good, and you gave me a starting point. But if this is going to get fixed, we need to know the series of events that lead up to this.

Silly Goose #4: "But I even gave you a Time Travel Trace file! C'mon ... that should have everything you need!!"

Sure, it might have the info I'm after, but without any breakpoints, background, or context to at least give me a starting point, your expectations are ridiculous. At a minimum, give me SOMETHING from the trace logs, eventvwr, etc. Without data to key off of, you're accomplishing two things: frustrating me *and* getting your name added to my whiteboard's "Noob Blacklist."

Scott Oseychik : repro debugging

The value of repro steps and why you should care