All About Database Testing – Why to Test, How to Test, and What to Test?

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. (image credit)

DB Testing

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

Data Integrity Testing

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.

How to test – Database Testing Process

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 the “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).

  • Create table: Create table<tablename> (field1 datatype(field size) ,……………..fieldn datatype(field size))
  • Delete entire table: Drop table <tablename>. – this command cannot be rolled back

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

  • To insert a row into a DB: INSERT INTO <table name> (field1, field2, field3)  VALUES  (‘val1′, ‘val2′…’valn’);
  • Delete specific row/rows from a table: DELETE FROM TABLENAME WHERE <required condition>.
  • Update rows: UPDATE <tablename> SET field1 = ‘updated value’ WHERE field2 = ‘N’;

Data control language: Deals with giving the 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.

The following are the statements commonly used:

  • BEGIN TRANSACTION TRANSACTION#
  • END TRANSACTION TRANSACTION#

Rollback statement ensures that the database lies in a consistent state.

  • ROLLBACK TRANSACTION#

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

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

2) Database schema:

Database schema is nothing but a formal definition of the how the data is going to be organized into 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 searching.
    • 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 ways 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 be adding the student to the corresponding subject tables once he is added to the student table.

The common method to test is to execute 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 during both the black box and white box testing phases.

  • White box testing:  Stubs and drivers are 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) 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 a 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 frontend(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 overruns the database object condition
  • Validate the results with a SQL Query.

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

The following is a sample VBScript code:

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

The result to 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 gets displayed.

Automation VB script code can be:

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

For the foreign key constraint validation use data loads that directly input data that violates the constraint and see if the application restricts the same or not. Along with the back end data load, perform the front end UI operations too in a way that are going to 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 tester to be technically strong with the key DB concepts. Despite some of negative beliefs that the DB testing creates new bottlenecks and is a lot of additional expenditure – this is a realm of testing that is gaining obvious attention and demand.

I hope this article has helped to focus on why that is so and also has 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 have done this before. Your comments and feedback is important to us and our readers to learn from your experience.

If you Like it, Share it!



The Best Software Testing Training You'll Ever Get!

software testing QA training

33 comments ↓

#1 Sahil on 08.12.13 at 11:58 am

Awesome share Vijay…was needing it

#2 Kapil Sharma on 08.12.13 at 12:35 pm

Again one of the greatest and deepest post from software testing help.

You guys rock!

#3 AdarshTrivedi on 08.12.13 at 12:37 pm

@Vijay please tell me what is most important feature to be tested during database testing and what factors kept in mind before starting database testing for a simple desktop based application.

#4 Bidya Paul on 08.12.13 at 12:43 pm

Thanks a lot Vijay… was awaiting for this concepts

#5 Pravin on 08.12.13 at 5:53 pm

Thanks a lot

#6 Hema on 08.12.13 at 6:10 pm

vijay can u please help us in DB testing like QTP tutorials.

as well as the key features in DB Testing. Thanks a lot for the article.

#7 Kanif on 08.12.13 at 6:33 pm

Once again great article Vijay, its really to the point.

Few nice database testing articles on below link:
http://www.softwaretestingclass.com/category/database-testing/

#8 Sunil on 08.12.13 at 10:59 pm

Thanks a lot ….Gr8 job…..

#9 Preet on 08.13.13 at 2:56 am

Good one…really very knowledgeable. Thanks.

#10 Topher on 08.13.13 at 4:12 am

This is great article and very concise and straightforward information. It gives me an idea on how to test database. Actually, I am only doing Manual Testing. I am interested to learn on how test DB. Thank you.

#11 Suresh on 08.13.13 at 5:26 am

Very Useful post!! Thanks

#12 Vins on 08.13.13 at 5:42 am

Gr8 Vijay……really very useful.

Thanks a lot for such a wonderful article.

#13 nivedita on 08.13.13 at 6:30 am

very helpful……a complete package for my students!! thankyou admin!!!! keep goin guys!!

#14 Mallikarjun on 08.13.13 at 9:10 am

Vijay,

Simply superb, appreciate you. Keep on posting and do help to the job seekers your level best.

#15 neha on 08.14.13 at 9:29 am

Hi

Very informative.
Could you please answer the question :’What are the challenges faced while doing DB testing”?

#16 Aswathy on 08.15.13 at 1:45 am

hi vijay,
u r doing a great job…Thnx a lot….Its very helpful for ISTQB preperation…

#17 Kishore on 08.16.13 at 12:41 pm

Very nice post. Thanks Vijay

#18 Debanjan on 08.17.13 at 6:40 am

@AdarshTrivedi

There is no such thing as most important feature during a database testing.

Everything depends upon whatever the business objective.

If for example say it is a data transformation and data conversion project then it would be very important to validate the business rules as well as data integrity before and after the application of the business rule logic.

If it is a data load project from one database to another then the mapping between the different columns in the source and target databases need to be validated.

In general database schema , database mapping , data integrity , consistency between front end and back end data and validation of the business rules are considered as most important.

It all depends upon what type of desktop application you have to validate. If it involves data transactions then data consistency between front end and back end , data integrity during transactions and business rule validations need to be taken into consideration.

I hope it helps you to understand the issue in question.

Take care
Debanjan

#19 mahalaxmi on 09.03.13 at 4:20 pm

hi Friends

can any body know “what is save point ?” explain me with examples. Here i always confuse.

#20 Sangram Kumar Das on 09.04.13 at 11:38 am

Very useful post..This is going to help the testers who are new to the DB testing..Thanks :)

#21 Rupalli Jadhav on 09.07.13 at 10:38 am

explanation of db testing is very useful,and explnation of subject is so simple

#22 rafeeq on 09.11.13 at 2:43 am

I am not comfortable in sql can I do software testing or not

#23 Federico Razzoli on 10.13.13 at 10:35 am

@Rupalli Jadhav. I suppose you can do SOME tests even if you don’t know SQL, as long as you can use an API to modify your database. For example, if a foreign key is supposed to perform an action when you delete a record from a table, you can delete the record using an API. But I definitely recommend some SQL skills, to test an RDBMS.

#24 Arivazhagan on 10.25.13 at 7:26 am

it’s really very helpful .

#25 SANDY on 12.21.13 at 5:13 pm

GUD JOB……….

#26 sheeba mathew on 04.01.14 at 9:03 am

Stupendous

#27 Deepika on 04.12.14 at 12:30 pm

Thanks so much Vijay … it’s very useful … Good Job your doing …

#28 Sanjeev on 04.16.14 at 7:36 am

Great Job Vijay

#29 Swathi on 05.02.14 at 7:29 am

This article is very good.I found useful when my interview scheduled in sometime..

#30 vijayc on 05.30.14 at 11:47 am

what are the shortest testing techniques to test a page ?
(we have to tell BVA, ECP,Response time

#31 vijayc on 05.30.14 at 11:48 am

how many times u take NCR?

#32 Prabhu on 06.25.14 at 5:09 am

used your web page for many issues and it was very helpfull.
Thx,
Prabhu

#33 shiva on 07.20.14 at 11:46 am

This information was very useful

Thank you

Leave a Comment