Sales Management Customer Relationship Human Resources Business Performance BI & Data Quality IT Tools & Vendors

  Register
Establishing 'Making it Happen' as a 'Formal & Predictable' Discipline
  Data Warehouse Testing Categories  

ENCYCLOPEDIA→   Enterprise Intelligence  →   -  Data-Warehouse/Mart  →   -  DW Testing and Implementation  → 

Data Warehouse Testing is Different

All works in Data Warehouse population are mostly through batch runs. Therefore the testing is different from what is done in transaction systems.

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

User-Triggered vs. System triggered

Most of the production/Source system testing is the processing of individual transactions, which are driven by some input from the users (Application Form, Servicing Request.). There are very few test cycles, which cover the system-triggered scenarios (Like billing, 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 MIS 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 transaction system will provide instant OR at least overnight gratification to the users, when they enter a transaction, which either is 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 to the MIS 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 a transaction system is a very small sample of the overall production data. Typically to keep the matters simple, we include as many test cases as are needed to comprehensively include all possible test scenarios, in a limited set of test data..

Data Warehouse has typically large test data as one does try to fill-up maximum possible combination and permutations of dimensions and facts.

For example, if you are testing the location dimension, you would like the location-wise sales revenue report to have some revenue figures for most of the 100 cities and the 44 states. This would mean that you have to have thousands of sales transaction data at sales office level (assuming that sales office is lowest level of granularity for location dimension).

Possible scenarios/ Test Cases

If a transaction system has hundred (say) different scenarios, the valid and possible combination of those scenarios will not be unlimited. However, in case of Data Warehouse, the permutations and combinations one can possibly test is virtually unlimited due to the core objective of Data Warehouse 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. Given that a data- warehouse needs lots of both, the effort required to prepare the same is much more.

Programming for testing challenge

In case of transaction systems, 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, most of the 'Data Warehouse data Quality testing' and 'Extraction, Transformation and Loading' testing is done by running separate stand-alone scripts. These scripts compare pre-Transformation to post Transformation (say) comparison of aggregates and throw out the pilferages. 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).


  Data Warehouse Testing Categories  
All Topics in: "DW Testing and Implementation" Chapter
 Data Warehouse Testing is Different →  Data Warehouse Testing Categories →  Data Warehouse Test Scenarios →  Data Warehouse Test Data →  Data Warehouse Implementation Deployment, Training and Support → 
Content Additions
More on DW Testing & Implementation
Data Warehouse Testing Categories
Data Warehouse Test Scenarios
Data Warehouse Test Data
Data Warehouse Implementation Deployment
BUY BI & Data Management Vendors & Tools Evaluation Kit
BUY largest on-line Data-Quality Management Kit
Additional Channels
Principles & Rules
Free Templates
Key Performance Indicators

Most Popular Zones with list of pages crossing 25000 hits  →→→ 
Maximising Sales Performance
Sales Compensation components
Sales Compensation Analysis
Sales Campaign SWOT analysis
Data Management in Sales Campaign
Sales Compensation administration
  Customer Relationship Management
Customer-Centric product-service management
Customer Satisfaction & Retention- Data Management
What is Customer Segmentation?
Exit barriers for Customer Retention
Customer Value and Profitability- BI
  Human Resources & Leadership
Develop Self and Others
Empower Front-line Employees
Maximize the output first and then the potential
Fostering Innovation
Developing Leaders- Few Leadership Traits
Business Performance & Planning
External Info Assessment Report
Financial Business Plan
Strategy Map Objectives Measures and Initiatives
Review Session should stay focused
Dashboard Health Checklist
  Business Intelligence & Data Quality
Data Quality is not Perfect Quality
Data Model Entity Relationship Controls
Data Warehouse Project Initiation
Customer Data Challenges
Data Quality Assurance Track
  IT Vendors & Tools Management
Vendor future plans Strategic fit
OLAP Server Reliability
Vendor Company structure Evaluation
Multi Cube OLAP Architecture
BI Tool Vendor Evaluation