Printable View
What exactly is MQ that was briefly mentioned here:
http://blogs.msdn.com/somasegar/arch...08/490694.aspx
and
http://blogs.msdn.com/texblog/archiv...01/541918.aspx
Is it a process? Strategy? Set of techniques? Or is it simply a set of priorites?
What were the main lesssons you learned from the MQ exercise and what parts of it can you take into your normal everyday development?
Hi Ted: MQ was the name of a "quality milestone" it was a chance for the whole of Visual Studio to take a step back and look at the processes we use to develop software and how we can improve them. We spent a lot of time looking at the tools we use, how we design features, how we run tests, how integrations are handled, how we do code-coverage, how we interact with users. You name it we looked at it.
Last week I was in the line in our cafeteria when one of the "owners" of the MQ initiative joined the line right behind me - I asked him a slightly different question "Did MQ make a difference?". He answered was that yes it did - we did a full testpass at the end of MQ and the number of regressions that were discovered was smaller than with previous testpasses and also the code-coverage numbers were significantly improved - but he did state that we'll have to wait until the end of the next release of Visual Studio to see if some of the process changes that were put in place have a real impact.
For the Visual C++ Compiler team we looked at our processes, tweaked a few things, and then decided to focus on bugs as getting rid of "bug debt" was also part of MQ. We focused almost entirely on user reported bugs that we had postponed during the development process for Visual C++ 2005 and I am happy to reported that we fixed well over 200 issues - a lot of which will find their way into SP1.
One thing that we had been doing already but that MQ confirmed was a form of "paired-programming". On the Visual C++ Compiler Team when we decide to fix a bug we immediately assign it to both a developer and a tester. This means that the tester can start writing regression tests while the developer is fixing the code. The tester also gets to review the changes with the developer which means that they may spot other tests that they might need to write - and the devleoper gets early feedback on whether or not the proposed fix actually addresses all the issues. Finally the fix and the new tests are checked in together which closes the window on the risk of a regreesion sneaking in before the tests are added to the appropriate suite.
All in all I think MQ was a success - but as I said above we'll need to get a full product cycle under our belts before we can know what really worked and what didn't.
Great info - thanks.