Database testing is one of the major testing which requires tester to expertise in
checking tables, writing queries and procedures. Testing can be performed in web
application or desktop and database can be used in the application like SQL or Oracle.
CariKture India Database testing usually consists of a layered process,
including the user interface (UI) layer, the business layer, the data access layer and
the database itself. The UI layer deals with the interface design of the database, while
the business layer includes databases supporting business strategies. Databases, the
collection of interconnected files on a server, storing information, may not deal with
the same type of data, i.e. databases may be heterogeneous. As a result, many kinds of
implementation and integration errors may occur in large database systems, which
negatively affect the system's performance, reliability, consistency and security. Thus,
it is important to test in order to obtain a database system which satisfies the ACID
properties (Atomicity, Consistency, Isolation, and Durability) of a database management
CariKture India Database test offerings include:
Data Mapping: In software systems, data often travels back and forth
from the UI (user interface) to the backend DB and vice versa. So these are some aspects
to watch for:
- Check whether the fields in the UI/frontend forms are mapped consistently with the
corresponding fields in the DB table. 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 whether the
invoked action in itself is successful or not.
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 the 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
- 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. 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.
Business rule conformity: More complexity in 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.