Test Guide

Verifying that a test case’s actions had the expected result is perhaps the most important part of testing. Every test case does something at least a little differently than every other test case, so the expected results are often a little different....

Many tests don’t care exactly what data they are executed against. Our Data Manager uses techniques similar to those used with Execution Behaviors to manage Data Providers that generate test data. This solves with a single stroke the dual problems of...

Most user actions in an application can be executed in different ways. As I mentioned earlier, creating a new document can be done via the following methods: Clicking the File menu, clicking the New submenu, then clicking the New Document menu item...

Even a small application such as Microsoft Notepad has a plethora of features that must be tested. While the occasional feature is simple enough that a single test case is sufficient to test it thoroughly, it is more likely that multiple test cases are...

What if you had a test case that looked like this? (Assuming a shape-drawing application such as Microsoft Visio...) Logical.Projects.CreateNewProject(); Point rectangleStart = DataManager.ScenePointProvider.GetNextValue(); Point rectangleEnd =...

The sum of these factors makes testers little more than factories churning out test case after test case, each of which is different only in some small detail (e.g., how a particular operation is invoked) than the others. Another way to say this is that...

All of these problems combine to make Test perpetually perceived as the “long pole”, since most Test work is done very late in the milestone. Most modern product and feature teams acknowledge that involving Test early in the development process (that...

These problems all combine to make test cases a maintenance nightmare. Anytime the application under test changes – regardless of whether the UI changed a tiny bit or an entire feature was dramatically revamped – every affected test case must be updated...

Test cases do not often make a distinction between the user actions a test case is testing and the steps it takes to invoke those actions. Indeed, most test cases explicitly tie these details together! Because much emphasis is placed on testing every...

The execution section of a test case is itself composed of three subsections: setup, execution, and teardown. Execution is often thought to be the most important part of a test case (after all, a test case that doesn’t verify anything is rather pointless...

An individual operation can usually be executed via several different user actions. For example, creating a new document can typically be done by one of the following user actions: Clicking the File menu, clicking the New submenu, then clicking...

Test cases are composed of three primary sections: Cache initial state. The primary task for any test case is verifying that an action had the intended effect; if the test case is to know what changed it clearly must save off the starting state...

In many of my posts I have alluded to the automation stack my team is building, but I have not provided any details. The next month or so of posts will remedy that: first I'll discuss the problems we are trying to solve and then I'll explain how we're...

They've let me on to the Microsoft Careers "Meet Our People" page! http://members.microsoft.com/careers/epdb/profileDetailPage.aspx?profileID=77 goes directly to me; check out http://members.microsoft.com/careers/mslife/meetpeople/ to see everyone else...