BVTs: infrastructure from the stone age
News, Technical, Work ·Tuesday August 25, 2009 @ 19:18 EDT (link)
Whenever I get assigned a "BVT Blocking" bug (BVT is some sort of test—maybe Basic Validation Test?), I assume I'm going to lose a day of work. The infrastructure for investigating is so baroque and poorly coordinated that even if test is kind enough to hand over a held machine (or two, in the case of co-authoring client-server tests), if it's not possible to verify the problem on that machine, the window is gone, and it'll take another few hours to hold another one. Of course these bugs never repro deterministically on a regular machine (or at least test doesn't attempt to do so without encouragement).
So it was unfortunate that I got assigned two BVT bugs today (one of which I passed on to EB; he was in later than usual), plus another "half" bug which involved a memory leak that another group whose name looks a lot like UEX was trying to pin on us (nice try; investigate your own object leaks, until you can show Word's leaking it; this object had a reference count in the 300s under normal use, so finding a missing Release is a needle-in-a-haystack exercise; I had AddRef and Release dump callstacks whenever they were called, and it didn't seem like co-authoring was doing anything untoward so I passed it back with my compliments). Anyway, back to the original bug: it did at least have symbols, but no sources. And apparently they can't hold crash bugs. So it was just sitting in WinDbg with a "trace" file, whatever that is. I can certainly understand using gdb or dbx in a Unix command-line environment (I'm familiar with both), but in an environment where most developers' standard environment is Visual Studio, for the !@#%ing love of all that is holy, provide a Visual Studio remote debug connection at the crash or assertion point, with the correct sources and symbols: that's all I ask. For now. Later on, they can work on making a "scenario" a less inscrutable pile of opaque excretions and make it easier to run and debug on a local machine.
I do hear interesting things about something called iDNA, though, and plan to see what I can learn about that. (There doesn't seem to be much else about it on the web, so I won't go into detail about what it is in case it's proprietary.)
Since I'm ranting, a certain project area with which I am involved (mentioned once already in this note) has turned into a real pig's breakfast. Word is a cranky old application to begin with, but it doesn't help to add to it a horrible mess that rhymes with Smirkspaces. I pray this whole kit and caboodle doesn't go the way of past attempts at collaborative authoring.
I was happy this morning. I was envisioning plowing through a stack of bugs, since finally the broken servers started to work better (than last miserable week); I had a decent build on both machines; things were looking up, bugs were to be slain, progress was to be made, and… a BVT bug landed on my plate and I lost a day.
All pigs saddled and ready to fly. May tomorrow be a better one.
