Portals eNewsletters Web Seminars dataWarehouse.com DM Review Magazine
DM Review | Covering Business Intelligence, Integration & Analytics
   Covering Business Intelligence, Integration & Analytics Advanced Search

Resource Portals
Business Intelligence
Business Performance Management
Data Integration
Data Quality
Data Warehousing Basics
More Portals...


Information Center
DM Review Home
Conference & Expo
Web Seminars & Archives
Current Magazine Issue
Magazine Archives
Online Columnists
Ask the Experts
Industry News
Search DM Review

General Resources
Industry Events Calendar
Vendor Listings
White Paper Library
Software Demo Lab
Monthly Product Guides
Buyer's Guide

General Resources
About Us
Press Releases
Media Kit
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

Ask the Experts Question and Answer

Ask the Expert

Meet the Experts
Ask a Question (Names of individuals and companies will not be used.)
Question Archive
Ask the Experts Home


It has been suggested that we can skip user acceptance testing of the Dimension tables in order to speed up implementation. This is regardless of whether the tables are new or existing. I am adamantly opposed to the idea. I would appreciate your thoughts on the subject.


Sid Adelman's Answer: An old mentor of mine commented on a dysfunctional IT shop and the way they delivered very poor quality systems. His line about their attitude was that "Testing was always an option." Now as it turned out, their testing was either incomplete or non-existent, and they had a dismal record for implementing quality applications. Don't listen to those who suggested taking shortcuts. You can't skip user acceptance testing regardless of whether you have dimension tables, normalized databases, flat files or punch cards.

Larissa Moss' Answer:User acceptance testing (UAT) is never performed on the basis of what types of tables to test. The reason for user acceptance testing is to verify the results of every DW process that either loads data into the tables (ETL process) or accesses data from the tables (reporting process). The idea of skipping UAT for dimension tables suggests to me that the ETL process would not be tested sufficiently- or not at all, which is a very bad idea because many errors on the reports have their origins in a faulty ETL process or in dirty data. Since the ETL process loads data into both the fact and the dimension tables, both must be tested to ensure that all rows were loaded according to specifications (including filtering and aggregating data), to reconcile the values in the target tables to the source files (including transformations and cleansing), and to verify that referential integrity exists between the fact and dimension tables. It is not only best practice but common practice to test all tables for all processes.

Chuck Kelley's Answer:I am with you. I think that the user community needs to be responsible for the data in the dimensions and so they need to "accept" the data. It may not need to be a full-blown month acceptance test, but the user community needs to the data steward of the dimensions (and facts!).

Clay Rehm's Answer:You should never skimp on testing to speed up implementation. Period. Testing is the most overlooked and underappreciated task on a project. There are plenty of books and articles written on this subject and I would encourage you to explore these.

To play devil's advocate, the dimension tables usually are pretty straightforward and could possibly get by with minimal testing depending on their complexity and depending on how much user involvement there was when they were developed.

(Posted )


Site Map Terms of Use Privacy Policy
SourceMedia (c) 2005 DM Review and SourceMedia, Inc. All rights reserved.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.