Checklist for ETL testing In Data Integration Testing Project 1.

Check for the Connection & Availability of the Testing Schema & all the target tables that will be involved in testing. Check for the Naming Conventions (e.g.) Check whether the names specified in the mapping document matches with that of the Target Tables created in the Testing Schema. Check for the Data Types/Size of the Columns that are available in the Target table to avoid unnecessary rejections due to size constraints Check whether all the Lookup tables are loaded with appropriate data. (e.g.) If there is a mapping logic which would be performed based on the look-up table values. Then, if there are no values available in the lookup table then there is all the possibility that the transformation won't be done as per our expectations Try to gain insight of the real-time scenario's that the project deals with (e.g.) There can be occasions when data in the columns are swapped between Job Title & Name prefix code, which can be pointed out by applying common sense Check for the record counts (e.g.) Source File contains - > 100 records, Out of which 80 was moved to Staging table using Business filters. Once the development team loads the data in the target table. Tester has to consider 3 scenarios: If the target tables have 80 records, it means no records are rejected If the target table have say 60 records, then 20 records should have been rejected and should be available in reject file/Error Table If the target tables have say 85 records, which is fundamentally incorrect. Validate each & every mapping rule specified in the mapping document, by writing an SQL query in the form (Staging table + Mapping Rule) - Target table = No Rows returned. If rows returned, analyze them & find whether the reason for rejection is appropriate. Check for the Referential Integrity Constraints, by segregation all the Tables with Primary/Foreign Key constraints & write queries for RI validation. Check for duplicates of Primary Key Columns

2.

3.

4.

5.

6.

7.

8.

9.

10. Validate the Null & Non-null Columns 11. Validate the relator tables that help in maintaining the historical data. (e.g.) Check the change in relationships that takes place during Day1, Day2, Day3, etc. 12. Give due importance to the following conditions: Certain records might get rejected even before loading the data into the staging table. Certain records might get rejected after loading into the staging but before moving to the target