First of all let us quickly understand as to what are the Relational Datatbases

Relational databases are tabular databases that are used to store target related data that can be easily reorganized
and queried. They are used in many applications by millions of end users.

What are the key aspects of Database Testing?

1) Testing of the actual data.

2) Database integrity.

3) Functionality testing of database application.

The users may access, update, delete or append to the database. The modified database should be error free. To
make the database error free and to deliver the quality product, regression testing of the database must be done.
Regression testing involves retesting of database again and again to ensure that it is free of all errors. It is a
relatively new idea in the data community. Agile software developers take this approach to the application code.

Why should we test a RDBMS?

Extensive testing of RDBMS is done due to the following reasons:

1) Quality data is an important asset: According to a survey on the importance of quality data following
conclusions were drawn:

a) 95.7% of people believed that data is a corporate asset.

b) 4.3% believed that data is not a corporate asset.

c) Out of the 95.7%, 40.3% had a test suite for data validation.

d) 31.6% discussed the importance of data.

2) Target related business functions are implemented in RDBMS: RDBMS should focus on mission-critical
business functionality.

3) Present approaches of RDBMS testing are inefficient: Presently we develop a database by setting up
database, write code to access the database, run code, and do SELECT operation to find the query results.
Although visual inspection is a good start, it may help us to find problems but not prevent them.

4) Testing provides a concrete test suite to regression test an RDBMS: Database regression testing is the
act of running the database test suite on a regular basis. This includes testing of actual data, database integrity,
ensuring that database is not corrupted, schemas are correct as well as the functionality testing of database
applications.

5) Verification of all modifications: Making changes to the database, may result in some serious errors like
missing-data and regression testing may help us in detecting such missing - data.

What should be Tested in Relational Database?

Here we will be discussing both Black Box and White Box testing approaches on relational databases.

Black Box Testing involves the following:

1) I/O Validation: Regression testing will help us in validating incoming data-values; outgoing data -values from
queues, stored- functions and views.

2) Error Handling: Regression testing of an RDBMS allows us to test quasi-nulls that is, empty strings are not
allowed.

3) Validating Table Structure: We can validate the relationships between the rows in different tables. This is
known as referential integrity. For example: if a row in an employee table references a row within the position
table then that row should actually exist.

4) Testing interaction between SQL and other components such as scripts: Regression testing allows
testing of interfaces between SQL and scripts by techniques such as parameter passing.

5) Testing of stored data: Data stored in the form of tables can be tested extensively by regression testing.

6) Testing of modified data: Updating the tables might introduce new errors which can be easily detected by
regression testing.

White Box testing involves the following:

1) Testing of the entire structure of stored procedures and functions: Entire schema can be tested by
regression testing. We can refactor our database tables into structures, which are more performant. The process of
refactoring here means a small change to a database schema, which improves its design without changing its
semantics. It is an evolutionary improvement of our database schema, which will support three things:

a) New needs of our customers.

b) Evolutionary software development.

c) Fix legacy database design problems.

2) Testing various stimulations: Regression testing allows unit testing of stored procedures, functions and
triggers. The idea is that the testis automatically run via a test framework and success or failure is indicated via a
Boolean flag.

3) Testing all views: Regression testing allows an extensive testing of all the three views viz, conceptual, logical
and physical.

4) Testing of all data constraints: Regression testing allows testing of all data constraints like null values,
handling single quote in a string field, handling comma in an integer field, handling wrong data types, large size
value, large size string etc.

5) Improving the quality of data: Data quality may range from syntactic mistakes to undetectable dirty data.
Data quality involves four C's i.e., Correctness, Completeness, Comprehension and Consistency.

Correctness of Database: Regression testing provides a correct database by removing the following errors

a) Incorrect manipulation through the use of views.

b) Incorrect joins performed using non-key attributes.

c) Integrity constraints incorrectly used.

d) CHECK, UNIQUE and NULL constraints, which cause problems with data insertion, updations and deletions.
When should we test a Database?

Testing of databases involves initial testing of database and database refactoring. This strategy can be applied
concurrently to both the application code and the database schema. Testing of databases is done not only during
the release but also during the development.

New software developers follow Test-First Approach wherein a test case is first written and then code is written
which will fulfill this test.

A) Step by step approach is as under:

Step - 1: A test is added for just enough code to fail.

Step - 2: Tests are then run to make sure that the new tests does in fact fail.

Step - 3: Functional code is then updated so that it passes the new tests.

Step - 4: Tests are run again.

Step - 5: If tests fail, update functional code again and retest.

Step - 6: Once the tests pass, next step is start again.

B) Test First Approach: TFA is also known as initial testing of database.

Test Driven Development: TDD is a progressive approach. It comprises TFA and refactoring (Regression testing).

This can be expressed in form of a equation:

TDD = TFA + Refactoring

The process of refactoring here means a small change to a database schema, which improves its design without
changing its semantics. It is an evolutionary improvement of our database schema, which will further support
following three things:

1) New needs of our customers.

2) Evolutionary software development.

3) Fix legacy database design problem.

What are the typical steps involved in Testing Databases?

Database testing primarily involves two key activities like:

A) Organising Sandboxes

B) Developing Test Cases

Now let us discuss these two key activities in detail

A) Key Activity - 1: Organising Sandboxes: Database testing involves the need of a copy of databases which
are called sandboxes. These sandboxes are of following three types

1) Functionality Sandbox: In this we check the new functionality of database and refactor the existing
functionality. Then we pass the tested sandbox to the next stage, which is integrated sandbox.

2) Integrated Sandbox: In this we integrate all the sandboxes and then test the system.
3) QA sandbox: After the system is tested, sandboxes are sent for acceptance testing. This will ensure the quality
of the database.

B) Key Activity - 2: Development of test cases: The step by step procedure for the development of test cases
is as under:

Step - 1: Setting up of the test cases: Set up the database to a known state.

The sources of test data are

1) External test data.

2) Test scripts.

3) Test data with known values.

4) Real world data.

Step - 2: Running the test cases : The test cases are then run. The running of the database test cases is
analogous to usual development testing.

Traditional Approach of Test Case Execution:

Test cases are executed on the browser side. Inputs are entered on web-input forms and data i submitted to the
back-end database via the web browser interface. The results sent back to the browser are then validated against
expected values.

Advantages of Traditional Approach: It is simple and no programming skill is required. It not only addresses thi
functionality of stored procedures, rules, triggers and data integrity but also the functionality of application as a
whole.
Disadvantages of Traditional Approach:

1) Sometimes the results sent to the browser after test case execution do no necessarily indicate that the data
itself is properly written to a record in the table.

2) When erroneous results are sent back to the browser after the execution of test cases, it doesn't necessarily
mean that the error is a database error.

3) A crucial danger with database testing and with regression testing in specific is coupling between tests. If we put
the database in to a known state, run several tests against that known states, before setting it, then those tests
are potentially coupled to one another.

Advanced Approach of Test Case Execution:

First of all we need to do a schematic preparation for Database Testing, which involves:

Generate a list of database tables, stored procedures, triggers, defaults, rules and so on. This will help us to have a
good handle on the scope of testing required for database testing.

Thereafter we can follow the following points:

1. Generate data schemata for tables. Analyzing the schema will help us determine the following:

# Can a certain field value be Null?

# What are the allowed or disallowed values?

# What are the constraints?

# Is the value dependent upon values in another table?

# Will the values of this field be in the look-up table?

# What are user defined data types?

# What are primary key and foreign key relationships among tables?

2. At a high level, analyze how the stored procedures, triggers, defaults and rules work. This will help
us determine the following:

# What is the primary function of each stored procedure and trigger? Does it read data and produce outputs, write
data or both?

# What are the accepted parameters?

# What are the return values?

# When is the stored procedure called and by whom?

# When is a trigger fired?

3. Determine what the configuration management process is. That is how the new tables, stored procedures,
triggers and such are integrated.

Step - 3: Checking the results: Actual database test results and expected database test results are compared in
this step as described in the following example.
CREATE FUNCTION f_is leapyear (@ ai_year small int)

RETURNS small int

AS

BEGIN

-if year is illegal (null or -ve ), return -1

IF (@ ai_year IS NULL) or

(@ ai_year <=0) RETURN -1

IF (((@ ai_year % ) = 0) AND

((ai_year % 100) <> 0)) OR

((ai_year % 400) = 0)

RETURN 1 -leap year

RETURN 0 - Not a leap year

END

Following test cases are derived for the above piece of code:

Test_id Year (Year to Expected Observed Match

Test) Result Result

1 -1 -1 -1 Yes

2 -400 -1 -1 Yes

3 100 0 0 Yes

4 1000 0 0 Yes

5 1800 0 0 Yes

6 1900 0 0 Yes

7 2010 0 0 Yes

8 400 1 1 Yes

9 1600 1 1 Yes

10 2000 1 1 Yes

11 2400 1 1 Yes

12 4 1 1 Yes

13 1204 1 1 Yes
 14 1996 1 1 Yes

15 2004 1 1 Yes

Who is best suited for Testing the Database?

Key individuals responsible for doing database testing are application developers and agile database administrators. They will
typically pair together and will perform pair testing which is an extension of pair programming. Pair database testing has following
advantages. Firstly testing becomes a real time interaction. Secondly, discussions are involved throughout.

The database testers are also responsible for procuring database-testing tools for the organization.

Some of the dataset testing CASE tools are described below:

Category of Meaning Examples

Testing

UNIT TESTING Tools, which enable us to DBUnit, SQL Unit.

TOOLS regression test our database.

LOAD TESTING These tools will test whether Mercury Interactive,

TOOLS our system will be able to Rational Suite, Test
stand high conditions of load. Studio.

TEST DATA They help to generate large Data Factory, Turbo

GENERATOR amounts of data for stress Data.
and load testing.

Q.1: How can we unit test our databases?

We can test stored procedures by executing SQL statements one at a time against known results. Then the results
can be validated with expected results. This is similar to unit testing.

<<<<<< =================== >>>>>>

Q.2: What are certain points that are to be kept in mind during database testing?

Following four important points need to be kept in mind.

(1) I/O validations and error handling must be done outside of the stored procedures.

(2) Do thorough analysis to design black-box test cases that produce problematic inputs that would break the
constraints.

(3) Testing the interaction between SQL and other components like scripts.

(4) Understanding how to use database tools to execute SQL statements can improve our ability to analyze web-
based errors like it helps us to determine whether an error is in the stored procedure code, the data itself or in the
components outside the database.

<<<<<< =================== >>>>>>

Q.3: What sort of tests may be carried out during database testing?

(1) SQL databases may not be able to accept special characters (like $, @, &) as valid inputs.
(2) Data sent to the database server may be corrupted due to packet losses caused by slow connections.

(3) Proper implementation of database rollback logic. Otherwise, it causes data corruption. Design your test cases
to exercise those critical areas.

(4) Check for complete loading of tables in the database.

(5) Check for proper error handling.

(6) Check that your server does not run out of disk space.

<<<<<< =================== >>>>>>

Q.4: What are milestone tests?

Milestone tests are performed prior to each development milestone. They are scheduled according to the milestone
plan.

<<<<<< =================== >>>>>>

Q.5: What sort of errors are handled at the client side and at the server side?

Simple errors such as invalid inputs should be handled at the client side. Handling error conditions can be done at
the server side.