Database Testing Guide

Database Testing Guide:
Computer applications are more complex these days with technologies like android and also with lots of smart phone apps. The more complex the front ends, the back ends are even more intricate.  So, it is all the more important to learn about DB testing and be able to validate the databases effectively to ensure secure and quality databases.

In this article you will learn all about Database Testing. Why to test- How to test- What to test : These are some of the aspects we will cover.

Why do we test a database?

Below, we will briefly see why the following aspects of a DB should be validated:

1) Data Mapping: In the software systems, data often travels back and forth from the UI (user interface) to the backend DB and vice versa. So following are the aspects to look for:

• To check whether the fields in the UI/Front end forms and mapped consistently with the corresponding DB table (and also the fields within).  Typically this mapping information is defined in the requirements documents.
• Whenever a certain action is performed in the front end of an application, a corresponding CRUD (Create, Retrieve, Update and delete) action gets invoked at the back end. A tester will have to check if the right action is invoked and the invoked action in itself is successful or not.

2) ACID properties validation:  atomicity, consistency, isolation and durability. Every transaction a DB performs has to adhere to these four properties.

• Atomicity means that a transaction either fails or passes. This means that even if a single part of transaction fails- it means that the entire transaction has failed. Usually this is called the “all-or nothing” rule.
• Consistency: A transaction will always result in a valid state of the DB
• Isolation: If there are multiple transactions and they are executed all at once, the result/state of the DB should be the same as if they were executed one after the other.
• Durability: Once a transaction is done and committed, no external factors like power loss or crash should be able to change it

3) Data integrity:

This means that following any of the CRUD operations, the updated and most recent values/Status of shared data should appear on all the forms and screens. A value should not be updated on one screen and display an older value on another one. So devise your DB test cases in a way to include checking the data in all the places it appears to see if it is consistently the same.

4) Business rule conformity:  More complex databases means more complicated components like relational constraints, triggers, stored procedures, etc. So testers will have to come up with appropriate SQL queries in order to validate these complex objects.