This post originated from an RSS feed registered with Agile Buzz by Jared Richardson. Original Post: Blitzkrieg Testing Feed Title: Jared's Weblog Feed URL: http://www.jaredrichardson.net/blog/index.rss Feed Description: Jared's weblog. The web site was created after the launch of the book "Ship It!" and discusses issues from Continuous Integration to web hosting providers. Latest Agile Buzz Posts Latest Agile Buzz Posts by Jared Richardson Latest Posts From Jared's Weblog

In an ideal world, every class in your software product would have unit tests. Mock Client Tests would validate every usage scenario. You'd catch every break in your product in minutes with your Continuous Integration system and the developer who changed the code would fix the problem quickly.

But we don't live in a perfect world, do we?

We support products that other people wrote … products with no automated tests at all. Sometimes we create products under incredibly tight deadlines and we don't add tests ourselves.

How we got here isn't important though … the important issue is how do we get the critical testing coverage we need? I've already talked about Mock Client Testing. That tells us what types of test to write. But in my mind this is a different question.

A blitzkrieg is an attack that rushes in headlong. It doesn't worry about taking every building and bridge … the soldiers just plow ahead and take the country. The details are addressed later.

Blitzkrieg Testing is similar. Aim for breadth, not depth. If you're testing a portal product that has ten main pages, write a test that logs in, visits a page, verifies the page, and then logs out. You've written the equivalent of a "Hello world!" program for that page.

Next, add the same type of test for every page in your portal ... your preferences page, configurations, content pages, and so on. The point here is to run across the product and create a basic test for as many areas as you can. Don't get stuck in any one area. You don't want to dig in; you want to roll across the country in a tank!

What have you accomplished with this mad dash across your product?

First, you've established a basic test framework. If someone else wants to help fill in your tests later, they've got running code they can use. They don't have to start from scratch.

Second, a "Hello world!" test validates a great deal more functionality than most people think. Quite often other developers (but never you and me!) will make a change to code or a configuration file and they are sure their changes couldn't have broken anything … but somehow things are broken all over the place! These basic tests ensure that the pages still function at a basic level.

Lastly—momentum! Never underestimate the value of momentum. Once you (or your team) have completed the initial dash, it's so much easier to continue in the habit of writing tests. You've also (hopefully) provided the critical mass of tests needed to show the value of automated tests to the doubters in your midst.

What about the high priority problem areas? Just like a real blitzkrieg, the hotspots are never where you think they'll be. Sometimes the enemy just up and runs away! Go ahead and complete your first round of lightweight tests and then see what's still breaking. Where are the real hot spots? Then you can invest the time writing more detailed tests where they're needed most instead of where you suspect they might be needed.

So remember, a Blitzkrieg Test effort is a short-term dash across the product, aiming for breadth, not depth.