Introduction Background Database testing; why?

Introduction to database testing Importance of database testing Database testing estimation Database testing model Reviews Levels of database testing Challenges involved in database testing Database Test Summary Results Database testing metrics Database testing tools Conclusion Introduction In this paper, I would like to discuss few key areas of database testing which is relatively a new area in a testing industry. This paper consists of the following sub topics Importance of database testing Why, When, How to do database testing? Challenges involved Database testing tools Background In todays complex dynamic environment, testing plays an important role. There will not be any product which will get released into the market without adequate testing. It is eventually evident that, the testing practices, tools, methods are also in tremendous growth in the recent past at par with developmental growth. The complexity involved in construction of code, is equally there when it is tested with the mind set of destruction. Until now, most of the applications are tested to check the functionalities, performance, and security. This is considerably reducing the risk of deploying the application into the production and maintenance. Experiences prove that, the existing test practices are not sufficient to give confidence on the product release. There are many areas, which are untested still, which increases the scope of risk. In this paper, I would like to discuss on one such area, Database testing, which is widely opened for testing. Database testing; why? Mr. Kumar, a software engineer by profession was upset, when he was paying his credit card payments due. He was being charged double for his transaction. He could be able to remember, during the first time, the system has reported. Transaction not completed.Login again. Then, he was performing the same transaction once again, thus twice the system has updated the transaction into the database server. Kumar has spent two weeks of time, to follow up with the Bank for crediting the excess amount to his account. Another example, a leading MNC corporation, who has asked its employees to view the salary revision letter in the intranet, was down due to heavy load in the network. After this, the management decided to release the letter manually; this has delayed in salary payment on that month. In another similar scenario, Mr. Rajesh has filed a case against the bank for allowing the unauthorized person to use his password, for online transactions. Rajesh, in his complaint, has said that, while he was changing from old password to new password, the system was suddenly crashing. After that, he did not know, whether the system is accepting the old password or the newer one. Meanwhile, some one has used his password for performing online transactions. These are the some of the real time scenarios, which proves that, the existing test practices are not sufficient that the system is safe. Even though, White box testing and Black box

testing, finds the defects in code and functional, it is not guaranteed that, the system is performing as expected. In other words, everything is fine does not equal to safe. Data, which is a corporate asset, is continuously ignored from the requirements to user acceptance testing. Especially, while testing financial and bio medical applications, the database should be thoroughly tested. In this paper, I would like to present various aspects of database testing. Introduction to database testing Testing a database is relatively different from any traditional testing methods. Database testing is a planned activity. It starts as soon as Software Requirements Specification is baseline and continues to exist in the system until the system is going for retirement or further enhancement. In this view, testing a database is different from functional testing where testing stops on the following conditions. Requirements are met No major bugs are present Budget In database testing, the testing continues to exist even after deployment. One example would be testing a database growth. Database growth is a situation, where the volume of data keeps on increasing day by day. When the system reaches its peak load, the system may encounter the following situation. Delay in service Denial of service Lost of data Testing the application with traditional functionality and performance (volume testing, load testing) testing does not give sufficient information on internals of database. The entire organizations business, transactions, good will, reputations are in stake even when any of the data is not correct. So, due importance should be given for database testing from the early stage of development. Importance of database testing Database testing will identify the defects and the weakness from the design which is cheaper when the same is identified after construction. As the complexity of the real time business rules are increasing, testing only the functionality and performance would not be enough to have the confidence. The overall product quality is increased when the data are safe & secure are guaranteed. Especially, database testing includes testing the backup and recovery which is very important feature of the system. Database testing estimation Estimating the database testing is relatively similar like, estimating the functionality or performance. Various factors affecting the database testing are as follows. Total no. of requirements Normalization planned No. of tables No. of columns in every table No. of validations per table No .of relationships between tables No. of implicit and explicit procedure No. of complex scenario to be tested Database testing model To test a database, like V model, we can use database testing model which is as follows.

Reviews Reviews should be conducted at every phase of database development. Review team may consist of database development team member, customer, and a tester. The objective of performing review is to eliminate the defects in the database design and development. Each review will have different objective. For example, when the database architecture is reviewed, the tester would identify the defects from the relationships, joins, procedures.

Levels of review System design review The objective of system design review is to verify that the system will be able to function as a whole with the current design. The various types of reviews performed in this level are Database design Database design with external users Security Normalization process followed Whether adequate Capacity planning is followed Data redundancy check System and its environment Testing the database artifacts such as view/trigger/procedure Data base design with SRS Database growth Security design Structure of System log Structure of Transaction log Concurrency control Compatibility Architecture design review The objective of architecture design review is to verify that the system and its components interface with each other. The various types of reviews performed in this level are Relationship between tables Joins Indexes used Interface of database artifacts with the table Referential integrity Module design review The objective of module design review is to verify that the components have been designed properly. The various types of reviews performed in this level are Table design Data types Constraints Rules Compute columns Business rules Levels of database testing Static and dynamic testing should be done at every phase of development.

We can

categorize the database testing into three levels similar like traditional V model. But, there exist a difference between V model and database testing model. In database testing model, the customer would not be fine tuning database because it is more internal to the system. So, UAT would not be one of the levels of database testing. The following are the levels of database testing. Unit testing Integration testing System testing Unit testing The objective of unit testing is to verify that the components are properly constructed. The various types of types of testing performed in this level are Testing the constraints Data types Compute fields All DML operation Performing Boundary checks Performing checks on the data types (like image) NULL or Missing values Table definition Other than, the table definition, all other tests are generally black box oriented. The table definition is white box testing. We can test the definition of table. Integration testing The objective of integration testing is to verify that the components are properly working together. The various types of types of testing performed in this level are Relationships (such as one to one) Joins Foreign key constraints Views Trigger Procedures Functions All definitions are generally black box oriented. Functional testing is black box oriented. System testing The objective of system testing is to verify that the system will be able to function as a whole with the current design. This is the final level of testing. After this, the customer is going to perform UAT. So, the approach should be more negative testing. Various items can be tested in the system testing is as follows. Database consistency Database design with external users Security Data redundancy check System and its environment Database growth System log Transaction log Concurrency control

Compatibility Response time Throughput rate Challenges involved in database testing Dynamic requirements Testing concurrency Testing database growth in a real time situation Testing deadlocks Testing complex relationships and computations Database Test Summary Results Once all the testing activities are completed, the test summary report should give the clear information on the level of coverage of database testing. Various metrics on database testing is as follows. Test execution summary Defects data summary Deviation analysis Database testing metrics Metrics gives the measurements of the various activities. Generally it involves the following. Effort estimation variance Schedule estimation Defect metrics Defect detection efficiency Defect density Database testing tools Database testing tools are generally used for testing the functionality and performance. I have mentioned here some of the tools which can be used for both. Ndbunit NDbUnit is a .NET library for putting a database into a known state. NDbUnit may be used to increase repeatability in unit tests that interact with a database by ensuring that the database's state is consistent across execution of tests. NDbUnit does this by allowing the unit test to perform an operation on a dataset before or after the execution of a test, thus ensuring a consistent state. NDbUnit: is an open-source LGPL-licensed project is written in C# has been tested with .NET version 1.1 supports SQL Server and OLE database types borrows many ideas from DbUnit, and makes them available for the .NET platform DBFire This is a simple testing tool that runs from the command line and produces the results of the test run in a simple text file. The tool runs pre-determined SQL queries in a prepared-statement like format. You give it the statement configuration in an XML file, and the tool does the rest. SQL DB Validator Tests can compare data content, date content, or row counts. Concurrent test execution ensures tests will run in the shortest possible time. They may also be run sequentially. A command line interface allows for integration of the software testing tool with any current test automation system. A customizable Syntax Highlighting Editor, which aids in query design, is integrated into the tool.

DTM DB Stress DTM DB Stress is a utility for stress testing the server parts of information systems and applications, as well as DBMSs and servers themselves. This tool allows you to create and configure a continuous set of requests to the server of the OLAP (query execution) and OLTP (adding, modifying and deleting data in the database) types. At the same time, the user can flexibly change both the number and the priority of this or that type of requests to a database or an application. The program is useful for any information system developer or any QA department employee who wants to make sure the product under development can work with a large number of simultaneous connections and concurring queries and transactions. Database administrators can use this utility to evaluate the current performance of servers and to make plans about increasing processing power. Conclusion In this paper, I have written about the various phases of database testing and its sequence. Still, there could be many areas which are open for testing. The aim of this paper is to given an insight on various dimensions on database testing to the reader. For any queries and critics, you can reach me thru saivinayk@ymail.com