bugs

Microsoft's Bug Flow Process

Abstract

I don't use Microsoft software at home. But sometimes I am forced to use it through work.

I won't list the bugs I have found, because they are generally ridiculous and they are, more importantly, oh so easy to find. So there's no bragging rights to finding a bug in a Microsoft product.

As anyone in software knows, there is a proper way to handle bugs.

Unsuprisingly, Microsoft does not do it this way. And every single time I've reported a bug to Microsoft, they've handled it exactly the same, ridiculous fashion.

How A Bug Flow Should Work

The regular bug flow is pretty simple. Feel free to skip this if you know how bugs are managed.

When a bug is reported, then a "bug" is opened in your list of bugs so that the bug can be tracked. The first step is to verify that it's an actual bug. Plenty of "bugs" can be things like user error or a misunderstanding of the tool. But if a bug is reproducible (there are steps that can make it happen every time), then it's easy to determine if it's the tool's fault or if the error lies somewhere between the keyboard and the chair.

If the bug is a user error, it gets closed as "not a bug". Otherwise it stays open so it can be tracked and fixed.

Once a bug is determined to be an actual bug, then it goes through various open stages such as "fixed - pending verification" until finally the fix gets to the user (such as through a software update) where it can finally be verified as fixed and then the bug is closed. Hallelujah, we fixed a bug!

Microsoft's Bug Flow

Microsoft has invented a ridiculous bug flow that has ensured they will have a monopoly on the stupidest software bugs in the world.

I have had to report a variety of bugs to Microsoft on a variety of different products, and this is, UNIVERSALLY, how they have reacted exactly ONE HUNDRED PERCENT of the time. (No seriously - including the repeat of the first step at least three times - it makes me think they have a script to help avoid bugs actually getting reported)

Dave finds a bug, and, as a verification engineer, properly documents the reproduction steps as well as a screenshot or video showing the exact failure. Dave sends the bug to MS.
Microsoft: "Please send us a screenshot of the failure"
Dave: Sends another screenshot showing the failure"
[Time passes]
Microsoft: "Please send us a screenshot of the failure"
Dave: Sends another screenshot showing the failure"
[Time passes]
Microsoft: "Please send us a screenshot of the failure"
Dave: Sends another screenshot showing the failure"
[Time passes]
Microsoft: "Please send us a screenshot of the failure"
Dave: "NO. You have them. Just fix the bug."
Microsoft: "Please explain why this is a bug"
Dave: "I already have. Look at the screenshot I've sent you three times."
[Lots of time passes]
Microsoft: "You are correct, this is a bug. We will look into it."
[Lots of time passes]
Microsoft: "We have verified that this is a bug. We will fix it some day. Can we close the bug now?"

Wait, what? First of all, nice job forcing me to send the same info over and over, but now that you know it's a bug, you want to close the bug even though it's not fixed and you don't even know if it will ever be fixed? And most comically, you're asking me if that's okay? I mean, no, no it's not okay. That's not how you fix bugs. But you do you, Microsoft, so I don't really care if you close the bug, since you're not going to do the right thing anyways, but it's comical that you want me to tell you it's okay to do it the wrong way.



Back to DaveSource Bugs