Test Plan as Requirements

My first project at my new job was a pretty simple web site. I didn't use the data controls (like DetailsView), although they would have been appropriate. I didn't write unit tests either, mostly because the application fills out forms that directly reflect auto-generated SubSonic classes. There was one place where I should have written unit tests, but only one. I did write a test plan.

A test plan, in theory, should cover every behavior that the application should exhibit. If the application is supposed to flash the background color every 10 seconds, there should be an item on the test plan that says "The background color flashes every 10 seconds". If there's no requirement for that to happen, it shouldn't be in the test plan. So the test plan should echo the requirements document, if you have one. Which you probably don't, so writing a test plan gives you requirements.

The real reason to write a test plan is to separate you the developer from you the tester. Testing something that you developed is tricky, because if you just dive in and test, you're not going to test very well. You're going to test the things that come to your mind, which is probably the things you worked on the most, which probably doesn't have bugs since you worked on them the most. Writing the test plan properly, by looking at the UI and writing down everything it should do, separates these two personas.