Database Testing Gourav Mehta (Associate QA Engineer)

Why Database Testing ? Data is an Important Corporate Asset. Mission-critical business functionality is implemented in RDBMSs. Current Approaches are not sufficient (Visual inspect by developers or formal test at the end of lifecycle) Testing provides the concrete feedback required to identify defects. Support for evolutionary development: How Data Activities Fit In

Database Updates Database Testing mainly includes on following: Data Integrity Test. Stored Procedure Test Type Test Data Size Test Event Driven Item Test Input Item Verification

Data Integrity Test Data integrity means that the data in the database is complete and consistent both at its creation and at all times during use. Once a value undergoes any of the actions(Update,/Delete/Insert) the database should be verified for the changes performed on related entities. Data integrity falls on following categories: Entity integrity Domain integrity

Data Integrity Test Referential Integrity User-Defined Integrity

Store 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 actions Items based on Functions and then Each action 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 (White Box).

Store Procedure Test In the case of stored procedures, to come up with test cases one can consider the following things: The Numbers of arguments being passed. The data type of each of the arguments being passed. The order of arguments being passed. The return type The data type of return type. Based on these, you can write both Positive and Negative test cases.

Type Test This test is performed to verify that the data types used by the DBA are the same as expected by developer. Often the data chosen by developers are not the same as suggested by DBA especially for the fields like: Phone (Number/Text) Description (Large text) This type of mismatch does not effect the functionality and execution of code. But prove to be very COSTLY during the updating or enhancing the functionality.

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

Event Driven Item Test Event Driven Actions (Triggers or Schedules Actions) needs to be tested on two parameters: A) Events that triggers 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 stored procedure are verified for the functionality.

Input Item Verification This is the process of verification of the item items. This has to be performed for database testing of the web based application. Often it is seen that the input items (Textbox/ RTB/ Combination Box/ActiveX 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 don't push in such characters which the databases Often misrepresent or replace with other characters.

Thanks QA… Your Feedback is Always Welcome.