|
Key Concepts for Database Testing (Part 2)
Jesse Watkins-Gibbs, Project Manager, LogiGear Corporation
In a previous article on database testing considerations, I discussed referential integrity and security. This article will cover the additional topics of interfaces and data formats.
Interfaces
In today's complex applications, data must pass between one or more (typically many more) interfaces. Some of the typical types of interfaces which exist between the user entering or reading data, and the database may include, but are not limited to:
* Graphical user interfaces (GUIs) on the web or desktop
* Java, COM, or .net classes
* Web Services
* Screen-scraping of a legacy mainframe application
* Application programming interfaces (APIs) for access the database, such as ODBC, JDBC, and OLEDB
Bugs can be introduced at any of these interfaces, no matter whether you are reading, writing, updating, or deleting data.
Testing the interactions between all of these interfaces can be very complex, but I would suggest that at a minimum, you:
1. Understand all of the interfaces that data passes through between the user and the database.
2. Learn about the technologies used to implement each interface, and what the possible bugs are due to that interface.
It is possible to create tests which are run against each of these interfaces; however some of these tests may require some programming. If you are going to test against an interface other than the UI, it is important to understand what formats of data are expected at that interface. This leads us to the next topic, data formats.
Data Formats
Data in a database may be input from and displayed on a number of different types of systems, including Web-based applications, desktop applications, and handheld devices. Each of these types of systems has unique system limitations, which may dictate how data should be stored and/or formatted in your database.
Take dates as an example. Most Windows applications can accept dates up to the year 9999, but many handheld devices can only accept dates up to the year 2039, due to memory capacity limitations. If your database allows users to store dates past 2039, what happens when you try to display one of these dates on a mobile handset?
The format of data may also change as it passes through various interfaces between the user interface and the database. For instance, data may first be extracted from the database in tabular format, then converted into XML format so it can be transferred via a web service, then be transformed into HTML for display within a browser. At each one of these interfaces, the format of the data will be changed, and new bugs may be introduced.
Again, you can test the data at each of the interfaces, but it may require some programming. At a minimum, you should be able to identify all of the formats used to transfer the data between each interface, and understand some of the fundamental limitations of the technologies being used. This will allow you to create better test cases, and more intelligently analyze data-related bugs that appear during testing or pop up in production.
Conclusion
Database testing is one of the most challenging tasks facing a software QA team. At a minimum, team members should understand referential integrity and database security, and have a good grasp on the various technologies and data formats used to transfer data between the user and the database. |
|