Database Testing

   Database testing nothing but testing the database .it can be tested manually or           
automatically using tools.

2).What are the testing criteria in database testing?

In database testing we have to test following criteria like

a)     Data validity testing: in validity testing we should known about SQL quires and how
to use it.

b)    Data integrity testing: in integrity testing we should known about integrity
performance of database.

c)     Data manipulation and performance testing: in that testing we have to know about
data design table and data implementation.

d)    Data triggering and functionality testing: in that testing we have to known about
data triggering concepts and functionality of add, delete, update and modify concepts in
database.

3).what are the SQL statement have you used in database testing?

In database testing we have to test two type of SQL statement such as

a) DDL (data definition language): 

    DDL is nothing but create database and create table.

   Ex.1. Create database (database name) vel

        2. Create table (table name) murugan (id int, name varchar (10), address varchar

    b) DML (Data manipulations language):

    DML is nothing but delete, insert, update etc...

Ex.1.insert table values (1,’murugan’,’chennai’) ;

      2. delete * from table name =’murugan’;

      3. update table set name=’balaji’ from id=1;

4).what are the different stage involved in database testing?

  Verify the data in database with respect to front end transactions.

  Verify the constraint (primarykey, forignkey …)

  Verify the performance of procedure

  Verify the triggers (execution of triggers)

  Verify the transactions (begin, commit, rollback)

  Verify the table relationship (1-1, 1-meny, meny-meny)

5).what is a fast database retrieval rate in database?

A database retrieval rate is 5 micro sec.

6).why we go to database testing?

     a) Database testing is primer.

     b) It is back-end and front-end applications.

     c) Testing the applications vs. testing the DBMS (Database Management System)

     d) Knowledge requirements for database testing.

     e) Data must pass quality assurance too.

7) What are the common problem arising in database?

     a). Relational database that affect the database applications.

     b). improperly normalized database (first, 2nd, 3rdnarmalizations).

Common for database:

·        Database size ~15 terabytes (this is total for all database)

1. What is normalization? - Well a relational database is basically composed of tables

that contain related data. So the Process of organizing this data into tables is actually
referred to as normalization.
2. What is a Stored Procedure? - Its nothing but a set of T-SQL statements combined to
perform a single task of several tasks. It’s basically like a Macro so when you invoke the
Stored procedure, you actually run a set of statements.
3. Can you give an example of Stored Procedure? - sp_helpdb, sp_who2, sp_renamedb
are a set of system defined stored procedures. We can also have user defined stored
procedures which can be called in similar way.
4. What is a trigger? - Triggers are basically used to implement business rules. Triggers
is also similar to stored procedures. The difference is that it can be activated when data
is added or edited or deleted from a table in a database.
5. What is a view? - If we have several tables in a db and we want to view only specific
columns from specific tables we can go for views. It would also suffice the needs of
security some times allowing specific users to see only specific columns based on the
permission that we can configure on the view. Views also reduce the effort that is
required for writing queries to access specific columns every time.
6. What is an Index? - When queries are run against a db, an index on that db basically
helps in the way the data is sorted to process the query for faster and data retrievals are
much faster when we have an index.
7. What are the types of indexes available with SQL Server? - There are basically two
types of indexes that we use with the SQL Server. Clustered and the Non-Clustered.
8. What is the basic difference between clustered and a non-clustered index? - The
difference is that, Clustered index is unique for any given table and we can have only
one clustered index on a table. The leaf level of a clustered index is the actual data and
the data is resorted in case of clustered index. Whereas in case of non-clustered index
the leaf level is actually a pointer to the data in rows so we can have as many non-
clustered indexes as we can on the db.
9. What are cursors? - Well cursors help us to do an operation on a set of data that we
retrieve by commands such as Select columns from table. For example : If we have
duplicate records in a table we can remove it by declaring a cursor which would check
the records during retrieval one by one and remove rows which have duplicate values.
10. When do we use the UPDATE_STATISTICS command? - This command is basically
used when we do a large processing of data. If we do a large amount of deletions any
modification or Bulk Copy into the tables, we need to basically update the indexes to
take these changes into account. UPDATE_STATISTICS updates the indexes on these
tables accordingly.
11. Which TCP/IP port does SQL Server run on? - SQL Server runs on port 1433 but we
can also change it for better security.
12. From where can you change the default port? - From the Network Utility TCP/IP
properties –> Port number. Both on client and the server.
13. Can you tell me the difference between DELETE & TRUNCATE commands? - Delete
command removes the rows from a table based on the condition that we provide with a
WHERE clause. Truncate will actually remove all the rows from a table and there will be
no data in the table after we run the truncate command.
14. Can we use truncate command on a table which is referenced by FOREIGN KEY? -
No. We cannot use truncate command on a table with Foreign Key because of referential
integrity.
15. What is the use of DBCC commands? - DBCC stands for database consistency
checker. We use these commands to check the consistency of the databases, i.e.,
maintenance, validation task and status checks.
16. Can you give me some DBCC command options? (Database consistency check) -
DBCC CHECKDB - Ensures that tables in the db and the indexes are correctly linked. and
DBCC CHECKALLOC - To check that all pages in a db are correctly allocated. DBCC
SQLPERF - It gives report on current usage of transaction log in percentage. DBCC
CHECKFILEGROUP - Checks all tables file group for any damage.
17. What command do we use to rename a db? - sp_renamedb ‘old name’, ‘new name’
18. Well sometimes sp_reanmedb may not work you know because if some one is using
the db it will not accept this command so what do you think you can do in such cases? -
In such cases we can first bring to db to single user using sp_dboptions and then we can
rename that db and then we can rerun the sp_dboptions command to remove the single
user mode.
19. What is the difference between a HAVING CLAUSE and a WHERE CLAUSE? - Having
Clause is basically used only with the GROUP BY function in a query. WHERE Clause is
applied to each row before they are part of the GROUP BY function in a query.
20. What do you mean by COLLATION? - Collation is basically the sort order. There are
three types of sort order Dictionary case sensitive, Dictionary - case insensitive and
binary.
21. What is a Join in SQL Server? - Join actually puts data from two or more tables into a
single result set.
22. Can you explain the types of Joins that we can have with Sql Server? - There are
three types of joins: Inner Join, Outer Join, Cross Join
23. When do you use SQL Profiler? - SQL Profiler utility allows us to basically track
connections to the SQL Server and also determine activities such as which SQL Scripts
are running, failed jobs etc..
24. What is a Linked Server? - Linked Servers is a concept in SQL Server by which we
can add other SQL Server to a Group and query both the SQL Server dbs using T-SQL
Statements.
25. Can you link only other SQL Servers or any database servers such as Oracle? - We
can link any server provided we have the OLE-DB provider from Microsoft to allow a link.
For Oracle we have an OLE-DB provider for oracle that Microsoft provides to add it as a
linked server to the sql server group.
26. Which stored procedure will you be running to add a linked server? -
sp_addlinkedserver, sp_addlinkedsrvlogin
27. What are the OS services that the SQL Server installation adds? - MS SQL SERVER
SERVICE, SQL AGENT SERVICE, DTC (Distribution transact co-ordinate)
28. Can you explain the role of each service? - SQL SERVER - is for running the
databases SQL AGENT - is for automation such as Jobs, DB Maintenance, and Backups
DTC - Is for linking and connecting to other SQL Servers
29. How do you troubleshoot SQL Server if it’s running very slow? - First check the
processor and memory usage to see that processor is not above 80% utilization and
memory not above 40-45% utilization then check the disk utilization using Performance
Monitor, Secondly, use SQL Profiler to check for the users and current SQL activities and
jobs running which might be a problem. Third would be to run UPDATE_STATISTICS
command to update the indexes
30. Let’s say due to N/W or Security issues client is not able to connect to server or vice
versa. How do you troubleshoot? - First I will look to ensure that port settings are proper
on server and client Network utility for connections. ODBC is properly configured at client
end for connection ——Make pipe & read pipe are utilities to check for connection. Make
pipe is run on Server and read pipe on client to check for any connection issues.
31. What are the authentication modes in SQL Server? - Windows mode and mixed
mode (SQL & Windows).
32. Where do you think the user’s names and passwords will be stored in sql server? -
They get stored in master db in the sysxlogins table.
33. What is log shipping? Can we do log shipping with SQL Server 7.0 - Log shipping is a
new feature of SQL Server 2000. We should have two SQL Server - Enterprise Editions.
From Enterprise Manager we can configure the log shipping. In log shipping the
transactional log file from one server is automatically updated into the backup database
on the other server. If one server fails, the other server will have the same db and we
can use this as the DR (disaster recovery) plan.
34. Let us say the SQL Server crashed and you are rebuilding the databases including
the master database what procedure to you follow? - For restoring the master db we
have to stop the SQL Server first and then from command line we can type
SQLSERVER .m which will basically bring it into the maintenance mode after which we
can restore the master db.
35. Let us say master db itself has no backup. Now you have to rebuild the db so what
kind of action do you take? - (I am not sure- but I think we have a command to do it).
36. What is BCP? When do we use it? - Bulk Copy is a tool used to copy huge amount of
data from tables and views. But it won’t copy the structures of the same.
37. What should we do to copy the tables, schema and views from one SQL Server to
another? - We have to write some DTS packages for it.

38.What is difference between inner and outer join?

Inner join: displays only matching record from 2 tables

Outer join:

Left outer join display all the records from 1st table even

if dont have matching record in 2nd table

rignt outer join display all the record from the 2nd table

even if there is not matching record in 1st table

39.Difference between delete and truncate?

TRUNCATE

1. It is DDL.

2. Speed is faster

3. Do not Check Constraints.

4. Roll back is not possible.it will delete the structure of the table.

5. Cannot use where clause

DELETE
1. It is not a DDL

2. Speed is slow

3. Check constraints, If Exists then shoe error.

4. We can rollback.

5. User Where Clause

Database Testing
Why test the database?

The database persists data that your application (and organization) depends on. The
data thus persisted is most often of mission-critical nature and a key asset for the
organization. Also, many of today's data-enabled applications implement a fair amount
of their functionality and business logic in the database itself. For an enterprise class
application, the data in the database would be accessed and updated
(insert/modify/delete) simultaneously by a large number of users (think thousands to
millions depending on the scale of your application's usage). 

The above statements highlight a few areas where database testing is needed. One, to
validate the quality of data being persisted. Two, if we plan to test the application code,
it is imperative that we also test the code in the database which implements the
business functionality and three, we should plan for non-functional database testing to
support the usage of the database in a real-world deployment scenario.

Let us briefly look at the above mentioned database test areas.

1. Data quality testing

Testing the quality of the data may be approached in three ways - data validity testing,
data integrity testing and data format testing.

a) Data validity testing - is done to verify the validity of the data that is stored in the
database. When data is entered via the front end application, check if the data is
correctly updated in the back-end database. Apart from the positive checks, look for
other behavior such as data truncation, verify how null/empty field values are handled,
verify how special characters or code snippets are handled in the database. Check that
the right columns in the right tables are being updated. Data validity testing normally
involves use of SQL queries to validate the data.

b) Data integrity testing - involves testing referential integrity and application of

constraints (foreign/primary key). When a data field is subject to modification (insert,
update or delete), the database should be verified for appropriate changes to related
entities such as primary key/foreign key relationships and that referential integrity of the
data is maintained

c) Data format testing - involves verifying the size and type of fields that store data in
the database with those that accept data in the application. This can help identify
mismatches between the type or size of data that is accepted by the front-end vs what
the database can store. Example: the application may accept text data but try to store in
a numeric or date field in the database or else the application may accept data of greater
length than the max length for the corresponding field in the database. This may not
throw errors during routine application usage but may store incorrect or erroneous data
in the database which could have repercussions elsewhere or at a later stage
    
2. Database code testing - involves testing the code in the database which implements
business logic and functionality. Examples of such code include, stored procedures,
views (read-only/updateable) and event driven items such as triggers. Each stored
procedure is tested distinctly for its functionality. When a stored procedure implements
multiple functions, each function is tested separately. Stored procedure testing would
look at testing the arguments that are passed to the stored procedure in terms of the
number, type and order of arguments plus the return value. Both positive and negative
tests can be devised to test stored procedures. Views both read only and updateable are
tested either as stored queries that dynamically retrieve values from the database
and/or allow updates to the database. In case where updates are allowed, data validity
and integrity testing is done. Event driven items are tested by verifying the events that
could trigger actions and the actions themselves for functional correctness

3. Non-functional database testing

In most real-world mission critical deployments, to ensure database scalability, security,

availability and recover-ability with minimal/no-loss of data, it is important to test the
following non-functional areas

a) Database performance testing (load/stress/longevity/scalability)

b) Database security testing
c) Database replication testing
d) Database fail-over testing
e) Database recovery testing

Database Testing Test Scenarios

1. Check if correct data is getting saved in database upon successful page submit
2. Check values for columns which are not accepting null values
3. Check for data integrity. Data should be stored in single or multiple tables based on
design
4. Index names should be given as per the standards e.g. IND__ 
5. Tables should have primary key column
6. Table columns should have description information available (except for audit
columns like created date, created by etc.)
7. For every database add/update operation log should be added
8. Required table indexes should be created
9. Check if data is committed to database only when the operation is successfully
completed
10. Data should be rolled back in case of failed transactions
11. Database name should be given as per the application type i.e. test, UAT, sandbox,
live (though this is not a standard it is helpful for database maintenance)
12. Database logical names should be given according to database name (again this is
not standard but helpful for DB maintenance)
13. Stored procedures should not be named with prefix “sp_”
14. Check is values for table audit columns (like createddate, createdby, updatedate,
updatedby, isdeleted, deleteddate, deletedby etc.) are populated properly
15. Check if input data is not truncated while saving. Field length shown to user on page
and in database schema should be same
 16. Check numeric fields with minimum, maximum, and float values
17. Check numeric fields with negative values (for both acceptance and non-
acceptance)
18. Check if radio button and dropdown list options are saved correctly in database
19. Check if database fields are designed with correct data type and data length
20. Check if all table constraints like Primary key, Foreign key etc. are implemented
correctly
21. Test stored procedures and triggers with sample input data
22. Input field leading and trailing spaces should be truncated before committing data
to database
23. Null values should not be allowed for Primary key column

Database Testing Checklist

Keep following points in mind when doing database testing. hope this will helpfull.
Field size validation
Check constraints
Indexes are done or not (for performance related issues)
Store procedure
Field size defined in the application is matching with that in database
Events like insert, update, delete
Data integrity, data validity and data manipulation and update

Please check below for DB testing

Field Validations
1. Is ‘Allow Null’ condition removed at database level for mandatory fields on UI
2. Is ‘Null’ as value not allowed in database
3. Is Field not mandatory while allowing NULL values on that field 
4. Is the Field length specified on UI same as field length specified in table to store same
element from UI into database.
5. Is the length of each field of sufficient size
6. Is the Data type of each field is as per specifications
7. Does all similar fields have same names across tables
8. Is there any computed field in the Database
Check Constraints
1. Is required Primary key constraints are created on the Tables
2. Is required Foreign key constraints are created on the Tables
3. Are valid references are done for foreign key
4. Is Data type of Primary key and the corresponding foreign key same in two tables
5. Does Primary key’s ‘Allow Null’ condition not allowed
6. Does Foreign key contains only not NULL values
Indexes
1. Are required Clustered indexes created on the tables
2. Are required Non Clustered indexes created on the tables
Stored Procedures/ Functions
1. Is proper coding conventions followed
2. Is proper handling done for exceptions
3. Are all conditions/loops covered by input data
4. Does TRIM is applied when data is fetched from Database
5. Does executing the Stored Procedure manually gives the correct result
6. Does executing the Stored Procedure manually updates the table fields as expected
7. Does execution of the Stored Procedure fires the required triggers
8. Are all the Stored Procedures/Functions used by the application (i.e. no unused stored
procedures present)
9. Does Stored procedures have ‘Allow Null’ condition checked at data base level
10. Are all the Stored Procedures and Functions successfully executed when Database is
blank
Data Integrity
1. Is the complete data in the database is stored in tables
2. Is the data well logically organized
3. Is the data stored in tables is correct
4. Is there any unnecessary data present
5. Is the data present in the correct table 
6. Is the data present in correct field within the table
7. Is the data stored correct with respect to Front End updated data
8. Is LTRIM and RTRIM performed on data before inserting data into database

Data Migration Testing concept and checklist for testing

Data Migration Testing
Data migration is a process which involves the migration of data from an existing
database to a new database. Whenever an organization decides to upgrade or change its
database, it will need to transport the existing data to the new database.
The scope of data migration is much more than what the term suggests. Data migration
activity typically will include everything that is required with respect to data to ensure
that the new database is up and running without any defects and it also contains all the
legacy data ( data that is present in the existing database) , and the data has been
migrated to correct table(s) and column(s).
Consequently it involves more activities than only migration of existing data as the name
suggests.
In a typical scenario it can include following activities:-
A. Migration of existing data to the new database.
B. The new database can have some 'Master Tables'. And Master tables need to be
populated with data first to account for various referential constraints. In such cases
data migration includes the activity of setting up (master) data in master tables.
C. The new database can have some tables or attributes which are not present in the
existing database. Thus a completely new set of data will be setup in these tables.
While data migration is different, first understand the data migration process. Data
migration is the process of shifting the whole production data from one database to
other new database. This process might be done by using data migration tool which is
developed as per the data migration requirements.
During this data migration process there may be possibility of data missing or data
corruption. So after the data migration process one has to test whether the whole data is
migrated successfully or not, whether something is missing or gets currepted during
migration.
So data migration testing is to compare migrated data with original data to find out any
discrepancies.
When we are speaking database migration testing. We can say ETL testing. Database
migration is extracting the database from source and loads the data to target database.
Two types of Loading:
1. Direct Loading.
2. Incremental Loading.
Direct Loading:
The direct loading is nothing copy the data from source to target. The number of rows
should be equal source and target.
Incremental Loading:
The Incremental loading, when loading the data from source to target, applying some
transformations. Cleaning the data or load the data with specific conditions.
Challenge is two different databases have their own structures so just simple
table/record import export function will not work. We need a tool (say ETL) in between
source database and destination database where we will write the transformation logic,
done by the Dev team. Testing team will validate that all those business rules in ETL are
actually working in migration testing
Types of Migration
Migration of data from one database to another can be further classified into various
subsets.
a. Direct Migration from the source database to the target:
In this type of migration the data elements that are present in the source database is
directly transferred into the target database
b. Migration after performing certain transformations on the source data:
This migration requires some transformation of the source data before it is migrated to
the new database.
For e.g., a field ‘Priority’ in the source database may allow only one out of the three
values High, Medium and Low. But in the target database the same field allows one out
of the three values 1, 2 and 3. Thus the a High value in the source database will be
transformed to a value 1 and will then be migrated to the target database.
Different types of migrations are listed below. These are the migrations which were
encountered during testing of data migration project(s). There could be some more
types of migration and presently are not part of the below list.
1. Change in datatype.
a. Data in the source table may be present as a character, but in the target table the
mapped column is an integer.
2. Concatenation of two or more columns.
3. Mathematical transformations (e.g. summing up of fields etc)
4. Migration of values depending on other fields/tables present in the source database.
c. Target Generated Data:
This is the data that is generated at the target database. These values will not be
present the source database but will be generated each time an insertion or an update
takes place on a table. These columns generally are the primary key of a table.
d. Reference at target system generated.
This type of migration deals with data that has to comply with referential integrity
constraints. This data is generated at the new database but the data comes from the
parent attribute. A reference key in the target database is usually encountered when a
table in the source database is split up into two or more tables in the target.
e. Manual setup data in the target database.
Certain tables have to be populated before the migration takes place. These tables can
be termed as ‘Master Tables’. These tables are the parent tables to the various
referential constraints that are to be implemented in the child tables. The data for these
tables may not come from the source database but will be setup manually in the target
database.
Checklist for test Data Migration Testing
1. We can check for the table row count.
2. We have to check database integrity.
3. We have to check the referential integrity.
4. Whether the data are loaded in the target database correctly.
5. Check the constraints.
6. All the entities are transformed or not like tables, SPs, Views, functions etc
7. Check the functionality of your application with target database, it should work as it is
supposed to work
Data Migration Testing Life Cycle
The following are the steps to be followed in the process of Data Migration Testing:-
1. Data Migration Requirement Analysis
2. Test Strategizing
3. Creation of POC
4. Test Planning
5. Design of Automated Test Scripts
6. Test Environment Setup
7. Test Execution
8. Result and Defect Analysis

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

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.

3. How to Test database in Manually? Explain with an example

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).

4. What is data driven test?

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-
testing 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 .

5. How to check a trigger is fired or not, while doing database testing?

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

6. How to Test Database Procedures and Triggers?

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

7. Is a “A fast database retrieval rate” a testable requirement?

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’.

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

9.How to test a SQL Query in Winrunner? without using DataBase CheckPoints?

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”);

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

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.

11. How do you test whether the database is updated as and when an information are
added in the front end?Give me an example?

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.

12. 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 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.

13. What are the different stages involved in Database Testing

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)

14. How to use SQL queries in WinRunner/QTP

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

15. What is database testing and what we test in database testing?

An1:
Database testing is all about testing joins, views, imports 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.

16. What SQL statements have you used in Database Testing?

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. 

17. How to test data loading in Data base testing?

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.

18. What is way of writing testcases for database testing?

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.

Check list for database testing :

1. Data integrity

The complete data belonging to each entity should be stored in the database. Depending
on the database design, the data may be present in a single table or multiple related
tables. Parent-child relationships should exist in the data. There should not be any
missing data.

2. Correctness of the data stored in the database

The data should be present in the correct table and correct field within the table.

3. Correctness and completeness of data migration (in case some or all the original data
has come from another source)

4. Functionality and performance of user objects e.g. functions, procedures, triggers.

5. Database performance (query execution times, throughput etc.) and locking problems

You may identify the main queries (or procedures) that are used in the application and
time them with sample data. Locking problems may become apparent when multiple
inserts/ updates are being made 
to the same entity simultaneously.

6. Data security

You may check if any data that should be encrypted e.g. passwords, credit card numbers
is in plain text or not. The database should not have the default passwords. Even
application accounts should have passwords that are complex and not easily guessed.

Additionally, you might need to review the following items:

1. Database fields (if they meet the specifications e.g. width, data type etc. as given in
the design documentation/ data dictionary etc.)

2. Normalization level

3. Compliance of user objects code to coding guidelines