Overview

The quality of a thing reflects the value of the work that goes into it. A well-done steak is, well, a mistake unless that's what the customer wants. The trick to getting a high-quality database application system is not to load large amounts of data in the wild hope that, by brutalizing the system, you will find out what's wrong with it. Instead, you must compare the end result of your effort to the needs and wants of your customers. In this short chapter, I hope to cover some of the techniques I've learned over the years for testing databases against requirements.

There are two parts to such testing: the database and the requirements. If you are going to hold the database design and development accountable for meeting a set of requirements, you must be reasonably sure that the set is correct and complete. That means that you must verify your requirements in the same way that you verify your design and code. As with all testing, this is not a one-time, do-or-die testing effort that you must complete before moving on to design. You do it over and over as your design and implementation progress, always questioning, always testing the limits of your requirements. You start with presenting the use cases to your clients and getting their feedback on completeness and accuracy of the...