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.