ETL Testing and Sanity Check Guide
ETL Testing and Sanity Check Guide
The defect life cycle involves stages: New, Open/Reject, In Analysis, In Development, Ready to Test, In Test, and Done/Reopen. This cycle tracks the status of defects from identification to resolution, ensuring systematic debugging and verification to improve software quality and reliability .
Regression testing checks that new code changes do not adversely affect existing functionalities, ensuring the software's existing code remains operable after updates. It validates that previously working features still perform correctly following code modifications .
The staging area in ETL architecture temporarily holds data from multiple sources before it is loaded into target tables. It combines and cleanses data, removing unwanted elements and standardizing formats, which is crucial for ensuring data accuracy, consistency, and readiness for further processing .
Key documents in the software testing lifecycle include the Test Plan, which outlines testing scope and timelines; the Test Strategy, detailing how testing will be conducted; the Requirement Traceability Matrix (RTM), mapping test cases to requirements; the Business Requirements Document (BRD), aiding in creating test scenarios; and the Functional Requirements Document (FRD), also used for test scenario creation .
Sanity testing is a subset of regression testing, performed after receiving a software build with minor changes to ensure the code works as expected. It checks if further testing can proceed. Smoke testing, on the other hand, determines if the deployed software build is stable enough for further testing, serving as an initial confirmation by the QA team .
In Agile project management, story points are used to estimate the effort required to complete a user story. They reflect the complexity of the story rather than just the time needed. Team members with more experience assign story points for the user stories based on their complexity, with 1 story point being equivalent to 7 hours of work .
In Informatica, available transformations include Source Qualifier, Lookup, Joiner, Filter, Aggregate, and Expression. These transformations process, filter, and join data as it moves from source to target, ensuring that the appropriate modifications and mappings occur to meet business logic and requirements .
In ETL testing, record validation involves several steps: record count validations to ensure the number of records matches from source to target, duplicate checks to identify and handle any duplicate records, reconciliation to validate the entire dataset from source to target, and referential integrity checks to ensure relationships between tables are consistent .
ETL testers typically load the source files into temporary tables using Informatica jobs. After loading, they prepare a source query based on the Source-Target Mapping document and compare it with the target data for validation .
When the source and target databases are different, testers verify if database connections exist between the two databases. They may also use automation tools, such as Python, to facilitate the testing process. Alternatively, sample data can be compared using Excel, though this is not recommended .



