1. Database Testing:
Database testing is validating that the operation performed on antecedent tables and the results generated
from the operation is in accordance to the requirements and stored in the corresponding columns of
resultant table. And data on the user interface is mirror of the data stored in the data-base. There are many
aspects to the correctness of a database system, including; Does the application program behave as
specified? Are the data in the database accurate? Does the DBMS perform all insertions, deletions, and
updates of the data correctly? Does the database schema correctly reflect the organization of the real
world data being modeled?
Understanding of requirements and the properties of the database and DB-tester queries the DB and find
out whether the system is responding adequately. Following aspects of the DB should be validated to
answer the questions mentioned above:
• Data mapping
• ACID property validation
• Data integrity
• Business rule conformity
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 are mapped consistently with the
corresponding DB table and column (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.
To test data mapping a tester should find fields and the corresponding tables and columns and also the
data type of that column from requirements, then give the inputs to the system; input with the data type
same as the defined in corresponding column and also with data type different from the declared data
type. Observe both the reactions and make report on it with the proper explanation.
If the user interface is not created then testing data mapping is not possible but the rejection and
acceptance of data on basis of data type can be tested using the “insert” statement of SQL.
ACID property validation: Acid stands for atomicity, consistency, isolation and durability. Every
transaction a DB performs has to stick firmly to these four properties.
• Atomicity: 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.
This can be tested by first identifying the rules for completion of transaction. And then giving
input that satisfies the rule, input that partially satisfies the rule and an input that completely
disobey the rule. Observe all three of the operation and if the system passes one and fails other

2. two then it would be following the property of atomicity and if not then it’s not following the
property in its essence; in both cases make a report on both the scenario.
• Consistency: A transaction will always result in a valid state of the DB.
For this tester has to find out the valid state of DB after each transaction. After the identification
of valid states give the input for transactions to see whether or not the DB is in its valid state after
the transaction.
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.
First identification of all transactions of the system from the requirements. Identifying the
dependent and independent transactions of the system, then giving input to the system for both
dependent and independent transactions. Observing that the independent transactions of the
system run parallel to each other without effecting the results of one another and the dependent
transactions does not start unless the input/object/field is fed to them.
• Durability: Once a transaction is done and committed, no external factors like power loss or
crash should be able to change it.
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.
This is tested by updating (Delete, Update, Insert e.t.c.) DB and then cross checking on all the interfaces
that all are mirror of the most recent values/status of the database.
Business Rule conformity: More complex databases means more complicated components like
constraints, triggers, stored procedures, etc.
To validate this the tester has to identify all the constraints, triggers, stored procedures and their flow (the
purpose of these and there expected output). Then querying system in a way to cover up the flow of these
constraints, triggers, stored procedures and comparing the results of the queries with the results expected.
Conclusion:
Computer applications are more complex these days with technologies like web, android and also with
lots of smart phone apps. The more complex the front ends, the back ends are even more intricate. A
small mistake in the backend/DB could led the whole project to a failure. It is very important to start
testing it from start, because in complex system it is easier and cost effective to identify and fix a bug in
start then at the end.