Explore topic-wise InterviewSolutions in .

• Check in the COLUMN of the database if there is any invalid data.
• Try to enter the wrong data into the table, and notice how the insertion behaves.
• Check if, in the reference tables, triggers are working fine.
• Check the actual result in the main table, when you insert the child record before inserting the parent record.
• What would HAPPEN if a user delete records derived from another table?
• Check if the data in two or more REPLICATED SERVERS are in SYNC.

This requires the ACID properties, and to achieve that we use the following statements-

Using the ROLLBACK command CHANGES are rolled back to the previous commit. Once transactions are EXECUTED, the user can use SELECT queries to VALIDATE the data.

BEGIN TRANSACTION TRANSACTION#

END TRANSACTION TRANSACTION#

ROLLBACK TRANSACTION# 

• Are the naming conventions of fields are as per requirement?
• Are the lengths and sizes of fields are matching the requirement?
• CREATE a test case that will check if there is any unmapped or unused table and column.
• Is the MAPPING of database fields is correct and COMPATIBLE with the REQUIRED mappings?
• Check if table DESIGNS are applied correctly and are scalable.

The first THING tester should do when migration happens is, to be aware of all the changes done in the new SQL server followed by creating a test case suite by CONSIDERING the below points-

• Which DATA type is used?
• What is the LENGTH of the fields?
• If in the new SQL server, database objects created are as expected.
• On the new SQL server, stress testing should be performed to identify the risks related to the MIGRATED environment.

• A GOOD understanding of SQL is required.
• Sometimes test plans are too complex.
• The database structure has been changed at the time of designing or executing a test.
• Testers have to test the development, staging, and production of database systems because of the little data PROVIDED to them.
• If the database size is too large it becomes a HUGE challenge to test it.

• Check if any compile-time errors are COMING during compilation.
• Users can insert PROPER comments or loggers after or before each EXECUTION so that a proper hint is given about the ONGOING process and narrow down the error point.

The answer is No, as the above requirement is not CLEAR. To test any requirement, SRS or PRS should clearly TELL it, i.e. above requirement should be MENTIONED like “Database RETRIEVAL rate should be of 10 MICROSECONDS”.

QTP doesn’t have built-in or default functions for database connectivity, to interact with a database, testers use ADODB objects and use VBScript LANGUAGE to CONNECT to them.

DDL- Data Definition Language:

• DROP: Used for dropping the OBJECTS of database or database itself.
• ALTER: Properties of database objects can be altered.
• CREATE: Used in the creation of databases and their objects like tables, views, etc.
• TRUNCATE: Using this all RECORDS from the table can be removed.
• RENAME: Used to rename the database objects.

DML- Data Manipulation Language:

• SELECT: From the database, specific records or data can be selected.
• INSERT: Used to insert new data or records.
• UPDATE: Existing records can be updated using UPDATE.
• DELETE: Existing records can be deleted.

DQL- Data Query Language:

• SELECT: queries fall under this CATEGORY.

 DCL- Data Control Language:

• GRANT: Used in granting the user access permissions.
• DENY: User permissions can be denied using it.
• REVOKE: User access can be removed using it.

TCL-Transaction Control Language:    

• COMMIT: Used for writing and storing the changes in the database.
• ROLLBACK: Used to restore the changes to the LAST commit.

This DEPENDS on the INTERFACE which is being USED in that front-end application. Ways to validate it-

• The front-end application’s interface allows view functionality to users to verify updated data.
• If you can’t view the functionality of data that is entered, then database UPDATES can be checked by using RELEVANT SQL/Oracle queries.
• The checkpoint function of WinRunner or QTP can also be used to check if a database has been updated.

Manual testing of databases requires HUMAN effort in observing the operational BEHAVIOR of the application. TESTERS have to manually check if adding a record from the front END also affected the backend database or not. Similarly, it should work for delete, update, edit, etc.

Example- To maintain the record of students who are going for a trip, enter the STUDENT’s information from the front-end system and manually check the effect of entered information on the backend database too.