Database (Data) Testing Tutorial with Sample Test

Cases
The GUI is in most cases given the most emphasis by the respective test managers as well as
the development team members since the Graphical User Interface happens to be the most
visible part of the application. However what is also important is to validate the information
that can be considered as the heart of the application aka DATABASE.

Let us consider a Banking application whereby a user makes transactions. Now from
database testing viewpoint following things are important:

1. The application stores the transaction information in the application database and
displays them correctly to the user.

2. No information is lost in the process.

3. No partially performed or aborted operation information is saved by the application.

4. No unauthorized individual is allowed to access the users information.

To ensure all these above objectives, we need to use data validation or data testing.

In this tutorial, we will study

Difference Between GUI and Database Testing

Types of Database Testing
Schema Testing
Database table, column testing
Stored procedures testing
Trigger testing
Database server validations
Functional database testing
Login and user security
Load testing
Stress testing
 Myths or Misconceptions related to Database Testing
Best Practices

Fundamental differences between user-interface and

data testing

User-Interface testing Database or Data testing

This type of testing is also known as This type of testing is also known as Back-end Testing
Graphical User Interface testing or or data testing.
Front-end Testing.

This type of testing chiefly deals with
all the testable items that are open
to the user for viewership and
interaction like Forms, Presentation,
Graphs, Menus, and Reports, etc.
(created through VB, VB.net, VC++,
This type of testing chiefly deals with all the testable
items that are generally hidden from the user for
viewership. These include internal process and
storage like Assembly, DBMS like Oracle, SQL Server,
MYSQL, etc.
Delphi - Frontend Tools )

This type of testing include validating This type of testing involves validating
the
the schema,
text boxes,
database tables,
select dropdowns,
columns ,
calendars and buttons,
keys and indexes,
navigation from one page to another,
stored procedures,
display of images as well as
triggers ,
Look and feel of the overall
application. database server validations,

validating data duplication,

The tester must be thoroughly
knowledgeable about the business
requirements as well as the usage of
the development tools and the usage
of automation framework and tools.
The tester in order to be able to perform back-end
testing must have a strong background in the
database server and Structured Query Language
concepts.
Types of database testing

The 3 types of Database Testing are

1. Structural Testing

2. Functional Testing

3. Non-functional Testing

Lets look into each type and its sub-types one by one.

Structural database testing

The structural data testing involves the validation of all those elements inside the data
repository that are used primarily for storage of data and which are not allowed to be
directly manipulated by the end users. The validation of the database servers is also a very
important consideration in these types of testing. The successful completion of this phase
by the testers involves mastery in SQL queries.

Schema testing
The chief aspect of schema testing is to ensure that the schema mapping between the front
end and back end are similar. Thus, we may also refer to schema testing as mapping
testing.
Let us discuss most important checkpoints for schema testing.

1. Validation of the various schema formats associated with the databases. Many times
the mapping format of the table may not be compatible with the mapping format present
in the user interface level of the application.

2. There is the need for verification in the case unmapped tables/views/columns.

3. There is also a need to verify whether heterogeneous databases in an environment

are consistent with the overall application mapping.

Let us also look at some of the interesting tools for validating database schemas.

DB Unit that is integrated with Ant is a very suitable for mapping testing.
SQL Server allows the testers to be able to check and to query the schema of the
database by writing simple queries and not through code.

For example, if the developers want to change a table structure or delete it, the tester would
want to ensure that all the Stored Procedures and Views that use that table are compatible
with the particular change. Another example could be that if the testers want to check for
schema changes between 2 databases, they can do that by using simple queries.

Database table, column testing

Let us look into various checks for database and column testing.

1. Whether the mapping of the database fields and columns in the back end is
compatible with those mappings in the front end.

2. Validation of the length and naming convention of the database fields and columns as
specified by the requirements.

3. Validation of the presence of any unused/unmapped database tables/columns.

4. Validation of the compatibility of the

data type
field lengths
 Of the backend database columns with that of those present in the front end of the
application.

5. Whether the database fields allow the user to provide desired user inputs as required
by the business requirement specification documents.

Keys and indexes testing

Important checks for keys and indexes -

1. Check whether the required

Primary key
Foreign Key

Constraints have been created on the required tables.

2. Check whether the references for foreign keys are valid.

3. Check whether the data type of the primary key and the corresponding foreign keys
are same in the two tables.

4. Check whether the required naming conventions have been followed for all the keys
and indexes.

5. Check the size and length of the required fields and indexes.

6. Whether the required

Clustered indexes
Non Clustered indexes

Have been created on the required tables as specified by the business requirements.

Stored procedures testing

The list of the most important things which are to be validated for the stored procedures.

1. Whether the development team did adopt the required

 coding standard conventions
exception and error handling

For all the stored procedures for all the modules for the application under test.

2. Whether the development team did cover all the conditions/loops by applying the
required input data to the application under test.

3. Whether the development team did properly apply the TRIM operations whenever
data is fetched from the required tables in the Database.

4. Whether the manual execution of the Stored Procedure provides the end user with
the required result

5. Whether the manual execution of the Stored Procedure ensures the table fields are
being updated as required by the application under test.

6. Whether the execution of the Stored Procedures enables the implicit invoking of the
required triggers.

7. Validation of the presence of any unused stored procedures.

8. Validation for Allow Null condition which can be done at the database level.

9. Validation of the fact that all the Stored Procedures and Functions have been
successfully executed when the Database under test is blank.

10. Validation of the overall integration of the stored procedure modules as per as the
requirements of the application under test.

Some of the interesting tools for testing stored procedures are LINQ, SP Test tool etc.

Trigger testing
1. Whether the required coding conventions have been followed during the coding
phase of the Triggers.
2. Check whether the triggers executed for the respective DML transactions have fulfilled
the required conditions.

3. Whether the trigger updates the data correctly once they have been executed.

4. Validation of the required Update/Insert/Delete triggers functionality in the realm of

the application under test.

Database server validations

1. Check the database server configurations as specified by the business requirements.

2. Check the authorization of the required user to perform only those levels of actions
which are required by the application.

3. Check that the database server is able to cater to the needs of maximum allowed
number of user transactions as specified by the business requirement specifications.

Functional database testing

The Functional database testing as specified by the requirement specification needs to
ensure most of those transactions and operations as performed by the end users are
consistent with the requirement specifications.

Following are the basic conditions which need to be observed for database validations.
 Whether the field is mandatory while allowing NULL values on that field.
Whether the length of each field is of sufficient size?
Whether all similar fields have same names across tables?
Whether there are any computed fields present in the Database?

This particular process is the validation of the field mappings from the end user viewpoint.
In this particular scenario the tester would perform an operation at the data base level and
then would navigate to the relevant user interface item to observe and validate whether the
proper field validations have been carried out or not.

The vice versa condition whereby first an operation is carried out by the tester at the user
interface and then the same is validated from the back end is also considered to be a valid
option.

Checking data integrity and consistency

Following checks are important

1. Whether the data is logically well organized

2. Whether the data stored in the tables is correct and as per the business requirements.

3. Whether there are any unnecessary data present in the application under test.

4. Whether the data has been stored as per as the requirement with respect to data
which has been updated from the user interface.

5. Whether the TRIM operations performed on the data before inserting data into the
database under test.

6. Whether the transactions have been performed according to the business

requirement specifications and whether the results are correct or not.

7. Whether the data has been properly committed if the transaction has been
successfully executed as per the business requirements.

8. Whether the data has been roll backed successfully if the transaction has not been
executed successfully by the end user.
9. Whether the data has been roll backed at all in the condition that the transaction has
not been executed successfully and multiple heterogeneous databases have been
involved in the transaction in question.

10. Whether all the transactions have been executed by using the required design
procedures as specified by the system business requirements.

Login and user security

The validations of the login and user security credentials need to take into consideration the
following things.

1. Whether the application prevents the user to proceed further in the application in
case of a

invalid username but valid password

Valid username but invalid password.
Invalid username and invalid password.
Valid username and a valid password.

2. Whether the user is allowed to perform only those specific operations which are
specified by the business requirements.

3. Whether the data secured from unauthorized access

4. Whether there are different user roles created with different permissions

5. Whether all the users have required levels of access on the specified Database as
required by the business specifications.

6. Check that sensitive data like passwords, credit card numbers are encrypted and not
stored as plain text in database. It is a good practice to ensure all accounts should have
passwords that are complex and not easily guessed.

Non-functional testing
Nonfunctional testing in the context of database testing can be categorized into various
categories as required by the business requirements. These can be load testing, stress
testing, security testing, usability testing, and compatibility testing and so on. The load
testing as well as stress testing which can be grouped under the gamut of performance
testing serves two specific purposes when it comes to the role of nonfunctional testing.

Risk quantification- Quantification of risk actually helps the stakeholders to ascertain the
various system response time requirements under required levels of load. This is the
original intent of any quality assurance task. We need to note that load testing does not
mitigate risk directly, but through the processes of risk identification and of risk
quantification, presents corrective opportunities and an impetus for remediation that will
mitigate risk.

Minimum system equipment requirement- The understanding which we observe through

formal testing, the minimum system configuration that will allow the system to meet the
formal stated performance expectations of stakeholders. So that extraneous hardware,
software and the associated cost of ownership can be minimized. This particular
requirement can be categorized as the overall business optimization requirement.

Load testing
The purpose of any load test should be clearly understood and documented.

The following types of configurations are a must for load testing.

1. The most frequently used user transactions have the potential to impact the
performance of all of the other transactions if they are not efficient.

2. At least one non-editing user transaction should be included in the final test suite, so
that performance of such transactions can be differentiated from other more complex
transactions.

3. The more important transactions that facilitate the core objectives of the system
should be included, as failure under load of these transactions has, by definition, the
greatest impact.

4. At least one editable transaction should be included so that performance of such

transactions can be differentiated from other transactions.
5. The observation of the optimum response time under huge number of virtual users
for all the prospective requirements.

6. The observation of the effective times for fetching of various records.

Important load testing tools are load runner, win runner and Jmeter.

Stress testing
Stress testing is also sometimes referred to as torturous testing as it stresses the application
under test with enormous loads of work such that the system fails .This helps in identifying
breakdown points of the system.

Important stress testing tools are load runner, win runner and JMeter.

Most common occurring issues during database testing

1. Significant amount of overhead could be involved in order to determine the state of

the database transactions.

2. Solution: The overall process planning and timing should be organized so that no time
and cost based issues appear.

3. New test data have to be designed after cleaning up of the old test data.

4. Solution: A prior plan and methodology for test data generation should be at hand.

5. An SQL generator is required to transform SQL validators in order to ensure the SQL
queries are apt for handling the required database test cases.

6. Solution: Maintenance of the SQL queries and their continuous updating is a

significant part of the overall testing process which should be part of the overall test
strategy.

7. The above mentioned prerequisite ensure that the set-up of the database testing
procedure could be costly as well as time consuming.

8. Solution: There should be a fine balance between quality and overall project schedule
duration.
Myths or Misconceptions related to Database Testing.

1. Database Testing requires plenty of expertise and it is a very tedious job

Reality: Effective and efficient Database testing provides long-term functional stability
to the overall application thus it is necessary to put in hard work behind it.

2. Database testing adds extra work bottleneck

Reality: On the contrary, database testing adds more value to the overall work by
finding out hidden issues and thus pro-actively helping to improve the overall
application.

3. Database testing slows down the overall development process

Reality: Significant amount of database testing helps in the overall improvement of

quality for the database application.

4. Database testing could be excessively costly

Reality: Any expenditure on database testing is a long-term investment which leads to

long-term stability and robustness of the application. Thus expenditure on database
testing is necessary.
Best Practices
All data including the metadata as well as the functional data needs to be validated
according to their mapping by the requirement specification documents.
Verification of the test data which has been created by / in consultation with the
development team needs to be validated.
Validation of the output data by using both manual as well as automation procedures.
Deployment of various techniques such as the cause effect graphing technique,
equivalence partitioning technique and boundary-value analysis technique for generation
of required test data conditions.
The validation rules of referential integrity for the required database tables also need
to be validated.
The selection of default table values for validation on database consistency is a very
important concept Whether the log events have been successfully added in the database
for all required login events
Does scheduled jobs execute in timely manner?
Take timely backup of Database.

Top 25 Database Testing Interview Questions &

Answers
1) What is data-base testing?

Data base Testing is segmented into four different categories.

Testing of Data Integrity

Testing of Data Validity
Data base related performance
Testing of functions, procedure and triggers
2) In database testing, what do we need to check normally?

Normally, the things that we check in database testing are:

 Constraint Check
Validation of a Field size
Stored procedure
Matching application field size to database
Indexes for performance based issues
3) Explain what is data driven test?

In a data-table, to test the multi numbers of data, data-driven test is used. By using this it
can easily replace the parameters at the same time from different locations.

4) What are joins and mention different types of joins?

Join is used to display two or more than two table and the types of joins are:

Natural Join
Inner Join
Outer Join
Cross Join
The outer join is divided again in two:

Left outer join

Right outer join
5) What are indexes and mention different types of indexes?

Indexes are database objects and they are created on columns. To fetch data quickly they
are frequently accessed. Different types of indexes are:

B-Tree index
Bitmap index
Clustered index
Covering index
Non-unique index
Unique index
6) While testing stored procedures what are the steps does a tester takes?

The tester will check the standard format of the stored procedures and also it checks the
fields are correct like updates, joins, indexes, deletions as mentioned in the stored
procedure.

7) How would you know for database testing, whether trigger is fired or not?
On querying the common audit log you would know, whether, a trigger is fired or not. It is in
audit log where you can see the triggers fired.

8) In data base testing, what are the steps to test data loading?

Following steps need to follow to test data loading

Source data should be known

Target data should be known
Compatibility of source and target should be checked
In SQL Enterprise manager, run the DTS package after opening the corresponding DTS
package
You have to compare the columns of target and data source
Number of rows of target and source should be checked
After updating data in the source, check whether the changes appears in the target or
not.
Check NULLs and junk characters
9) Without using Database Checkpoints, how you test a SQL Query in QTP?

By writing scripting procedure in VBScript, we can connect to database and can test the
queries and database.

10) Explain how to use SQL queries in QTP?

In QTP using output database check point and database check, you have to select the SQL
manual queries option. After selecting the manual queries option, enter the "select" queries
to fetch the data in the database and then compare the expected and actual.

11) What is the way of writing test cases for database testing?

Writing a test cases is like functional testing. First you have to know the functional
requirement of the application. Then you have to decide the parameters for writing test
cases like

Objective: Write the objective that you would like to test

Input method: Write the method of action or input you want to execute
Expected: how it should appear in the database
12) To manage and manipulate the test table what are the SQL statements that you
have used in Database testing?

The statements like SELECT, INSERT, UPDATE, DELETE are used to manipulate the table, while
ALTER TABLE, CREATE TABLE and DELETE TABLE are used to manage table.
13) How to test database procedures and triggers?

To test database procedures and triggers, input and output parameters must be known.
EXEC statement can be used to run the procedure and examine the behavior of the tables.

Open the database project in solution explorer

Now in View menu, click the database schema
Open the project folder from schema View menu
Right click on the object that has to be tested, and then click on the dialog box that
says Create Unit Tests
After that create a new language test project
Select either a) Insert the unit test or b) Create a new test and then click OK
Project that has to be configured will be done by clicking on the Project Configuration
dialog box.
Once it configured click on OK
14) How you can write test cases from requirements and do the requirements
represents exact functionality of AUT (Application under Test)?

To write a test cases from requirements, you need to analyze the requirements thoroughly
in terms of functionality. Thereafter you think about the appropriate test cases design
techniques like Equivalence partitioning, Black box design, Cause effect graphing etc. for
writing the testcases.Yes, the requirements represent exact functionality of AUT.

15) What is DBMS?

DBMS stand for Database management system, there are different types of DBMS

Network Model
Hierarchical Model
Relational Model
16) What is DML?

DML stands for Data Manipulation Language, It is used to manage data with schema objects.
It is a subset of SQL.

17) What are DCL commands? What are the two types of commands used by DCL?

DCL stands for Data Control Language, it is used to control data.

The two types of DCL Commands are:

Grant: By using this command user can access privilege to database

Revoke: By using this command user cannot access the database

18) What is white box testing and black box testing?

Black box testing means testing the software for the outputs on giving particular inputs. This
testing is usually performed to see if the software meets the user's requirements. There is
no specific functional output expected for running this test.

The white box testing is done to check the accuracy of code and logic of the program. This
testing is done by the programmer who knows the logical flow of the system.

19) How does QTP evaluate test results?

Once the testing is done, QTP will generate a report. This report will show the checkpoints,
system message and error that were detected while testing. The test results window will
show any mismatches encountered at the checkpoints.

20) Explain the QTP testing process?

QTP testing process is based on following steps:

Creating GUI (Graphical User Interface) Map files : Identifies the GUI object which has
to be tested
Creating test scripts: Test scripts are recorded
Debug tests: Test should be debugged
Run tests: Test cases should be run.
View results: The results reflects the success or failure of the tests
Report detects: If the test is failed, the reasons will be recorded in the report detect
file
21) What is load testing and give some examples of it?

To measure the system response, load testing is done. If the load exceeds the users pattern
it is known as stress testing. Examples of load testing are downloading the set of large files,
executing multiple applications on a single computer, subjecting a server to large number of
e-mails and allotting many tasks to a printer one after another.

22) How to test database manually?

Testing the database manually involves checking the data at the back end and to see
whether the addition of data in front end is affecting the back end or not, and same for
delete, update, insert etc.

23) What RDBMS stands for and what are the important RDMBS that SQL use?
RDBMS stands for Relational Database Management Systems that use SQL, and the
important RDBMS that SQL uses are Sybase, Oracle, Access ,Ingres, Microsoft SQL server etc.

24) What is performance testing and what are the bottlenecks of performance
testing?

Performance testing determines the speed of the computer system performance. It includes
the quantitative tests like response time measurement. The problem in performance testing
is that you always need a well-trained and experienced man power also the tools you use
are expensive.

25) What is DDL and what are their commands?

To define database structure, DDL is used. DDL stands for Data Definition Language. The
various DDL commands include Create, Truncate, Drop, Alter, Comment and Rename.