Databases can usually be tested using the front-end client or comparing the output of your program against expectations. So, the answer to your question would be "anything that you can't verify using the front-end".
One other thing to keep in mind is the data that will need to be inserted into the database at the time of implementation in order to support the application. I would want to look at the data loading scripts and compare them against the data that is being tested against.
"The single biggest problem in communication is the illusion that it has taken place."
-George Bernard Shaw, Irish playwright and Nobel Prize winner, 1856-1950
Originally posted by cyblue: Databases can usually be tested using the front-end client or comparing the output of your program against expectations. So, the answer to your question would be "anything that you can't verify using the front-end".
<font size="2" face="Verdana, Arial, Helvetica">I would want to be careful about this statement, there is an assumption that the front end is correct. Many times I have seen bugs in the client applications that return n-1 records due to incorrect incrementation tests in loops. It is for testing for this kind of bug that checking the DB is essential.
Stumpy, that wouldn't assume the front-end is correct. The goal would be to find a defect at the black-box level. If you know you put 10 records in the database, you should get 10 back. The only case where this wouldn't work would be if you didn't know what was in your database and had to query to check it. In most cases, the tester doesn't need to dig into every field of the database. After the defect is found you (or the developer) determines whether it is in the database or the front-end. If your data is going in and the correct data is coming out, that's 99% of your database functional testing done.
To put it quite simply, you do not put data into a database to sit there totally unused. Therefore, if the system has a front end, there will be a means of at least viewing the data if not working with it via that front end.
As mentioned before, it all comes down to knowing what data is present and what data is input.
Three sets of circumstance where you do have to query the database outside of unit testing:
a. When working with a staged delivery and the data access has not yet been delivered.
b. Defect analysis
c. Data scraping (locating specific data to use in subsequent tests)
There is a potential fourth. What if an error in the data input mechanism is countered by another error in the data output mechanism (two separate bugs that negate each other)? How would you discover this? By non simplistic testing! Use data in/data out in as many different scenarios as possible. I have yet to see such a situation pass undiscovered when sufficient testing has been performed.