The databases and the database processes should be tested as a subsystem within the project. These subsystems should be tested without the target-of-test’ s User Interface as the interface to the data. Additional research into the Database Management System (DBMS) needs to be performed to identify the tools and techniques that may exist to support the testing identified below.

Test Objective: Ensure database access methods and processes function properly and without data corruption.

Technique: Invoke each database access method and process, seeding each with valid and invalid data or requests for data.
Inspect the database to ensure the data has been populated as intended, all database events occurred properly, or review the returned data to ensure that the correct data was retrieved for the correct reasons

Completion Criteria: All database access methods and processes function as designed and without any data corruption.

Special Considerations: Testing may require a DBMS development environment or drivers to enter or modify data directly in the databases.
Processes should be invoked manually.
Small or minimally sized databases (limited number of records) should be used to increase the visibility of any non-acceptable events.

Database Testing mainly concentrates on following:

1. Data Integrity test
2. Stored Procedure test
3. Type test
4. Data Size Test
5. Event Driven Item Test
6. Input Item Verification


1)Data Integrity test

Once a value undergoes any of the above actions (update / Delete / Insert) the database should be verified for the changes performed on related entities i.e., Foreign key / Primary key and all dependent entities

2)Stored Procedure test
Every Stored Procedure is to be tested separately for its functionality (Based on Separate functions it performs) Stored procedures need to be broken up into Action Items based on Functions and then each action item needs to be tested separately as the results of Complete Stored procedure.

Execution may differ from the results obtained by partial execution. This also helps in validating the modularity of Code (White Box).
In the case of stored procedures, to come up with test cases one can consider the following:

1. The no. of arguments being passed
2. The data type of each of the arguments being passed
3. The order of the arguments being passed
4. The return value
5. The data type of the return value

Based on these you can write both positive and negative test cases, consider a simple example of a stored procedure taking 2 numbers as input and returning the sum of the 2 numbers


3) Type test
This test is performed to verify that the data types used by the DBA are same as expected by agreed upon by the developer. Often the data types chosen by developers are not the same as suggested by database administrators, especially for the fields like

A) Phone (Num./Text)
B) Description (Large Text)

These kinds of mismatches often do not effect the functionality and normal execution of code, but prove to be very Costly during Updating of product or during addition of features to the existing modules

4) Data Size Test
Performance of Data size testing is often done only at the front end during the unit testing , but it is essential to perform it at back end separately .
This ensures smooth transition while appending functionality and integrating modules as during these Phases , the data is passed to the system with direct user interaction and bypassing front end validation.

5)Event Driven Item Test

Event Driven Actions (Triggers or Scheduled Actions) needs to be tested on two parameters.
A) Events that trigger these actions: Here QA needs to check the events on which any of the trigger can get fired/executed . This testing can be done with the help of DBA also .
B) Actions performed by the above stated events. Here the contents of such stored procedures or scheduled actions are verified for the functionality .


6)Input Item Verification

This is the process of verification of the input items (Though this is not totally a part of database testing, but this has to be performed essentially during database testing of the Web based applications.

Often it is seen that the input items (Text Box / RTB / Combination Box / Active-X controls) are tested for validation only at front end (Screen testing) but these are again to be tested with junk Character values to confirm that they do not push in such characters which the databases Often misrepresent or Replace with other characters (this testing can partially be performed during Unit testing also by the developer

__________________

Have a Nice Day
Sudhir S M
India

Ok, well, this is very informative. I did read in another thread the question about the testing and I had never even heard of it before.