Test Scenario

Test Cases

Mapping doc
validation

Verify mapping doc whether corresponding ETL information is provided or not. Change log
should maintain in every mapping doc.
Define the default test strategy If mapping docs are missed out some optional information.
Ex: data types length etc

Structure validation

1. Validate the source and target table structure against corresponding mapping doc.
2. Source data type and Target data type should be same.
3. Length of data types in both source and target should be equal.
4. Verify that data field types and formats are specified
5. Source data type length should not less than the target data type length.
6. Validate the name of columns in table against mapping doc.

Constraint
Validation

Ensure the constraints are defined for specific table as expected.

Data Consistency
Issues

1. The data type and length for a particular attribute may vary in files or tables though the
semantic definition is the same.
Example: Account number may be defined as: Number (9) in one field or table and
Varchar2(11) in another table
2. Misuse of Integrity Constraints: When referential integrity constraints are misused, foreign
key values may be left dangling or
inadvertently deleted.
Example: An account record is missing but dependent records are not deleted.

Data Completeness
Issues

Ensures that all expected data is loaded in to target table

1. Compare records counts between source and target. Check for any rejected records.
2. Check Data should not be truncated in the column of target table.
3. Check boundary value analysis (ex: only >=2008 year data has to load into the target)
4. Comparing unique values of key fields between source data and data loaded to the
warehouse. This is a valuable technique that points out a variety of possible data errors
without doing a full validation on all fields.

Data Correctness
Issues

1. Data that is misspelled or inaccurately recorded.

2. Null, non-unique, or out of range data may be stored when the integrity constraints are
disabled.
Example: The primary key constraint is disabled during an import function. Data is entered
into the existing data with null unique identifiers.

Data Transformation

1. Create a spread sheet of scenarios of input data and expected results and validate these
with the business customer. This is an excellent requirements elicitation step during design
and could also be used as part of testing.
2. Create test data that includes all scenarios. Utilize an ETL developer to automate the entire
process of populating data sets with the scenario spread sheet to permit versatility and
mobility for the reason that scenarios are likely to change.
3. Utilize data profiling results to compare range and submission of values in each field
between target and source data.
4. Validate accurate processing of ETL generated fields; for example, surrogate keys.
5. Validate that the data types within the warehouse are the same as was specified in the data
model or design.
6. Create data scenarios between tables that test referential integrity.
7. Validate parent-to-child relationships in the data. Create data scenarios that test the
management of orphaned child records.

Data Quality

1. Number check: if in the source format of numbering the columns are as xx_30 but if the
target is only 30 then it has to load not pre_fix(xx_). we need to validate.
2. Date Check: They have to follow Date format and it should be same across all the records.
Standard format: yyyy-mm-dd etc..
3. Precision Check: Precision value should display as expected in the target table.
Example: In source 19.123456 but in the target it should display as 19.123 or round of 20.
4. Data Check: Based on business logic, few record which does not meet certain criteria
should be filtered out.
Example: only record whose date_sid >=2008 and GLAccount != CM001 should only load in
the target table.
5. Null Check: Few columns should display Null based on business requirement.
Example: Termination Date column should display null unless & until if his Active status
Column is T or Deceased.
Note: Data cleanness will be decided during design phase only.

Null Validation

Verify the null values where "Not Null" specified for specified column.

Duplicate check

1. Needs to validate the unique key, primary key and any other column should be unique as
per the business requirements are having any duplicate rows.
2. Check if any duplicate values exist in any column which is extracting from multiple columns
in source and combining into one column.
3. Some time as per the client requirements we needs ensure that no duplicates in
combination of multiple columns within target only.
Example: One policy holder can take multiple polices and multiple claims. In this case we
need to verify the CLAIM_NO, CLAIMANT_NO, COVEREGE_NAME, EXPOSURE_TYPE,
EXPOSURE_OPEN_DATE, EXPOSURE_CLOSED_DATE, EXPOSURE_STATUS, PAYMENT

DATE Validation

Date values are using many areas in ETL development for:

1. To know the row creation date ex: CRT_TS
2. Identify active records as per the ETL development perspective Ex: VLD_FROM, VLD_TO
3. Identify active records as per the business requirements perspective Ex: CLM_EFCTV_T_TS,
CLM_EFCTV_FROM_TS
4. Sometimes based on the date values the updates and inserts are generated.
Possible Test scenarios to validate the Date values:
a. From_Date should not greater than To_Date
b. Format of date values should be proper.
c. Date values should not any junk values or null values

Complete Data
Validation
(using minus and
intersect)

1. To validate the complete data set in source and target table minus query is best solution.
2. We need to source minus target and target minus source.
3. If minus query returns any value those should be considered as mismatching rows.
4. And also we needs to matching rows among source and target using Intersect statement.
5. The count returned by intersect should match with individual counts of source and target
tables.
6. If minus query returns o rows and count intersect is less than source count or target table
count then we can considered as duplicate rows are exists.

Some Useful test

scenarios

1. Verify that extraction process did not extract duplicate data from the source (usually this
happens in repeatable processes where at point zero we need to extract all data from the
source file, but the during the next intervals we only need to capture the modified, and new
rows.)
2. The QA team will maintain a set of SQL statements that are automatically run at this stage
to validate that no duplicate data have been extracted from the source systems.

Data cleanness

Unnecessary columns should be deleted before loading into the staging area.
Example2: If a column have name but it is taking extra space , we have to trim space so
before loading in the staging area with the help of expression transformation space will be
trimmed.
Example1: Suppose telephone number and STD code in different columns and requirement
says it should be in one column then with the help of expression transformation we will
concatenate the values in one column.