How we test Software at Microsoft

I recently picked up this book called "How we test software at Microsoft". I think every qa person should have 1 copy. It has rich resources, tons of information, different methodologies, baseline studies and tests, case studies and much more.

One amusing fact it talks about is being in a situation where the bugs "wont fix" meaning that a fix was not planned for the current or future release. The reason for these resolutions was simple: The code was "too scary to touch" and apparently the original developer had left the company years earlier. The code was so complex and difficult to comprehend that not a single developer was comfortable fixing bugs for fear that he or she would cause a dozen other failures - Now we all know this doesn’t happen to us "regular" people does it ??


Anytime simplicity isn't a part of the initial design and implementation of the software, there is potential for the code to grow into a nonmaintainable mess. I believe, proper QA Analysts should be involved at the start of the SDLC to ensure to keep it simple. A professor once introduced the term "KISS" - Keep It Simple Stupid :)

The book talks about using Metrics for evaluation and testing. One such metric is Halstead Metrics:
Halstead metrics are an entirely different complexity metric based on 4 measurements of syntax elements in a program:
Number of unique operators
Number of unique operands
Total occurrences of operators
Total occurrences of operands
Eg. To measure the code length. Halstead metics has an formula – (n1/n2) * (N1/N2)

Model-Based Testing Tools at Microsoft
Spec explorer – One powerful tool used for model=based testing at Micosoft. This was created in 2002. It can do impressive analysis and transformation of the model program that generates FSMs(Finite State Machines)
Spec explorer for Visual Studio – 3rd generation spec explorer