Ans: It is not easier to understand and verify a back end than a front end because a front end usually has friendly and intuitive user interfaces.
A back end has its own objects, such as, tables, stored procedures and triggers. Data integrity and protection is critical. Performance and multi-user support are big issues. Slowness in operation can be vital to the project’s future.
There are no sufficient tools for back end testing. SQL language is mainly a testing tool. MS Access and MS Excel can be used to verify data but they are not perfect for testing. However, there are a large number of test tools available for front end testing.
To be able to do back end testing, a tester must have strong background in SQL server and SQL language. It is relatively difficult to find testers who understand both SQL server and SQL testing. This causes a shortage of back end testers.

Ans: The back end is no longer a "black box" to testers. We have full control of test coverage and depth. Many bugs can be effectively found and fixed in the early development stage. Take Forecast LRS as an example; the number of bugs in a back end was more than 30% of total number of bugs in the project. When back end bugs are fixed, the system quality is dramatically increased.

Ans: A back end is the engine of any client/server system. If the back end malfunctions, it may cause system deadlock, data corruption, data loss and bad performance. Many front ends log on to a single SQL server. A bug in a back end may put serious impact on the whole system. Too many bugs in a back end will cost tremendous resources to find and fix bugs and delay the system developments.
It is very likely that many tests in a front end only hit a small portion of a back end. Many bugs in a back end cannot be easily discovered without direct testing.

Ans: Database testing basically include the following. 1)Data validity testing. 2)Data Integrity testing 3)Performance related to data base. 4)Testing of Procedure, triggers and functions. Data validity testing: Data validity tes...  

Ans: Testing an application’s interface with a relational database.
Interface: SQL is nothing but Interface Between RDBMS and application so it lets us to extract, combine, manipulate, and organize data and many more..

Ans: The Collection of Interrelated Data is called Data Base.
Relational Database Concepts
RDBMS= DBMS +Referential Integrity (It is achieved through Foreign Key).
Referential Integrity: The existence of a value in one dataset is dependent on the existence of the same value in another linked dataset
Ex: Oracle, Sqlserver, Mysql follow RDBMS model.

Ans: A collection of facts, Pieces of information from which conclusions may be drawn.
Ex: Resumes for managing the human Resources..!

Ans: By writing scripting procedure in the TCL we can connect to the database and we can test data base and queries.
The exact process should be:
1)connect to the database
db_connect(“query1″,DRIVER={driver name};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”);

Ans: in QTP
using output database check point and database check point ,
select SQL manual queries option
and enter the “select” queries to retrieve data in the database and compare the expected and actual

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