I went into another tester's office yesterday to get some information about a project we are tracking. He keeps this information in a notebook (not shared, which is why I was there) and was using a new build of OneNote on his dogfood machine. He tried to open the page with the information and OneNote hung. At this point, we have an expectation of people who use our products in dogfood and that expectation is to "report the bug when you find it."

So instead of getting me the information, he had to stop his work and gather the information needed to track why OneNote was hanging. To do this, he had to launch a debugger (for this one particular task, we have a tool based on WinDBG to do this for us), attach it to the hung process and get a memory dump of the state of OneNote. Since we have the tool already, this is mostly automated and takes about a minute to three, depending on the computer and network speed. Once he got this information, he added all the information he had about what he and OneNote had been doing before hitting the hang - this took about a minute for him to type it in. Then he copied the files to a file server we have dedicated to holding these and the file copy took about two minutes or so. Add that up, (and he still has only gathered data and not entered a bug in our database) and we've spent about five minutes. It sounds like a short period of time when I write it, but when you are actually being blocked from getting your "work" done, it feels like an eternity.

I put "work" in quotes because he actually has two jobs. One is to track the status of the project I was asking for and the other is to report bugs in our products. Sometimes it feels these tasks don't have equal priority, or using dogfood software gets in the way of getting a job done, to which I always reply: "What's the bug number of the blocking bug?" This ensures we actually track the problems we see day to day.

Once he had all that information (long story short: the network was acting up and not connecting him to his notebook) he killed the hung OneNote process and restarted. And naturally, OneNote crashed. Again, he had to go through all the steps above to get the memory dump, collect associated files which now includes his OneNote cache file, a list of notebooks he had open and the number of the crash if he uploaded the data to the Microsoft website. Allowing for more file copy time, searching for two potential duplicate bugs before entering the bugs and actually entering them, he will probably spend 15-30 minutes total making these bug reports.

That's up to half an hour of his workday devoted to entering tracking these two bugs. Looking forward to testing the fixes for them, he will need to save the machine state (in this case, the cache is likely enough) to be able to verify the fix prevents the crash and leaves OneNote in a healthy state.

All in all, this is a pretty big amount of time he is on the hook to provide. And remember, this all started because I asked him about the status of a project at the same time as the network "acted up." Had I been a minute or two earlier or later, we may have missed this problem and not discovered it for several weeks. But he hit it yesterday and was diligent with reporting it and owning the resolution. He's been testing for a while here and had a good attitude about his. His laughing comment was "Well, I was actually going to get some work done on this other project I had but I guess I'll spend this morning tracking down some bugs instead!"

And that is exactly why we are here.

Questions, comments, concerns and criticisms always welcome,

John