Database Testing

Q. 1: What we normally check for in the Database Testing?

In Database Testing we need to check,

1) The field size validation

2) Check constraints.

3) Indexes are done or not (for performance related issues)

4) Stored procedures

5) The field size defined in the application is matching with that in the db.

Q. 2: What is Database testing?

Database testing include the following.

1) Data validity testing: For doing data validity testing you should be good in SQL queries.

2) Data Integrity testing: For data integrity testing you should know referential integrity and different constraints.

3) Performance related to database: For performance related things you should have idea about the table structure and design.

4) Testing of Procedure triggers and functions: For this a clear understanding of testing procedure triggers and functions is required.

Database testing is all about testing joins, views, imports and exports, testing the procedures, checking locks, indexing etc.

Database testing does not refer to testing of the data in the database.

Usually Database administrators perform database testing.

Q. 3: How can we do manual testing of database? Explain with an example

It involves observing operations that are operated on front-end are effected on the back-end or not. The approach can be explained like:

While adding a record through the front-end, check back-end that addition of record is effected or not. It applies to delete, update,......etc.

For Example: Enter the employee record in database through the front-end and check manually if the record is added or not to the back-end.

Q. 4: What is data-driven test?

Data driven test is used to test the multi-numbers of data in a data-table. With help of this we can easily replace the parameters at the same time from different locations e.g.: using .xls sheets.

Q. 5: While doing database testing, how do we know that a trigger is fired or not?

It can be verified by querying the common audit log where we are able to see if the triggers is fired or not.

Q. 6: Is a "A fast database retrieval rate" a testable requirement?

No. Since the requirement seems to be ambiguous. The SRS should clearly mention the performance or transaction requirements i.e. It should specify clearly like - Database retrieval rate of 5 microseconds.

Q. 7: How to test a DTS package created for data insert update and delete? What should be considered in the above case while testing it? What conditions are to be checked if the data is inserted, updated or deleted using a text files?

Data Integrity checks should be performed. IF the database schema is 3rd normal form, then that should be maintained. Check to see if any of the constraints have thrown an error.

The most important command will have to be the DELETE command. That is where things can go really wrong.

It is important to maintain a backup of the previous database.

Q. 8: How to test a SQL Query in QTP or winRunner? Without using database checkpoints?

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

The exact process should be:

1) Connect to the database:

db_connect("query1",DRIVER={drivername};SERVER=server_name;

UID=uidname;PWD=password;DBQ=database_name ");

2) Execute the query:

db_excecute_query("query1","write query u want to execute");

-Condition to be mentioned-

3) Disconnect the connection:

db_disconnect("query");

Q. 9: How do you test whether a database in updated when information is entered in the front end?

It depends upon the application interface.

1) If your application provides view functionality for the entered data, then you can verify that from front end only. This way Black- box test engineers verify the functionality most of the times.

2) If your application has only data entry from front end and there is no view from the front end, then you have to go to Database and run relevant SQL query.

3) You can also use database checkpoint function in QTP.

Q. 10: What steps does a tester take in testing Stored Procedures?

First the tester should to go through the requirement, as to why the particular stored procedure is written for.

Then check whether all the required indexes, joins, updates, deletions are correct comparing with the tables mentioned in the Stored Procedure. And also he has to ensure whether the Stored Procedure follows the standard format like comments, updated by, etc.

Then check the procedure calling name, calling parameters, and expected Reponses for different sets of input parameters.

Then run the procedure yourself with database client programs like TOAD, or mysql, or Query Analyzer

Rerun the procedure with different parameters, and check results against expected values.

Finally, automate the tests with QTP.