Except for the simplest of software applications, the vast majority of software programs are tied to a database at the back end. Although this is not a focus of ISEB / ISTQB teachings, it is a critical aspect of the real world. Whether the software is designed for the Internet, desktop, server, or a large corporation, chances are that a database is involved. And the greater the complexity of the software, or the larger the number of transactions processed, the great the complexity of said database. Therefore it is important to factor this in to your testing efforts.
Although a full blown database test plan is beyond the scope of this post, we can at least touch on the highpoints so you can get a general idea of what is involved. First, make sure that the data is mapped accurately. This will help test whether or not the database performs as expected when the application interacts with it. For example, if the end user deletes some data from the user interface, you will want to make sure that these data points are subsequently deleted from the associated database table.
You will also want to validate data integrity. This means that the most current data values are shared across the board. In other words, each shared system must show the most recent value for each data point whenever updated. This is important because different modules of a software program might utilize the same data in different ways.
Additionally, unless the database is designed simply to store records, you will want to test the functionality of any business logic or rules that reside at the database level. Finally, you will want to test the database transaction properties – atomicity, consistency, isolation, and durability.
In order to execute the database test, it is worth mentioning that the tester should have explicit knowledge of the database tool/language (such as SQL), DML (database manipulation language), the internal structure of the database, and AUT. Then, the tester will simply perform operations from the user interface and validate the output via SQL queries (or by observing the actual database tables if the tester is not good with SQL or if the application is relatively simplistic). Note that the more complex the database, the less likely that you’ll be able to manage all the SQL queries, and as such assistance from the development team may be necessary.
The bottom line is that database testing is becoming a necessity in today’s high-tech world. Just make sure the tester in charge knows what he or she is doing, including adequate knowledge of SQL, AUT and the internal workings of the database’s structure.