Categories of Testing at Microsoft

Humans seem to have a natural tendency to categorize. Software Test Engineers are no exception, especially when it comes into breaking down our work items. Different “types” of Testing include the following:

• Functional Testing
• Specification Testing
• Security Testing
• Regression Testing
• Automation Testing
• Beta Testing

A popular Microsoft Test interview question involves asking a candidate to test “Object X”, where that object is something similar to a Salt Shaker. We don't expect candidates to blindly rattle off categories of testing, of course. How much fun would you have listening to someone listing off categories from their memory? It's not that much fun, exactly! Interviewing is our change of pace from the daily Microsoft routine, and we're hoping to watch a great mind solve a problem. Ideally, we'll feel impressed and entertained during an interview. Hopefully you'll be inventing great, innovative, and applicable test cases from each of the categories above!

So, here's the fun part. The list above is intentionally incomplete. There are some important categories of testing that are still missing. Fill in some of the blanks in the comments on this post... I'll try to throw in a little prize to the people with the best answers!

Comments

• Anonymous
  March 24, 2004
  Usability Testing
• Anonymous
  March 24, 2004
  <ul>Unit/API testing
  <ul>Acceptance testing
  <ul>Stress/load testing
  <ul>Performance benchmark testing
  <ul>Release testing
• Anonymous
  March 24, 2004
  With respect to the salt shaker you need the Ges(t)alt test and the sa(li)nity check. Other tests in general include localization so that the rest of the world can continue pay inflated royalties. The stress test which allows for continued service while being Slashdotted. Compatibility testing ensuring your own software works with your older and newer software/hardware. Non-destructive testing found by noting the point at which your hardware explodes. Destructive testing - see non-destructive testing. WHQL testing - a vendor specific form of testing. Trial by fire - an open source version of WHQL testing. Revenue - an executives version of testing. Unit testing - one of those buzzwords you hope to learn someday in your spare time - if they'll ever let you go home.
• Anonymous
  March 24, 2004
  The comment has been removed
• Anonymous
  March 24, 2004
  The comment has been removed
• Anonymous
  March 24, 2004
  The comment has been removed
• Anonymous
  March 25, 2004
  The comment has been removed
• Anonymous
  March 25, 2004
  The comment has been removed
• Anonymous
  March 25, 2004
  Course one thing I could have added under Recovery Testing would be: "or buffer overflows" :-)
• Anonymous
  March 25, 2004
  Interesting comment. I'd argue that a buffer overflow is a scenario where you don't want to recover. What could I mean by that? Well, firstly, do whatever you can to prevent any buffer overflows from entering your app. But, supposing you miss one, which can realistically happen in any piece of software- what should you do when you encounter one? You app can either:
  
  -Shut down gracefully
  -Surrender the Instruction Pointer to a (cr/h)acker.
  
  I'd pick shut down gracefully any day of the week.
• Anonymous
  March 25, 2004
  The comment has been removed
• Anonymous
  March 31, 2004
  Could you please help me ? I have interview at microsoft tomorrow for STE 2 contrating position. They need stress and performance testing. Could you please send me some stress and performance testing question please? My email address is guptashraddh@hotmail.com
  
  
• Anonymous
  March 31, 2004
  Could you please help me ? I have interview at microsoft tomorrow for STE 2 contrating position. They need stress and performance testing. Could you please send me some stress and performance testing question please? My email address is guptashraddha@hotmail.com
  
• Anonymous
  April 01, 2004
  The comment has been removed