I’m sure I’m not the only seasoned database-developer who wakes up in the night, thinking of some of the bugs in code that slipped through unit testing, and whistles with embarrassment.

The older I get, the less confident I become in my ability to get things right without a lot of help. Developers need testers: I’ve never met a good developer who can test his or her own software, purely because a developer brings to the task assumptions about functionality that can be entirely wrong. A Developer also finds it very hard to test their creation deliberately to destruction, whereas a tester will gain great satisfaction from it.

It was quite recently that I had one of my more unpleasant shocks with testing. I’d written a back-office system for processing orders from a website, based in SQL Server and ASP.NET. The company was responsible for providing a full-time tester and produced an accountant. He knew nothing of testing but had the tenacity of a ferret chasing a rabbit.

I laughed when he checked my calculations with a desk calculator; though I boggled at the speed he could use it. How could he possibly find a bug? When he soon found an error in one of my calculations, I was incredulous. After a lot of raised voices and hand-waving, I realized how stupid I’d been. There are a number of rules for how to handle rounding errors in the formula for calculating tax on individual purchase items. Not only that, but the rules can vary. I’d used the wrong rule. How soon, in IT, one can lose one’s professional gravitas.

So when I wake up in the night in a cold sweat, and my bugs run past me like sheep waiting to be counted, I keep asking myself how many of the subtle database bugs would have been trapped by one of the newer test methodologies currently being proselytized . Some; yes. I love James Whittaker’s concept of Testing Tours, for example, but others wouldn’t. Whereas Asserts and automated regression testing always work for me, I’m convinced that the best development work comes from a sort of intellectual game between the developer and tester that can usually transcend the methodology. The usefulness of a structured test methodology is that it removes the unnecessary noise, the trivial bugs, from the build in the first place, and allows the tester to home in on the important matters. Database testing certainly has a lot in common with application testing but there are subtle differences that often demand slightly different test techniques. There is a danger in generalizing