Database Testing Interview Questions And Answers

Data bas testing basically include the following.
1)Data validity testing.
2)Data Integritity testing
3)Performance related to data base.
4)Testing of Procedure,triggers and functions.
for doing data validity testing you should be good in SQL queries
For data integrity testing you should know about referintial integrity and different constraint.
For performance related things you should have idea about the table structure and design.
for testing Procedure triggers and functions you should be able to understand the same.

In DB testing we need to check for,
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.

Observing that opertaions, which are operated on front-end is effected on back-end or not.
The approach is as follows :
While adding a record thr' front-end check back-end that addition of record is effected or not. So same for delete, update,...... Ex:Enter employee record in database thr' front-end and check if the record is added or not to the back-end(manually).

It can be verified by querying the common audit log where we can able to see the triggers fired.

No. I do not think so. Since the requirement seems to be ambiguous. The SRS should clearly mention the performance or transaction requirements i.e. It should say like 'A DB retrival rate of 5 micro sec'.

By writing scripting procedure in the TCL we can connect to the database and we can test data base and queries.
The exact proccess 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");

It depends on what level of testing you are doing.When you want to save something from front end obviously, it has to store somewhere in the database
You will need to find out the relevant tables involved in saving the records.
Data Mapping from front end to the tables.Then enter the data from front end and save.
Go to database, fire queries to get the same date from the back end.

verify field level data in the database with respect to frontend transactions
verify the constraint (primary key,forien key ....)
verify the performance of the procedures
verify the triggrs (execution of triggers)
verify the transactions (begin,commit,rollback)

An1:
Database testing is all about testing joins, views, inports and exports , testing the procedures, checking locks, indexing etc. Its not about testing the data in the database.
Usually database testing is performed by DBA.

An2:
Database testing involves some in depth knowledge of the given application and requires more defined plan of approach to test the data.
Key issues include:
1) Data Integrity
2) Data Validity
3) Data Manipulation and updates
Tester must be aware of the database design concepts and implementation rules.

An3:
Data bas testing basically include the following.
1)Data validity testing.
2)Data Integritity testing
3)Performance related to data base.
4)Testing of Procedure,triggers and functions.
for doing data validity testing you should be good in SQL queries
For data integrity testing you should know about referintial integrity and different constraint.
For performance related things you should have idea about the table structure and design.
for testing Procedure triggers and functions you should be able to understand the same.

You have to do the following things while you are involving in Data Load testing.
1. You have know about source data (table(s), columns, datatypes and Contraints)
2. You have to know about Target data (table(s), columns, datatypes and Contraints)
3. You have to check the compatibility of Source and Target.
4. You have to Open corresponding DTS package in SQL Enterprise Manager and run the DTS package (If you are using SQL Server).
5. Then you should compare the column's data of Source and Target.
6. You have to check the number to rows of Source and Target.
7. Then you have to update the data in Source and see the change is reflecting in Target or not.
8. You have to check about junk character and NULLs.

An1:
here database testing means test engineer should test the data integrity, data accessing,query retriving,modifications,updation and deletion etc

An2:
Database tests are supported via ODBC using the following functions:
SQLOpen, SQLClose, SQLError, SQLRetrieve, SQLRetrieveToFile, SQLExecQuery, SQLGetSchema and SQLRequest.
You can carry out cursor type operations by incrementing arrays of returned datasets.

All SQL queries are supplied as a string. You can execute stored procedures for instance on SQL Server you could use “Exec MyStoredProcedure” and as long as that stored procedure is registered on the SQL Server database then it should execute however you cannot interact as much as you may like by supplying say in/out variables, etc but for most instances it will cover your database test requirements

An3:
Data bas testing basically include the following.
1)Data validity testing.
2)Data Integritity testing
3)Performance related to data base.
4)Testing of Procedure,triggers and functions.

for doing data validity testing you should be good in SQL queries
For data integrity testing you should know about referintial integrity and different constraint.
For performance related things you should have idea about the table structure and design.
for testing Procedure triggers and functions you should be able to understand the same.


An4:
Data base testing generally deals with the follwoing:
a)Checking the integrity of UI data with Database Data
b)Checking whether any junk data is displaying in UI other than that stored in Database
c)Checking execution of stored procedures with the input values taken from the database tables
d)Checking the Data Migration .
e)Execution of jobs if any

An1:
Data driven test is used to test the multinumbers of data in a data-table, using this we can easy to replace the paramerers in the same time from deferent locations.
e.g: using .xsl sheets.

An2:
Re-execution of our test with different input values is called Re-testing. In validate our Project calculations, test engineer follows retesting manner through automation tool.Re-teting is also called DataDriven Test.There are 4 types of datadriven tests.
1) Dynamic Input submissiion ( key driven test) : Sometines a test engineer conducts retesting with different input values to validate the calculation through dynamic submission.For this input submission, test engineer use this function in TSL scriipt-- create_input_dialog ("label");
2) Data Driven Files Through FLAT FILES ( .txt,.doc) : Sometimes testengineer conducts re-testing depends on flat file contents. He collect these files from Old Version databases or from customer side.
3)Data Driven Tests From FRONTEND GREAVES : Some times a test engineer create automation scripts depends on frontend objects values such as (a) list (b) menu (c) table (d) data window (5) ocx etc.,
4)Data Driven Tests From EXCEL SHEET : sometimes a testengineer follows this type of data driven test to execute their script for multiple inputs. These multiple inputs consists in excel sheet columns. We have to collect this testdata from backend tables .

Before testing Data Base Procedures and Triggers, Tester should know that what is the Input and out put of the procedures/Triggers, Then execute Procedures and Triggers, if you get answer that Test Case will be pass other wise fail.
These requirements should get from DEVELOPER

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.
Most of all, maintain a backup of the previous database.

It depend on your application interface..

1. If your application provides view functionality for the entered data, then you can verify that from front end only. Most of the time Black box test engineers verify the functionality in this way.

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

3. You can also use database checkpoint function in WinRunner.

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 mentions 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 WinRunner.

in QTP
using output databse check point and database check point ,
select SQL manual queries option
and enter the "select" queris to retrive data in the database and compare the expected and actual

The most important statement for database testing is the SELECT statement, which returns data rows from one or multiple tables that satisfies a given set of criteria.
You may need to use other DML (Data Manipulation Language) statements like INSERT, UPDATE and DELTE to manage your test data.
You may also need to use DDL (Data Definition Language) statements like CREATE TABLE, ALTER TABLE, and DROP TABLE to manage your test tables.
You may also need to some other commands to view table structures, column definitions, indexes, constraints and store procedures.

An1:
You have to do the following for writing the database testcases.
1. First of all you have to understand the functional requirement of the application throughly.
2. Then you have to find out the back end tables used, joined used between the tables, cursors used (if any), tiggers used(if any), stored procedures used (if any), input parmeter used and output parameters used for developing that requirement.
3. After knowing all these things you have to write the testcase with different input values for checking all the paths of SP.
One thing writing testcases for backend testing not like functinal testing. You have to use white box testing techniques.

An2:
To write testcase for database its just like functional testing.
1.Objective:Write the objective that you would like to test. eg: To check the shipment that i load thru xml is getting inserted for perticular customer.
2.Write the method of input or action that you do. eg:Load an xml with all data which can be added to a customer.
3.Expected :Input should be viewd in database. eg: The shipment should be loaded sucessfully for that customer,also it should be seen in application.4.You can write ssuch type of testcases for any functionality like update,delete etc.

An3:
At first we need to go through the documents provided.
Need to know what tables, stored procedures are mentioned in the doc.
Then test the functionality of the application.

Simultaneously, start writing the DB testcases.. with the queries you have used at the backend while testing, the tables and stored procedures you have used in order to get the desired results. Trigers that were fired. Based on the stored procedure we can know the functionality for a specific peice of the application. So that we can write queries related to that. From that we make DB testcases also.

An1:
In DB testing we need to check for,
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.

An2:
Database testing involves some indepth knowledge of the given application and requires more defined plan of approach to test the data. Key issues include :
1) data Integrity
2) data validity
3) data manipulation and updates.

Tester must be aware of the database design concepts and implementation rules