I think that one of the reasons that we don't hear much about database testing is because it is a relatively new idea within the data community.
Many traditional data professionals seem to think that testing is something that other people do, particularly test/quality assurance professionals, do.
More importantly, it enables them to automate their database testing script into the build procedure itself.
Agile developers realize that testing is so important to their success that it is something they do every day, not just at the end of the lifecycle, following agile testing strategies.
In each sandbox you'll have a copy of the database.
In the development sandbox you'll experiment, implement new functionality, and refactor existing functionality, validate your changes through testing, and then eventually you'll promote your work once you're happy with it to the project integration sandbox.
This reflects a penchant for over-specialization and a serial approach towards development by traditionalists, two ideas which have also been shown to be questionable organizational approaches at best.
Figure 1 indicates what you should consider testing when it comes to relational databases. Agile software developers take a test-first approach to development where they write a test before you write just enough production code to fulfill that test.
You then update your functional code to make it pass the new tests. If they fail you need to update your functional code and retest. Test-driven development (TDD) is an evolutionary approach to development which combines test-first development and refactoring.
Choose an approach that reflects the culture of your organization. For unit testing, I prefer to create sample data with known values.
This way I can predict the actual results for the tests that I do write and I know I have the appropriate data values for those tests.
The diagram is drawn from the point of view of a single database, the dashed lines indicate threat boundaries, indicating that you need to consider threats both within the database (clear box testing) and at the interface to the database (black box testing). The steps of test first development (TFD) are overviewed in the UML activity diagram of Figure 2.
Table 1 lists the issues which you should consider testing for both internally within the database and at the interface to it. The first step is to quickly add a test, basically just enough code to fail.