Over the past few months, I've had more and more people ask me about how we go about testing on agile projects. Agile developers are definitely "test infected," and this month, I explore several strategies for testing on agile software development projects. A word of warning: Although we clearly don't follow our father's serial testing methodology of yesteryear, I suspect that we can still learn a few tricks from dear old dad.
Let's start by setting the philosophical groundwork:
- First, you want to test as early as you possibly can because the potential impact of a defect rises exponentially over time (this isn't always true, but it's something to be concerned about). In fact, many agile developers prefer a test-first approach.
- Second, you want to test as often as possible, and more importantly, as effectively as possible, to increase the chance that you'll find defects. Although this increases your costs in the short term, studies have shown that greater investment in testing reduces the total cost of ownership of a system due to improved quality.
- Third, you want to do just enough testing for your situation: Commercial banking software requires a greater investment in testing than membership administration software for your local Girl Scouts group.
- Fourth, pair testing, just like pair programming and modeling with others, is an exceptionally good idea. My general philosophy is that software development is a lot like swimming—it's very dangerous to do it alone.
