This testing checks the following:

• Data is able to extract the required fields.

• The Extraction logic for each source system is working
• Extraction scripts are granted security access to the source systems.
• Updating of extract audit log and time stamping is happening.
• Source to Extraction destination is working in terms of completeness and accuracy.
• Extraction is getting completed with in the expected window.

Transformation Testing

• Transaction scripts are transforming the data as per the expected logic.
• The one time Transformation for historical snap-shots are working.
• Detailed and aggregated data sets are created and are matching.
• Transaction Audit Log and time stamping is happening.
• There is no pilferage of data during Transformation process.
• Transformation is getting completed with in the given window

Loading Testing

• There is no pilferage during the Loading process.

• Any Transformations during Loading process is working.
• Data sets in staging to Loading destination is working.
• One time historical snap-shots are working.
• Both incremental and total refresh are working.
• Loading is happening with in the expected window.

End User Browsing and OLAP Testing

• The Business views and dashboard are displaying the data as expected.
• The scheduled reports are accurate and complete.
• The scheduled reports and other batch operations like view refresh etc. is happening in the
expected window.
• 'Analysis Functions' and 'Data Analysis' are working.
• There is no pilferage of data between the source systems and the views.

Ad-hoc Query Testing

• Ad-hoc queries creation is as per the expected functionalities.

• Ad-hoc queries output response time is as expected.

Down Stream Flow Testing

• Data is extracted from the data warehouse and updated in the down-stream systems/data marts.
• There is no pilferage.

One Time Population testing

• The one time ETL for the production data is working

• The production reports and the data warehouse reports are matching
 • T he time taken for one time processing will be manageable within the conversion weekend.

End-to-End Integrated Testing

• End to end data flow from the source system to the down stream system is complete and accurate.

Stress and volume Testing

This part of testing will involve, placing maximum volume OR failure points to check the robustness and
capacity of the system. The level of stress testing depends upon the configuration of the test environment
and the level of capacity planning done. Here are some examples from the ideal world:

• Server shutdown during batch process.

• Extraction, Transformation and Loading with two to three times of maximum possible imagined data
(for which the capacity is planned)
• Having 2 to 3 times more users placing large numbers of ad-hoc queries.
• Running large number of scheduled reports.

Parallel Testing

Parallel testing is done where the Data Warehouse is run on the production data as it would have done in
real life and its outputs are compared with the existing set of reports to ensure that they are in synch OR
have the explained mismatches.

Security Framework testing

Check all possible aspects of Security Framework.

Unlike a typical transaction system, data warehouse testing is different on the
following counts:

User-Triggered vs. System triggered

Most of the web based testing is by processing of individual transactions, which are driven by some inputs
from the users like Application Form or Servicing Request.. There are very few test cycles, which cover the
system-triggered scenarios Like claims processing or adjudication Valuation.

In data Warehouse, most of the testing is system triggered as per the scripts for ETL ('Extraction,
Transformation and Loading'), the view refresh scripts etc.

Therefore typically Data-Warehouse testing is divided into two parts--> 'Back-end' testing where the source
systems data is compared to the end-result data in Loaded area, and 'Front-end' testing where the user
checks the data by comparing their services with the data displayed by the end-user tools like OLAP.

Batch vs. online gratification

This is something, which makes it a challenge to retain users interest.

A web based testing will provide instant OR at least overnight gratification to the users, when user enter a
transaction, which either processed online OR maximum via overnight batch. In the case of data-
warehouse, most of the action is happening in the back-end and users have to trace the individual
transactions based on services and views produced by the OLAP tools. This is the same challenge, when
you ask users to test the month-end mammoth reports/financial statements churned out by the transaction
systems.

Volume of Test Data

The test data in web based application testing is very small sample of the overall production data. Typically
to keep the matters simple, Testing include as many test cases as needed to comprehensively include all
possible test scenarios, in a limited set of test data..

Where as Data Warehouse testing needs typically large test data to fill-up maximum possible combinations
and permutations of dimensions and facts.

For example, if we are testing the location dimension, we would like the location-wise revenue report to
have some revenue figures for most of the regions in 55 states. This would mean that we have to have
thousands of transaction data at regional office level (assuming that regional office is lowest level of
granularity for location dimension).

Possible scenarios/ Test Cases

In web based testing lets say hundred different scenarios; the valid and possible combination of those
scenarios will be limited. However, in case of Data Warehouse, the permutations and combinations can
possibly unlimited due to the core objective of Data Warehouse and is to allow all possible views of Data. In
other words, 'You can never fully test a data Warehouse'

Therefore one has to be creative in designing the test scenarios to gain a high level of confidence.

Test Data Preparation

This is linked to the point of possible test scenarios and volume of data. Data- warehouse needs lots of
effort required to prepare test data and is much more.

Programming for testing challenge

In case of web based testing , users/business analysts typically test the output of the system. However, in
case of data warehouse, as most of the action is happening at the back-end, and most of the 'Data
Warehouse data Quality testing and its done at 'Extraction, Transformation and Loading' which will be by
running separate stand-alone scripts.

These scripts compare pre-Transformation to post Transformation of data.

Users roles come in play, when their help is needed to analyze the same (if designers OR business analysts
are not able to figure it out).