There are several advantages to automated database testing. First, automated database testing is faster and more reliable the traditional GUI-based test automation. It’s faster because you don’t have to process the GUI to do your testing. That is, starting the application, logging in, navigating to the feature you want to test, and running the test is significantly slower then just creating a connection to a database and executing a query. In addition, if you use a tool like RFT, which uses a multithreaded language, you can execute multiple tests in parallel. For the same reasons that your tests are faster, they are more reliable. You no longer need to update your scripts for GUI-level changes. Another advantage to testing the database directly is that there are no GUI-level blocking bugs. A blocking bug is a bug that prevents you from executing your other tests. For example, if you were testing a shopping cart and wanted to test credit card processing, but you couldn’t add any items to your shopping cart because the Add to Cart functionality was broken, then your testing would be blocked by another bug. If you test directly at the database, you are not immune to blocking bugs, but they are typically much less frequent. Database testing is as simple or as complex as you want it to be. As you start to dive into your database, you may find it helpful to identify: * The types of database activity (insert, delete, update) that will be invoked * When these transactions will occur within the application-under-test * The calculations or processing rules used by the application * Any time-critical transactions, functions, conditions, and possible causes of poor performance Not all database tests need to be difficult. There are also some simple tests you can perform, such as checking: * Data fields to ensure proper data types * For proper spacing and length * Data formats that may not be enforced by a data type * For duplicate data * Reference data to ensure that the data you are expecting is there Note: It is a good practice to keep backup copies of test files and test databases. Before reporting an error, check your working copies of the input and comparison files against the backups.