Test Cases at Microsoft

  • Article

Brian Lutz is a lucky contracting Tester in the building with my favorite cafeteria on campus, 110. He brings up a great comment about the role of Test Cases at Microsoft:

One thing I’d like to see is some discussion about test cases, and how they are written and executed. In talking with some colleagues outside of MS who have done ad hoc testing on their products, when I presented the idea of a test case and provided examples, it was virtually a new concept for them. It seems that in particular, people who develop software alone or with small groups where there are no designated testers may not really know much on the subject.

When I worked on a small MIS (Management of Information Services) team, I noticed the same thing as Brian. Many small (and even medium size) shops feel forced to rely on ad-hoc testing, instead of the more structured approach that we take at Microsoft. While ad-hoc testing can be a great way to have fun and find *some* bugs, it's not going to help you ship a world-class piece of software.

Here's a handy definition of a Test Case:

“A test case is a document specifying inputs, predicts results, and a set of execution conditions for a test item”.

That definition is short... sweet... and boring! Here's three reasons Test Cases can actually help you:

  • It gives you a great starting point for writing automation. Writing test cases is a crucial first step before writing test code.
  • Adding headcount before shipping a product? New members of your team will hit the ground running if they have test cases to start from! Mentoring a new hire quickly becomes easier.
  • If you have a moment of ingenuity (like, “What happens when I launch my XP application in Win95 compatability mode?“), then you can ensure that the case is remembered later on when you might need it.

Now, a question for the people at home: Anyone have any test case horror stories? (I've got one that I'll add later : )

-Greg