0% found this document useful (0 votes)
25 views12 pages

Database Testing: Gourav Mehta (Associate QA Engineer)

Uploaded by

kriszpm
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
25 views12 pages

Database Testing: Gourav Mehta (Associate QA Engineer)

Uploaded by

kriszpm
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 12

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.

You might also like