If you have a set of design requirements and specifications, you should design testing to make sure all of those requirements are met. Details like field length, datatype, field formats, etc. should all be tested. You should write up scenarios of all of the known operations and test those out to ensure that the app can perform them.
You should also include testing that tries to break all of the rules. Perform operations out of expected order, leave out required info, try to create "orphan" records by trying to delete master table values etc. Give the application to someone who is not familiar with it, let them bang around in it and see if they can break something. Let a user or someone familiar with the business rules of the app enter data or run queries or whatever else which they know will test those rules.
Document all of the testing scenarios you work thru so you can retest all of them after you get done fixing all of the bugs you find in the first round. Keep repeating the process until you can't break anything anymore. Then pray that there still isn't some hidden bomb inside the code waiting to blow up in the client's face next year.
P.S. Also test for periodic situations, duplicate a year-end process, load it up with a lot of records and test performance. I am sure there are other things I am missing, you almost can't test it too much.
HTH
