What I’m learning about Microsoft’s bug management logic

I’d like to think I’ve gained a fair bit of experience and knowledge of the way the guys at Microsoft like to deal with bugs and the like.

The Software

Microsoft Connect is a clunky, archaic piece of bespoke software that can be a pain to use. First off, its seriously slow for bug tracking software which can leave you frustrated and wishing the IE team just looked at some specific external bug log pages instead of making you jump through hoops to get a bug logged. Secondly, I have a gripe with the Feedback landing page- I despise the bug ticket ‘tooltip’ which displays most of the meta data associated with the bug. Yes, it’s useful to have access to that information without having to wait 5 minutes while the bug page loads, but the performance of those tooltips is absolutely dreadful. Intuitively you have to hover over a link to display the relevant tooltip, but it depends in what area of the link you hover over as to how long it takes to appear; the worst situation (which I have experienced many a time is when the hover behaviour gets into an apparent never-ending ‘cycle’ where the cursor type changes from pointer to cursor and back again every half a second or so. And please Microsoft, get rid of that annoying tooltip fade-in effect – I don’t care for pretty Javascript effects when I’m logging bugs.

It’s all about the small things…

When you come to file a new bug, you’re presented with a number of irrelvant questions (relating to a CSS/HTML bug, for example); “What language of your browsers frame?” (what does that even mean?), “What is your language preference order?”, “How often does this happen?”, etc etc. I’d suggest to Microsoft that they tailor that form page based on the criteria given in some of the initial questions. It’s not a case of it being confusing; it’s just a pain to answer these mandatory questions.

Another one of my pet hates is to do with the individual bug page once you’ve filed the bug (including speciying a test case URL). Although you’re encouraged to visit this URL, for some silly reason it’s outputted as plain text, meaning you have to copy and paste the URL string into your browser – please, please Microsoft transform it into a link!

Once you’ve filed your bug, you’re unable to edit your description.

Communication between developers and the IE team (or lack of)

One of the surprises I came across when I first signed up was to do with the Opacity property ticket. I was never really expecting IE8 to support this property (and indeed they’re not going to be), however I was alarmed at the fact that they so quickly closed the ticket as ‘Closed by Design’, and then later ‘Postponed’. At the time of this status change, there was little to no word from the IE team as to what they were planning on doing in relation to Opacity (or emulating it, at least), hence why there were so many frustrated developers leaving comments on the ticket. Although the original author of the ticket wasn’t completely clear as to the meaning of the ticket, myself, and I’m sure most others were clear it related to the Opacity effect in general, not the actual property itself. This was apparently something that the IE team didn’t understand as can be read in a subsequent comment left on that ticket.

Back to my original gripe

Something I’ve stated in the past, is the fact that the IE team chose to stage a closed Beta program as opposed to an open one. I have no idea on how many testers Microsoft let in to the program, but one thing is for sure – it’s had a detrimental impact on the time it takes to find bugs, hence why we have layout bugs being shipped in a last-minute, closed RC1. Thankfully many people who weren’t able to join this program (for whatever reason) still posted links to either their own sites or sites they had spotted whilst surfing which include obvious layout bugs; this sort of participation is still a real help to us testers, since I’m more than happy to examine the bug and create a reduced testcase to send to Microsoft.