Database Testing Guide (Why, How, and What About Database Testing)

Database Testing Guide:

Computer applications are more complex these days with technologies like Android and also with lots of Smartphone apps. The more complex the front ends, the more intricate the back ends become.

So it is all the more important to learn about DB testing and be able to validate databases effectively to ensure security and quality databases.

In this article, you will learn all about Database Testing. Why test- How to test- What to test. 

Why do we test a database?

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

All About Database Testing 1

#1) 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.

#2) ACID properties validation:  Atomicity, Consistency, Isolation, and Durability. Every transaction a DB performs has to adhere to these four properties.

DB Testing

(image credit)

  • 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 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.

Data Integrity Testing

#4) 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.

How to test Database – Step-by-step Process

Recommended read => How to test a Database – tips

The general test process for DB testing is not very different from any other application. The following are the steps:

Step #1) Prepare the environment
Step #2) Run a test
Step #3) Check test result
Step #4) Validate according to the expected results
Step #5) Report the findings to the respective stakeholders

Database Testing Process

Usually, SQL queries are used to develop the tests. The most commonly used command is “Select”.

Select * from <tablename> where <condition>

Apart from Select, SQL has 3 important types of commands:

  1. DDL: Data definition language
  2. DML: Data manipulation language
  3. DCL: Data control language

Let us see the syntax for the most commonly used statements.

Data Definition language Uses CREATE, ALTER, RENAME, DROP and TRUNCATE to handle tables (and indexes).

Data Manipulation language Includes statements to add, update and delete records.

Data control language: Deals with giving authorization to users for manipulation and access to the data. Grant and Revoke are the two statements used.

Grant syntax:
Grant select/update
On <table name>
To <user id1, user id2…useridn>;

Revoke syntax:
Revokeselect/update
on <table name>
from<user id1, user id2…useridn>;

What to test – different components

1) Transactions:

When testing transactions it is important to make sure that they satisfy the ACID properties.

These are the statements commonly used:

  • BEGIN TRANSACTION TRANSACTION#
  • END TRANSACTION TRANSACTION#

The Rollback statement ensures that the database remains in a consistent state.

  • ROLLBACK TRANSACTION#

After these statements are executed, use a Select to make sure the changes have been reflected.

  • SELECT * FROM TABLENAME <tables which involve the transactions>

2) Database schema:

A database schema is nothing more than a formal definition of the how the data is going to be organized inside a DB. To test it:

  • Identify the requirements based on which the database operates. Sample requirements:
    • Primary keys to be created before any other fields are created.
    • Foreign keys should be completely indexed for easy retrieval and search.
    • Field names starting or ending with certain characters.
    • Fields with a constraint that certain values can or cannot be inserted.
  • Use one of the following methods according to the relevance:
    • SQL Query DESC<table name> to validate the schema.
    • Regular expressions for validating the names of the individual fields and their values
    • Tools like SchemaCrawler

3) Trigger:

When a certain event takes places on a certain table, a piece of code (a trigger) can be auto-instructed to be executed.

For example, a new student joined a school. The student is taking 2 classes: math and science. The student is added to the “student table”.  A trigger could add the student to the corresponding subject tables once he is added to the student table.

The common method to test is to execute the SQL query embedded in the trigger independently first and record the result. Follow this up with executing the trigger as a whole. Compare the results.

These are tested in both the black-box and white-box testing phases.

  • White box testing:  Stubs and drivers are used to insert or update or delete data that would result in the trigger being invoked. The basic idea is to just test the DB alone even before the integration with the front end (UI) is made.
  • Black box testing:

a) Since the UI and DB, integration is now available; we can insert/delete/update data from the front end in a way that the trigger gets invoked. Following that, Select statements can be used to retrieve the DB data to see if the trigger was successful in performing the intended operation.

b) The second way to test this is to directly load the data that would invoke the trigger and see if it works as intended.

4) Stored Procedures:

Stored procedures are more or less similar to user-defined functions. These can be invoked by Call Procedure/Execute Procedure statements and the output is usually in the form of result sets.

These are stored in the RDBMS and are available for applications.

These are also tested during:

  • White box testing: Stubs are used to invoke the stored procedures and then the results are validated against the expected values.
  • Black box testing: Perform an operation from the front end (UI) of the application and check for the execution of the stored procedure and its results.

5) Field constraints – Default value, unique value and foreign key:

  • Perform a front-end operation which exercises the database object condition
  • Validate the results with a SQL Query.

Checking the default value for a certain field is quite simple. It is part of business rule validation. You can do it manually or you can use tools like QTP. Manually, you can perform an action that will add a value other than the default value of the field from the front end and see if it results in an error.

The following is a sample VBScript code:

Function VBScriptRegularexpressionvlaidation(pattern , string_to_match)
Set newregexp = new RegExp
newregexp.Pattern = “<Default value as required by the business requirements>”
newregexp.Ignorecase = True
newregexp.Global = True
VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match)
End Function
Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match)

The result of the above code is True if the default value exists or False if it doesn’t.

Checking the unique value can be done exactly the way we did for the default values. Try entering values from the UI that will violate this rule and see if an error is displayed.

Automation VB script code can be:

Function VBScriptRegularexpressionvlaidation(pattern , string_to_match)
Set newregexp = new RegExp
newregexp.Pattern = “<Unique value as required by the business requirements>”
newregexp.Ignorecase = True
newregexp.Global = True
VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match)
End Function
Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match)

For the foreign key constraint validation use data loads that directly input data which violate the constraint and see if the application restricts them or not. Along with the back end data load, perform the front end UI operations too in a way that will violate the constraints and see if the relevant error is displayed.

Conclusion:

With all these features, factors and processes to test on a database, there is an increasing demand on the testers to be technically proficient in the key DB concepts. Despite some of the negative beliefs that DB testing creates new bottlenecks and is a lot of additional expenditure – this is a realm of testing that is attracting significant attention and demand.

I hope this article has helped to focus on why that is so and has also provided you with the basic details of what goes into testing a database.

Please let us know your feedback and also share your personal experiences if you are working on  DB testing. 


85 thoughts on “Database Testing Guide (Why, How, and What About Database Testing)”

  1. Hi Vijay,
    It is indeed a very informative post. I was just wondering if you can in general tell us which will be a better option to go for: DATABASE Testing or AUTOMATION testing.
    Note: I am already Oracle Certified Professional(did it 3 years ago) and ISTQB CTFL. Now I am in manual testing(eg; website, software, process flow testing, simple database testing etc..). Want to grow professionally. So plz throw some light.

    Thanks,
    Sachin

  2. Very interesting article,database testing is often seen as a overhead. But does not have to be. With testing tools such as SOAP UI you can also build database assertions with SOAP UI JDBC functionality.
    In this way you can build Sql queries into your automated tests. When testing at the web service layer.

  3. Hi, all. I have a question. What if the tested does not know the DB at all of a project and mostly on same project working on UI side? If tester has to test DB related to a test case how a tester can find out which table to use, how to use it, should required document have table name already written or tested himself need to find in DB?

  4. is there any tools or ide that can i use for database testing whether i can check that data flow is correct and following the parenting data sequence ? i am a fresher tester joined in the job 3 days ago. My project manager told me to test the database with data input. So i am in dilemma what should i do. I simply want to load that sql or dba file into the tools and manually input some data that will check my database working flow….
    please help me out. Since the day 1 of my job i am following this website and helped me a lot.

  5. DataBase perfomance testing is basically testing your sql queries. Infact this is done in unit testing or by SQL DBA.
    In SQL Server. In sql server 2000 there was a tool called Qery Analyzer. Frm SQL SErver 2005 onwards Micrsoft changed everything to Managment Studio. In management studio there is something called execution plan. Execution plans can tell you how a query will be executed, or how a query was executed.
    There are 2 major stages are there
    1. Processes that occur in the relational engine
    2. Processes that occur in the storage engine.
    In the relational engine the query is parsed and then processed by the Query Optimizer

  6. hi,
    I’m testing payment gateway how i’ll make sure that user data and transaction is secure from third party? Basically i want to test security of Payment Gateway.

  7. Hello Guys,

    I wanted to know the queries to be used in database testing alone with proper database testing concepts
    Can you please do the needful

    Thanks

  8. Hello Guys,

    I want to do the database testing and quite puzzled as I am not sure how to do the database testing .. not sure about the queries to be used
    Can you guys please add the queries and interview questions for database testing

    Thanks

  9. Thank you for the article. Many of the things described is what I’m doing, but it’s always helpful to name them, which helps put things into another perspective.

Leave a Comment