One of the pitfalls to avoid is paying equal attention to everything. This is the well-known "test everything" syndrome. The slowest-moving, most bloated, most bureaucratic "waterfall" software project in the world didn't include time to test everything, so you can expect to have to skip something on a fast-moving XP iteration. The trick is in knowing what to concentrate on and what to ignore. We can't give you an algorithm for making this distinction, but we can sum up the key ingredient in a single word: risk. Design your tests to minimize risk. Even if this seems obvious, it's still easy to fall into a trap where you devote an inordinate amount of attention to an area, not because it's especially risky but because it's an easy area for which to design tests. Maybe you just have a ton of detailed information about that area, like a list of fields with all the various types of allowable values and optional/required specifications. It's easy to design tests that go through lots and lots of combinations, but if this isn't a risky area, why bother? Here's one of Tip's favorite stories about this:
In the next chapter, we'll share our experience of useful ways to get all these details down into an executable form the whole team can understand. |