Database testing

Database testing includes black box, white box and requirements testing ACID — atomicity, consistency, isolation and stability. In this guide, I will explain all the necessary definitions, how it is done, and give examples.

What is database testing?

Database testing, or backend testing, or data testing, differs from user interface testing in that it is not at all concerned with the visual interface of the software. After all, its main task is to check the correct operation of all internal processes and the ability to quickly, accurately and safely obtain data.

Database testing checks the database schema, tables, and triggers. It places stress on the database and may involve running complex queries to thoroughly test its capabilities and responsiveness. Database management systems (DBMS) such as Oracle and SQL Server are also tested.

What is a database schema?

A schema is a logical structure that defines the organization and relationships of data in a database. It describes how data is stored, accessed, and manipulated in a DBMS. A schema describes data types, constraints, and relationships among database objects such as tables, views, indexes, and triggers.

Schema is critical to ensuring the integrity and consistency of data in a database. It provides developers and administrators with a framework for organizing and structuring data. It also helps ensure that the data stored in the database meets certain requirements, such as validation, security, and availability. Organizations can use a database schema to organize and optimize their databases for efficient data management, improving business operations and decision making.

Why is database testing important?

Testing databases is important for several reasons:

  1. Some bugs can only be found using this type of testing.

  2. Certain conditions of use can only be tested in the database.

  3. Database testing improves stability and security.

  4. Database testing ensures consistency.

Database function example

Imagine opening an online banking application on your smartphone and transferring a small amount of money from your current account to a deposit. Now think about how much happens behind the scenes in those few seconds.

  1. The application sent the transaction information to the database.

  2. None of your data (i.e. money) gets lost along the way.

  3. The application did not crash, but completed the translation successfully.

  4. The transaction was secure.

  5. Your money is now safely in your deposit account (congratulations!)

All these functions are performed in the database. The testing process is very important because if a critical failure occurs in the database system, the system stops. No information can be sent or received, transmitted or protected. Outwardly, the application may appear to be running (you can navigate windows and prepare to make a transaction), but nothing significant will happen.

Everything looks good on the outside, but on the inside it's a disaster.

This is fine image

Principles of Database Testing

The word “principles” may sound more like “why” than “how.” Trust me, these are two important practical concepts.

  1. ACID Properties

    • Atomicity

    • Consistency

    • Isolation

    • Durability

  2. Data integrity

What are ACID properties?

ACID properties stand for Atomicity, Consistency, Isolation, and Durability. Every transaction in database testing must conform to these principles.

A transaction is a group of tasks. Even a simple real transaction like the bank transfer I talked about earlier will involve several lower order tasks. ACID properties are designed to confirm that each transaction is completed accurately, completely, and holistically.

ACID principles

  • Atomicity (A, Atomicity) implies that each transaction is treated as an atomic unit. This means that every transaction must be completed completely, otherwise it will fail. This attitude to each transaction allows you to avoid the unpleasant situation when a money transfer is half completed. Sounds alarming, right? With atomicity, if a transaction is half completed when something goes wrong, the entire transaction fails. The money is being returned. And no stress.

  • Consistency (C) means that the database remains consistent after a transaction. No transaction can negatively affect other data in the database. If you deposit money into your own bank account, it will not be withdrawn from someone else's account.

  • Isolation (I, Isolation) prevents threads from crossing. It ensures that if multiple transactions occur simultaneously, each transaction will be treated as if it were the only transaction in the database. Nobody's information is mixed with someone else's.

  • Durability (D, Durability) implies that the database is resilient enough to retain all recent transactions even if the system fails. Again, there are practical reasons to require such robustness from a database. For example, if you make a money transfer and ten minutes later the database crashes, how will you know to make the transfer again? Having such strict requirements prevents confusion on the part of end users.

Data integrity

Data integrity practices aim to ensure that all the latest data is updated throughout. There are four distinct parts that together confirm the integrity of the data. To achieve a high level of data integrity, the tester must ensure that the data:

  • verifiable

  • can be restored

  • are accurate

  • are complete

If the data does not meet these four requirements, then it most likely does not meet the data integrity standard. Data management tools can help with this, but ultimately it's up to you to ensure high data quality.

As Hugh Price noted in an episode of The QA Lead Podcast entitled Your Data Quality Sucksensuring systems run on high-quality and secure data is becoming increasingly important as more companies create their own data banks.

Database management language

Language DML is a programming language used to manage data in a database management system. DML is primarily used to perform tasks such as inserting, updating, deleting, and retrieving data from a database. Essentially, DML provides a set of commands and functions that allow users to interact with data in a database, modifying or retrieving that data according to certain criteria. DML is an essential component of any database system, allowing users to perform operations on data without understanding the underlying database structure or technology.

DML commands are usually used in conjunction with the language DDL, which is used to create and modify database objects such as tables, views, and indexes. DDL and DML form the core components of a database system, allowing users to create, modify, and manipulate data in a secure, efficient, and reliable manner. Using DML in database management allows organizations to store, manage, and analyze large volumes of data, making it a critical business tool in today's data-driven world.

Types of Database Testing

Now that we've covered the two basic principles of database testing, we can move on to the different types of testing. Chances are you've already heard of some of these approaches. Here I will explain how each of these concepts applies to database testing.

There are three types of database testing:

  1. Structural

  2. Functional

  3. Non-functional

Within these three types there are subtypes. I'll tell you about them too.

Structural testing

Structural testing examines the data warehouse elements that are used to store data. These elements are hidden from end users and happen entirely behind the scenes. Testers perform these tests by writing SQL queries.

Data Display Testing

Data structure mapping is the process of establishing relationships between two different data models. Also called schema testing, data mapping testing tests the front-end and back-end. The tests check whether they interact with each other correctly.

For example, if you fill out a registration form on a website, proper data mapping will take the web form and transfer it into the database. The name, email and password will be saved where they should be. Data display testing confirms that the process works.

There are several data display tools, for example:

Testing Database Tables

Table testing performs several checks on the data display structure. The compatibility of fields on the front-end and back-end is checked. The length of database fields is checked. It also checks to see if there are any unmapped tables or columns in the database that need to be accessed.

Database server checks

Server verification ensures that the server configuration meets the requirements. It also ensures that anyone attempting to access certain areas of the database server has the appropriate authorization. This is an important step in ensuring the security of the database for its users. Finally, testing the server ensures that it is capable of processing the maximum number of transactions simultaneously.

For example, when testing a server for a banking application, you need to ensure that the server can handle the financial transactions of a certain number of users and that all users can only access their own information.

Functional testing

We'll put the fun back into functional testing. I promise. Functional testing is the process of verifying that the database meets the client's specifications and that the end user's actions do not deviate from those requirements. This means a lot of pretending to be the end user. Doesn't that sound funny? It seems to me quite.

Black Box testing

Black box testing is a software testing strategy in which the internal structure of the system under test is unknown to the tester. Without such in-depth knowledge, the tester will approach it with the same expectations as the end user.

Black box testing is performed during database testing because it allows you to find bugs in popular scenarios that the end user is most likely to encounter. This is the ultimate testing as an end user.

White Box testing

This is the exact opposite of black box testing. In white box testing, the tester fully understands the internal structure of the software under test.

He approaches testing like an inspector. White box testing is sometimes called transparent box testing because the tester observes the interactions between modules. In this case, he is not so concerned with the user experience.

Unit testing

Unit testing is a technique that involves testing individual modules or components of an application in isolation from the rest of the system. This type of testing is designed to test individual database objects such as tables, views, stored procedures, and functions. By testing these objects in isolation, developers can ensure that each object functions as intended.

Database unit tests typically involve writing automated tests that run specific SQL commands on a database object or module and verify that the expected results are returned. For example, a unit test for a stored procedure might involve passing a set of input parameters to the procedure and checking that the output is correct. By using unit tests in this way, developers can ensure that each database object works as expected and that any changes to the database schema or application code will not result in unexpected consequences or errors.

Non-functional testing

With non-functional testing, the end user doesn't matter in the slightest. It's not that the end user isn't important, it's just that these tests have other concerns. Non-functional tests test the performance of the database under load and stress, and look for opportunities to optimize performance.

Stress Testing

Database load testing is a type of performance testing. It is carried out to check whether the user load will have a sharply negative impact on the performance of the database. The tester runs many load requests and runs them over and over again to simulate an active user base.

Stress testing

Stress tests are more intensive tests that not only test the performance of the database, but also look for places where it might break. Which is much more destructive. And funny.

Have you ever eagerly awaited the release of a new video game or smartphone? If so, you probably know the feeling when you load a website or open an app to make a purchase and are faced with unusually long loading times, unexpected error codes, and glitches in processing information. This is the database in a stressful situation.

Stress testing differs from load testing in that it exposes the database to a sudden, unexpectedly high volume of traffic.

Automated Database Testing

Automated database testing has become very popular in recent years. Manual database testing would take too long, require too many people, and simply cost too much money.

There are many ways to automate testing. IN this article Here are some database management tools that offer testing functionality.

Testing the Database Using the API

API is a set of protocols and standards that allow different software applications to communicate with each other. In database testing, the API can connect to the database and perform various operations such as inserting, updating, deleting, and retrieving data.

The connection between APIs and database testing is that APIs can be used to automate and simplify the testing process. Using an API to connect to a database, testers can automate tasks such as inserting, updating, and deleting data, as well as running queries to retrieve data and validate results. This can significantly reduce the time and effort required for manual testing and improve the accuracy and consistency of test results.


In conclusion, we invite all beginning testers to open lessons:

  • April 3: “What is the role of a functional tester in a software development team?” > Sign up

  • April 17: “How to write a bug report so that your colleagues will say “thank you” to you” > Sign up

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *