Introduction
Databases are integral part of any application. There are applications which directly operate on databases. There are other applications that send requests to the aforementioned applications. The document provides the guidelines on how to go on with the testing of applications that directly operate on Databases.
The system test of these applications mainly concentrates on testing the changes or amendment incorporated in the application. The amendments in the application can be broadly classified as
- Amendments in processing logic
- Amendments in database structure
Testing for Amendments in processing logic:
The amendment in processing logic includes the following;
- Logic to persist data onto the tables
- Logic to retrieve data from tables
- Logic to automatically update fields in tables
- Logic to run appropriate procedures, etc.
The following are the guidelines that are prescribed for such scenarios
Before Testing:
- Identify tables that would get affected.
- Identify fields that are affected.
- Map the input data onto the field in each table.
- An input data may be mapped onto multiple tables, care should be taken to map such data to all the fields.
- Test Cases should check for,
- Primary key violation
- Foreign key violation
- Missing Timestamps
- Missing default values
- Inappropriate mapping of data onto tables
- Flow diagrams provide very useful information on the application’s nature, but test cases should cover possible scenarios beyond that depicted in flow diagrams.
- Test cases should cover all possible error scenarios that may occur.
- Snapshots of relevant records in all tables are to be taken
While Testing:
- Validation checks of the input data are to done.
- The input data provided for each case and the output received are to be stored.
- Proper match of the error scenarios and error codes are to be verified.
- The data should be persisted onto the database in the proper format.
- Certain fields in tables would have default values. The occurrence of the default values if no input is provided for the field is to be checked.
- Fields that store timestamps automatically on execution of the records are to be verified.
After Testing:
- Snapshots of relevant records in all affected tables are to be taken.
- Document the SQL queries that are used to simulate scenarios as SQL files or scripts.
- Input to the applications may be in the form of XML. In such cases, the input XML and the corresponding output XML are to be documented.
Testing for Amendments in database structure:
The amendment in database structure includes the following;
- Creation of new database objects (Tables, Views, Sequences, etc.)
- Creation of new triggers, procedures, etc.
- Modification of existing tables with the addition or deletion of columns.
- Dropping of existing database objects
- Change of datatype or size of the fields.
- Change of the constraints or default values on database objects.
The following guidelines help in testing changes in database structure.
Before Testing:
- · Test Cases should cover verification of datatype and size of the new fields added and new tables.
- Test Cases should be included for existence of Triggers and Procedures.
- The new field in a table might necessitate the inclusion of new fields in the history / backup tables if any. Cases should cover them as well.
- Process flows that lead to the modification or updation of the new field are to be covered in the test cases.
- Procedures on the table are to be tested.
- Constraints on the new tables are to be tested.
While Testing:
- Default values for fields on the table should be tested.
- History entries, if any, should be maintained.
- Check the time-zones if any are updated appropriately.
- Mapping of data onto the new fields is to be verified.
- If modification of database structure involves the deletion of a field in a table or a table, it should be verified that no reference is made to it by other tables.
After Testing:
- Perform a check that Negative scenarios where the trigger is not to be invoked are tested.
- If database objects are dropped, then check that there are no further references made to it.
Pit fall:
- Certain fields will require Timestamp to be populated while others would require Date to be populated.
Related Posts
- Software Testing Best Practices
- Checklist/Guidelines for ASP.Net Developers
- Ad hoc Reporting using SQL Server Reporting Services 2005
- Sybase with DotNet Application and SQL Server Reporting Services
- ORALOAD Oracle Utility for Bulk Data Load
Tags: Database Application, Testing Database Application, Testing Guidelines
