When a bug is confirmed and reported, it will be entered into our work item database and everyone got its own list of bugs to track and fix. There are two primary product cycle management system in Microsoft, one is our internal and legendary Product Studio (or PS), another is Team Foundation Server (or TFS) and it's what I am working at. As a team member of TFS, it is no secret that we use TFS as primary SDLC system and we dogfood the latest bits as well. (Dogfood means "eat our own food", or in other word, we use the system we are building. If we break it, we fix it.)

Bugs are tracked in TFS and nomatter if it's a real bug, or just annoying thing we found, we will file it as a bug with different severity and priority. So bug count is always high and we will try our best to keep it low. Some of you may heard rumors about the Vista bug count is 10,000+ in late 2006, but don't panic, many of they may not be a real bug.

When a bug is filed, someone will assign it to a dev for investigation and fix. If the cost for fixing the bug is high (i.e. fixing the bug may break backward compatibility), dev will discuss with program manager (PM) if the bug should be fixed or postponed.

After a bug is fixed and before checking in, we will shelve the changes and ask for some buddies to do a code review. This process reduce the chance that new changes will introduce any artifacts and ensure code integrity. Afterward, we will inform the QA owner of the bug and let him/her know about the changes. Depends on the changes, devs will then do a kinda full-scale test on his/her changes to ensure everything is still in a consistency state.

First, devs will get the latest bits along with shelved changes, compile all the stuff and make sure nothing break. Then we will then run unit tests to make sure new changes don't break other components. While running unit tests (as it may takes a long while), devs will send their bits to a scouting machine to do scouting. Scouting is a manual QA process to play the bits and see if any abnormal behavior is noticed.

So after a half day long of testing, devs will then check-in their changes. Since someone may already checked in newer code while the dev is doing sync-ing/compiling/unit-testing/scouting, we will use a specialized system to do a check-in, and we call it Gauntlet.

Gauntlet will do an official run of what devs and QA done: get the latest source, unshelve the changes, compile source as bits, and do all tests including unit tests and QA test. After all tests are completed, Gauntlet will check in the code for the dev and let him know everything goes fine. Dev will then pass his/her job to QA and testing the new build, writing new tests for the bug, etc. If anything breaks, dev and QA must fix the problem before nightly build starts.

Except scouting which is a manual tests, most of stuff I mentioned here is automated. And even though they are automated, it took at least an hour to do all the steps for TFS. Nonetheless, as you may notice these steps are pretty straightforward, we just want to ensure every build is a solid build, as solid as we can dogfood on.