NewBelgiumDW Unit Test Scenarios

NewBelgiumBeerDW MS 2008 ETL Framework
Dimension, Fact Table & Cube Testing Summary
% Pass Dimension Table Assigned To # Tests

0% DimDistAccount 15
0% DimDistAccountSnapshot 3
0% DimDistWarehouse 10
0% DimItem 11
0% DimDate 1
0% DimPremise 4
0% DimCOT 6
0% DimPackage 5
0% DimFlavor 6
0% DimReleaseType 6
0% DimPackageType 5
0% DimDistributor 7
0% DimNBBGeo 6
0% DimCleansedAccount 39
0% DimDataStatus 4
0% DimNBBRole 9
0% DimState 11
0% DimNBBSalesOrg 10
0% DimNBBPersonnelMap 10
0% DimSyndicatedData 8
0% DimCoreFlavor 11
0% DimDistPersonnel 11
0% DimDistWarehouseSalesRepMap 11
% Pass Fact Table Assigned To # Tests

0% FactDailySales 9
0% FactMonthlySales 8
0% FactNonBuyPOD 5
0% FactPODGoal 11
0% FactDistInventory 12
0% FactNBBShipments 8
0% FactAvailability 11
0% FactOrders 10
0% FactNBBInventory 6
0% FactForecast 8
0% FactFeaturesAdsDisplay 9
0% FactSaleDay 8
% Pass Fact Table Assigned To # Tests
0% Cube_DW Test Cases 53
k
# Tests by
Priority Comments
High 12
Medium 1
Low 2
Not Required 0
High 3
Medium 0
Low 0
Not Required 0
High 7
Medium 3
Low 0
Not Required 0
High 8
Medium 1
Low 2
Not Required 0
High 1
Medium 0
Low 0
Not Required 0
High 1
Medium 1
Low 2
Not Required 0
High 3
Medium 1
Low 2
Not Required 0
High 2
Medium 1
Low 0
Not Required 0
High 3
Medium 1
Low 2
Not Required 0
High 3
Medium 1
Low 2
Not Required 0
High 2
Medium 1
Low 2
Not Required 0
High 4
Medium 1
Low 2
Not Required 0
High 3
Medium 1
Low 2
Not Required 0
High 12
Medium 9
Low 18
Not Required 0
High 3
Medium 1
Low 2
Not Required 0
High 6
Medium 1
Low 2
Not Required 0
High 6
Medium 3
Low 2
Not Required 0
High 4
Medium 2
Low 4
Not Required 0
High 5
Medium 3
Low 2
Not Required 0
High 3
Medium 3
Low 2
Not Required 0
High 6
Medium 3
Low 2
Not Required 0
High 6
Medium 3
Low 2
Not Required 0
High 6
Medium 3
Low 2
Not Required 0
# Tests by
Priority Comments
High 9
Medium 0
Low 0
Not Required 0
High 7
Medium 1
Low 0
Not Required 0
High 4
Medium 1
Low 0
Not Required 0
High 7
Medium 2
Low 2
Not Required 0
High 8
Medium 2
Low 2
Not Required 0
High 4
Medium 2
Low 2
Not Required 0
High 7
Medium 2
Low 2
Not Required 0
High 5
Medium 3
Low 2
Not Required 0
High 5
Medium 1
Low 0
Not Required 0
High 4
Medium 2
Low 2
Not Required 0
High 5
Medium 2
Low 2
Not Required 0
High 4
Medium 2
Low 2
Not Required 0
# Tests by
Priority Comments
High 53
Medium 0
Low 0
Not Required 0
Testing Instructions
Step Direction
1 View the Summary tab to determine which Dimension Tables and/or Facts are assigned to your name
2 Select the tab with the label that matches your assigned Dimension Table and/or Fact
3 Fill out the Name and Date fields on top of your assigned Dimension Table and or Fact
4 Starting with Step 1, read the Scenario and Expected Result
5 Perform the Testing Steps and determine whether or not the Expected Result occurs
6 If the Expected Result DOES occur, leave the Actual Result column blank and enter "P" or "Pass" in the Pass / Fail column
7 If the Expected Result DOES NOT occur, leave the Actual Result column blank and enter "F" or "Fail" in the Pass / Fail
column
8 Repeat Steps 4-7 for each step in the Unit Test
9 When you are finished with the all of the steps, review the Pass / Fail column
10 After completion of all test scripts for the package, return to the Summary tab and appropriately fill in the "% Pass" column
NewBelgiumBeerDW MS 2008 ETL Framework Test Cases
Dimension Table: DimDistAccount
Tester's Name:
Test Date: DD/MM/YYYY
Description: Distributor supplied accounts and attributes
Priority Status
High - H New Yet to be Tested
Medium - M Open Currently Being Tested
Low - L Closed Testing Complete
Not Required - NR On Hold Testing on Hold till later [Date]
ID Priority Status Scenario Expected Result

1 H New Change the Type 1 fields for row 10: State and Country. **Make Row should be updated with the different value
sure to complete Test 3 to bring the values back to the new row inserted
original**
2 H New Check that the updated row is in the audit tables Rows updated should be 1 and Rows inserted
UpdateAuditKey value from DimAudit table sho
DimDistAccount.Update Audit Key field for row
3 L New Change the Type 1 fields for row 10 back to the original values: Row should be updated with the original values
State and Country. new row inserted
4 L New Check that the updated row is in the audit tables Rows updated should be 1 and Rows inserted
5 H New Change the Type 1 fields for row 10 to an invalid value not found in Row should be updated with the "Invalid" flag v
the Decode table: State and Country . Invalid values could be:
State = PQ
Country = BeerWorld
**Make sure to complete Test 7 to bring the values back to the
original**
6 H New Verify the Decode table inserted 2 new rows to flag the new "Invalid 2 new rows will be added to the bottom of the li
Values" new values containing the "Invalid" flag.
7 H New Change the Type 1 fields for 1 row back to the original values: Row should be updated with the original values
State and Country new row inserted
8 H New Negative value testing: Change the Type 1 field for row 20: Channel Should receive appropriate error message that
to Null instead of its current value. **Make sure to complete Test be a null value
9 to bring the values back to the original**
9 H New Change the Type 1 field for row 20: Channel back to its original Row should be updated with the original values
value new row inserted
10 H New Duplicate ID Check for VIPID - VIP Account Number. This is a These values should be unique and no duplicat
unique number assigned by VIP to each account independent of
distributor.
11 H New Constraints: During constraint testing, the objective is to validate All contraints should be populated and unique.
unique constraints, primary keys, foreign keys, indexes, and
relationships. Contraints for this dimension are:
DisAccountKey, BKDistSupplierID, BKRetailOutletCustomerID.
12 H New Initialization During the ETL process: If the code does not re- All fields from original data where a Null value i
initialize the cursor (or working storage) after each record, there is a should be null. Compare to AJWinterAle spread
chance that fields with null values may contain data from a previous
record. Fields that could contain a Null value and should be
checked are: VIPID, Key Account Flag, Record Type, Premise
Name, Licensee Name, Address2, Zip, Country, Phone, Chaine
Code, Chain Code 2, Fine Wine Store, Chain Status, Display
Account, Patron Ethnicity, Industry Volume, Patron Lifecycle,
Occupation, Patron Age, Type, Outlet Type, Primarey Sales Route,
Secondary Sales Route, StoreNumber RetailOutletStores, and
Territory Flag 1 - Territory Flag 30.
13 M New New Record Validation: Add a new test record with test data. 1 new row should be added. InsertAuditKey sho
populated with DimAudit.InsertAuditKey value f
record.
14 H New Invalid Business Key Change: Check to ensure that invalid changes Should receive appropriate error message that
to business keys cannot be made. Business Keys to check: key.
BKDistSupplierID and BKRetailOutletCustomerID.
15 H New Check Type 2 fields as these are derived in the ETL. These are These fields should be changing as data is load
standard Slowly Changing Dimension (SCD)-2 columns where changed. Ensure that values are being updated
historical changes need to be tracked. Type 2 fields to check are: date/time and reasons.
RowIsCurrent, RowStartDate, RowEndDate, and
RowChangeReason.
16
17
18
19
20
21
22
23
24
25
26
27
28
ses
Test Summary
Total Pass 0
Total Fail 0
Total N/A 15
Total Tests on Worksheet 15
Expected Result Testing Steps

Row should be updated with the different values inserted, no Run the following SQL statement against NBB DW: To be added
new row inserted
DistAccountKey = 10
Rows updated should be 1 and Rows inserted should be 1. Run the following SQL statement against the NBB DW: Select
UpdateAuditKey value from DimAudit table should be in PrimarySourceDatabase, PrimarySourceTableName,
DimDistAccount.Update Audit Key field for row 10. DestinationDatabase, DestinationTableName, InsertStdRowCnt,
UpdateRowCnt, PkgName From AuditTableProcessing,
AuditPkgExecution Where
AuditTableProcessing.PkgExecKey=AuditPkgExecution.PkgExecKe
y
Row should be updated with the original values inserted, no Run the following SQL statement against NBB DW: To be added
new row inserted
Rows updated should be 1 and Rows inserted should be 1 Run the following SQL statement against the NBB DW: Select
PrimarySourceDatabase, PrimarySourceTableName,
DestinationDatabase, DestinationTableName, InsertStdRowCnt,
y
Row should be updated with the "Invalid" flag value inserted. Run the following SQL statement against NBB DW: To be added
2 new rows will be added to the bottom of the list showing the Run the following SQL statement against the NBB DW: Select * From
new values containing the "Invalid" flag. dbo.Decode
new row inserted
Should receive appropriate error message that this field cannot Run the following SQL statement against NBB DW: To be added
be a null value
DistAccountKey = 20
new row inserted
These values should be unique and no duplicates. Run the following SQL statement against NBB DW: To be added
All contraints should be populated and unique. Run the following SQL statement against NBB DW: To be added
All fields from original data where a Null value is expected Run the following SQL statement against NBB DW: To be added
should be null. Compare to AJWinterAle spreadsheet.
1 new row should be added. InsertAuditKey should be Run the following SQL statement against NBB DW: To be added
populated with DimAudit.InsertAuditKey value for this new
record.
Should receive appropriate error message that this is an invalid Run the following SQL statement against NBB DW: To be added
key.
These fields should be changing as data is loaded and Run the following SQL statement against NBB DW: To be added
changed. Ensure that values are being updated with appropriate
date/time and reasons.
Pass
Fail
Pass / Fail Actual Results
Created By: Frank Quatraro
Comments
Dimension Table: DimDistAccountSnapshot
Tester's Name:
Description: Snapshot of accounts to be able to track account changes over time
Priority Status

1 H New After completing DimDistAccount unit test 1 verify new record with 1 new row should be added with State and Cou
modified State and Country values is added to this dimension table.
2 H New After completing DimDistAccount unit test 3 verify new record with 1 new row should be added with State and Cou
modified State and Country values (back to original values) is back to original values
added to this dimension table.
3 H New After completing DimDistAccount unit test 17 verify brand new 1 new row should be added as a copy of the ne
record has been added to this table. DimDistAccount. Verify that DistAccountSnapsh
current date as the test is run.
4
5
6
7
8
9
10
11
12
13
14
15
16
17
ses
s over time
Test Summary
Total Pass 0
Total Fail 0
Total N/A 3

1 new row should be added with State and Country changes Run the following SQL statement against the NBB DW: Select * From
dbo.DimDistAccountSnapshot
1 new row should be added with State and Country changes Run the following SQL statement against the NBB DW: Select * From
back to original values dbo.DimDistAccountSnapshot
1 new row should be added as a copy of the new record from Run the following SQL statement against the NBB DW: Select * From
DimDistAccount. Verify that DistAccountSnapshotDate field has dbo.DimDistAccountSnapshot
current date as the test is run.
Pass
Fail
Comments
Dimension Table: DimDistWarehouse
Tester's Name:
Description: Lists all of the distributor and warehouse combinations
Priority Status

1 H New Change the Type 1 fields for row 10: Address, City, State, Zip, and Row should be updated with the different value
Country. **Make sure to complete Test 3 to bring the values new row inserted
back to the original**
DimDistWarehouse.Update Audit Key field for r
3 M New Change the Type 1 fields for 1 row back to the original values: Row should be updated with the original values
Address, City, State, Zip, and Country. new row inserted
4 M New Check that the updated row is in the audit tables Rows updated should be 1 and Rows inserted
5 H New Negative value testing: Change the Type 1 field for row 20: Change Should receive appropriate error message that
to Null instead of its current value. Perform negative value testing cannot be a null value.
for: Distributor Warehouse ID, DistIributor ID, State, Warehouse
Name, Distributor Name, and Birthday (Year warehouse joined
NBB).
original**
6 H New Change the Type 1 field for row 20: Distributor Warehouse ID, Row should be updated with the original values
DistIributor ID, State, Warehouse Name, Distributor Name, and new row inserted.
Birthday back to their original value.
7 H New Constraints: During constraint testing, the objective is to validate All contraints should be populated and unique.
DistWarehouseKey, BKDistWhseID, and DistID.
initialize the cursor (or working storage) after each record, there is a should be null. Compare to Loft1\Instance1 spr
checked are: Address1, Address2, City, Zip, and Phone.
9 M New New Record Validation: Add a new test record with test data. 1 new row should be added. InsertAuditKey sho
populated with DimAudit.InsertAuditKey value f
record.
10 H New Invalid Business Key Change: Check to ensure that invalid changes Should receive appropriate error message that
to business keys cannot be made. Business Keys to check: key.
DistWarehouseKey, BKDistWhseID, and DistID.
11
12
13
14
15
16
17
18
19
ses
Test Summary
Total Pass 0
Total Fail 0
Total N/A 10
Expected Result
Row should be updated with the different values inserted, no
new row inserted
Rows updated should be 1 and Rows inserted should be 1.

UpdateAuditKey value from DimAudit table should be in
DimDistWarehouse.Update Audit Key field for row 10.
Row should be updated with the original values inserted, no

new row inserted
Rows updated should be 1 and Rows inserted should be 1
Should receive appropriate error message that these fields

cannot be a null value.
Row should be updated with the original values inserted, no

new row inserted.
All contraints should be populated and unique.
All fields from original data where a Null value is expected

should be null. Compare to Loft1\Instance1 spreadsheet.
1 new row should be added. InsertAuditKey should be

populated with DimAudit.InsertAuditKey value for this new
record.
Should receive appropriate error message that this is an invalid
key.
Pass
Fail
Testing Steps Pass / Fail
Run the following SQL statement against NBB DW: To be added
DistWarehouseKey = 10
Run the following SQL statement against the NBB DW: Select
PrimarySourceDatabase, PrimarySourceTableName, DestinationDatabase,
DestinationTableName, InsertStdRowCnt, UpdateRowCnt, PkgName From
AuditTableProcessing, AuditPkgExecution Where
AuditTableProcessing.PkgExecKey=AuditPkgExecution.PkgExecKey
DistWarehousetKey = 10
PrimarySourceDatabase, PrimarySourceTableName, DestinationDatabase,
DestinationTableName, InsertStdRowCnt, UpdateRowCnt, PkgName From
AuditTableProcessing, AuditPkgExecution Where
AuditTableProcessing.PkgExecKey=AuditPkgExecution.PkgExecKey
DistWarehousetKey = 20

Actual Results
Comments
Dimension Table: DimItem
Tester's Name:
Description: Contains combinations of flavor and package types
Priority Status

1 H New Change the Type 1 fields for row 25: Change Item Status (A/I) Row should be inserted, row 2 "Row is Current
"N" and the new row should reflect the changes
statement.
2 H New Check that the updated rows are in the audit tables Rows updated should be 1 and Rows inserted
DimDistWarehouse.Update Audit Key field for r
3 L New Change the Type 1 fields for 1 row back to the original values: Item Row should be updated with the original values
Status (A/I) new row inserted
4 H New Change the Type 1 fields for row 25: Flavor Abbreviation, Package Row should be updated with the different value
Abbreviation, Package Name, Package Type, and Item Long Name. new row inserted
original**
5 M New Check that the updated rows are in the audit tables Rows updated should be 1 and Rows inserted
DimItem.Update Audit Key field for row 25.
6 L New Change the Type 1 fields for 1 row back to the original values: Row should be updated with the original values
Flavor Abbreviation, Package Abbreviation, Package Name, new row inserted
Package Type, and Item Long Name.
7 H New Source-to-Target field to field validation. Check that data from Data from GP should match data in DimItem fo
spreadsheet has been uploaded correctly into warehouse. Fields to
check: UnitsPerCase, Case Weight, Pallet Weight, and Ounces Per
Case.
8 H New Negative value testing: Change the Type 1 field for row 20: Change Should receive appropriate error message that
to Null instead of its current value. Perform negative value testing cannot be a null value.
for: BKVIPSRSID, Units Per Case, and Ounces Per Case.
**Make sure to complete Test 11 to bring the values back to
the original**
9 H New Change the Type 1 field for row 20: BKVIPSRSID, Units Per Case, Row should be updated with the original values
and Ounces Per Case. back to their original value. new row inserted.
initialize the cursor (or working storage) after each record, there is a should be null. Compare to SKU and GP sourc
checked are: ItemID, FlavorShortName, PackageShortName,
FlavorName, PackageName, PackageType, ReleaseType,
CurrentStatus, CostofGoodsSold, LongName, CaseWeight, Pallet
Weight, and ItemIsActive.
11 H New Check Type 2 fields as these are derived in the ETL. These are These fields should be changing as data is load
standard Slowly Changing Dimension (SCD)-2 columns where changed. Ensure that values are being updated
historical changes need to be tracked. Type 2 fields to check are: date/time and reasons.
RowChangeReason.
12
13
ses
Test Summary
Total Pass 0
Total Fail 0
Total N/A 11

Row should be inserted, row 2 "Row is Current" field should be Run the following SQL statement against NBB DW: To be added
"N" and the new row should reflect the changes in the SQL ItemKey = 25
statement.
Rows updated should be 1 and Rows inserted should be 1. Run the following SQL statement against the RevereAWDW: Select
DimDistWarehouse.Update Audit Key field for row 20. DestinationDatabase, DestinationTableName, InsertStdRowCnt,
y
new row inserted
new row inserted
Rows updated should be 1 and Rows inserted should be 1. Run the following SQL statement against the RevereAWDW: Select
DimItem.Update Audit Key field for row 25. DestinationDatabase, DestinationTableName, InsertStdRowCnt,
y
new row inserted
Data from GP should match data in DimItem for each record. Run the following SQL statement against NBB DW: To be added
Should receive appropriate error message that these fields Run the following SQL statement against NBB DW: To be added
cannot be a null value.
ItemKey = 20
new row inserted.
should be null. Compare to SKU and GP source data.
These fields should be changing as data is loaded and Run the following SQL statement against NBB DW: To be added
changed. Ensure that values are being updated with appropriate
date/time and reasons.
Pass
Fail
Comments
Dimension Table: DimDate
Tester's Name:
Description: Date dimension contains one row for every Calender Day, beginning at 1
system. Need to test initial data load. The Fiscal Date dimension uses the excel sprea
Priority Status
High - H New
Medium - M Open
Low - L Closed
Not Required - NR On Hold
ID Priority Status Scenario

1 H New Need to test initial data load of this dimension for Type 1 data fields
as all fields are derived. Data fields to check are: DateKey (i.e.
Calendar Date as an integer), Calendar Date (Full date as a SQL
date = 12/32/1999 and time =00:00:00), Calendar Day of Year (The
day of the year 1 - 366), Calendar Month Name (January -
December), Calendar Month Number (1-12), Calendar Quarter (1 -
4), Calnedar Day of Week Name (Sunday - Saturday), Calendar
Day of Week (1 -7), Calendar Day of Month (1-31), Calendar Week
of Month (1-5), Calendar Week of Year (1-52), Calendar Year (4
digit year), Calendar Year Month as integer (Year and Month as
integer, 200601), Calendar Year Quarter as integer (Year and
Quarter as integer, 200601), Is This the Last Day of Month (Y/N),
Last Date of Calendar Month (date 12/31/1999 or 1/30/2010), and
Last updated (on first load should be current day/time).
5
6
8
9
10
11
12
13
14
15
Framework Test Cases
w for every Calender Day, beginning at 1/1/1985 through 12/31/2035. The Date dimension is de
al Date dimension uses the excel spreadsheet 'Date Dimension Calendar Only'.
Test Summary
Yet to be Tested Total Pass 0
Currently Being Tested Total Fail 0
Testing Complete Total N/A 1
Testing on Hold till later [Date] Total Tests on Worksheet 1
Scenario Expected Result

d of this dimension for Type 1 data fields Record Count: Rows updated should be X and Rows inserted
ata fields to check are: DateKey (i.e. should be X. X = number of records in excel spreadsheet
er), Calendar Date (Full date as a SQL 'Date Dimension Calendar Only'.
e =00:00:00), Calendar Day of Year (The
alendar Month Name (January - Data Validation: Perform source-to-target field-to-field data
th Number (1-12), Calendar Quarter (1 - accuracy.
Name (Sunday - Saturday), Calendar
dar Day of Month (1-31), Calendar Week
Week of Year (1-52), Calendar Year (4
Month as integer (Year and Month as
r Year Quarter as integer (Year and
1), Is This the Last Day of Month (Y/N),
nth (date 12/31/1999 or 1/30/2010), and
should be current day/time).
e Date dimension is derived and is not populated from any transaction
dar Only'.
Pass
Fail
Actual Results
Comments
Dimension Table: DimPremise
Tester's Name:
Description: Indicates if on/off premise (bars with draft)
Priority Status

1 H New Change the Type 1 fields for row 100: Premise On/Off. **Make Row should be updated with the different value
sure to complete Test 3 to bring the values back to the new row inserted
original**
DimPremise.Update Audit Key field.
Premise On/Off. new row inserted
5
6
7
8
9
10
11
12
13
14
15
16
17
ses
Test Summary
Total Pass 0
Total Fail 0
Total N/A 4

new row inserted
PremiseKey = 100
DimPremise.Update Audit Key field. DestinationDatabase, DestinationTableName, InsertStdRowCnt,
y
new row inserted
y
Pass
Fail
Comments
Dimension Table: DimCOT
Tester's Name:
Description: An attribute of Accounts that classifies them in different channels
Priority Status

1 H New Change the Type 1 fields for row 250: COT Name. **Make sure to Row should be updated with the different value
complete Test 7 to bring the values back to the original** new row inserted
DimCOT.Update Audit Key field.
COT Name. new row inserted
5 H New Check derived value for PremiseName field for data accuracy. If COT Number < 21 then PremiseName = Off,
6 H New Need to test initial data load of this dimension for Type 1 data fields. Data Validation: Perform source-to-target field-
Data fields to check are: COTNumber and COTName. accuracy.
7
8
9
10
11
12
13
ses
channels
Test Summary
Total Pass 0
Total Fail 0
Total N/A 6

new row inserted
COTKey = 10
DimCOT.Update Audit Key field. DestinationDatabase, DestinationTableName, InsertStdRowCnt,
y
new row inserted
y
If COT Number < 21 then PremiseName = Off, else On. Run the following SQL statement against NBB DW: To be added
Data Validation: Perform source-to-target field-to-field data Run the following SQL statement against NBB DW: To be added
accuracy.
Pass
Fail
Comments
Dimension Table: DimPackage
Tester's Name:
Description: Package size of the beers
Priority Status

1 New Change the Type 1 fields for row 75: PackageShortName, Row should be updated with the different value
PackageName, Flavor/Package Abbrev (BKVIPSRSID). **Make new row inserted
sure to complete Test 3 to bring the values back to the
original**
2 New Check that the updated row is in the audit tables Rows updated should be 1 and Rows inserted
3 H New Change the Type 1 fields for 1 row back to the original values: Row should be updated with the original values
PackageShortName, PackageName, Flavor/Package Abbrev new row inserted
(BKVIPSRSID).
initialize the cursor (or working storage) after each record, there is a should be null. Compare to SKU source data.
checked are: Package Abbreviation and Package Name.
6
7
8
9
10
11
12
13
14
15
16
17
ses
Test Summary
Total Pass 0
Total Fail 0
Total N/A 5

new row inserted
PackageKey = 75
y
new row inserted
y
should be null. Compare to SKU source data.
Pass
Fail
Comments
Dimension Table: DimFlavor
Tester's Name:
Description: Flavors of the Beers
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Change the Type 1 fields for row 75: FlavorShortName,
FlavorName, Flavor/Package Abbrev (BKVIPSRSID). **Make sure
to complete Test 3 to bring the values back to the original**
2 M New Check that the updated row is in the audit tables
3 L New Change the Type 1 fields for 1 row back to the original values:
FlavorShortName, FlavorName, Flavor/Package Abbrev
(BKVIPSRSID).
4 L New Check that the updated row is in the audit tables
5 H New Initialization During the ETL process: If the code does not re-
initialize the cursor (or working storage) after each record, there is a
checked are: Flavor Abbreviation and Flavor Name.
6 H New Check Type 2 fields as these are derived in the ETL. These are
standard Slowly Changing Dimension (SCD)-2 columns where
historical changes need to be tracked. Type 2 fields to check are:
RowChangeReason.
7
8
9
10
11
12
13
14
15
16
17
Test Summary

or row 75: FlavorShortName, Row should be updated with the different values inserted, no
ge Abbrev (BKVIPSRSID). **Make sure new row inserted
ng the values back to the original**
w is in the audit tables Rows updated should be 1 and Rows inserted should be 1
for 1 row back to the original values: Row should be updated with the original values inserted, no
Name, Flavor/Package Abbrev new row inserted
L process: If the code does not re- All fields from original data where a Null value is expected
king storage) after each record, there is a should be null. Compare to SKU source data.
values may contain data from a previous
ontain a Null value and should be
viation and Flavor Name.
se are derived in the ETL. These are These fields should be changing as data is loaded and
Dimension (SCD)-2 columns where changed. Ensure that values are being updated with appropriate
be tracked. Type 2 fields to check are: date/time and reasons.
ate, RowEndDate, and
Pass
Fail
PackageKey = 75
y
y
Actual Results
Comments
Dimension Table: DimReleaseType
Tester's Name:
Description: Contains a class of flavors like seasonal or lips of death
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Change the Type 1 fields for row 92: ReleaseType and
Flavor/Package Abbrev (BKVIPSRSID). **Make sure to complete
Test 3 to bring the values back to the original**
ReleaseType and Flavor/Package Abbrev (BKVIPSRSID).
checked are: Release Type.
RowChangeReason.
7
8
9
10
11
12
13
14
15
16
17
easonal or lips of death
Test Summary

or row 92: ReleaseType and Row should be updated with the different values inserted, no
KVIPSRSID). **Make sure to complete new row inserted
s back to the original**
Package Abbrev (BKVIPSRSID). new row inserted
king storage) after each record, there is a should be null. Compare to SKU source data.
e.
Pass
Fail
ReleaseTypeKey = 92
y
y
Actual Results
Comments
Dimension Table: DimPackageType
Tester's Name:
Description: Contains draft or package column
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Change the Type 1 fields for row 92: PackageType and
Flavor/Package Abbrev (BKVIPSRSID).
PackageType and Flavor/Package Abbrev (BKVIPSRSID).
checked are: Package Type.
6
7
8
9
10
11
12
13
Test Summary

or row 92: PackageType and Row should be updated with the different values inserted, no
KVIPSRSID). **Make sure to complete new row inserted
Package Abbrev (BKVIPSRSID). new row inserted
king storage) after each record, there is a should be null. Compare to GP source data.
e.
Pass
Fail
PackageTypeKey = 92
y
y
Actual Results
Comments
Dimension Table: DimDistributor
Tester's Name:
Description: A table to contain the name of the distributor
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Change the Type 1 fields for row 5: Distributor Name **Make sure
Distributor Name.
5 H New Change the Type 1 field for row 5: Distributor Name to Null instead
of their current value. **Make sure to complete Test 6 to bring
the values back to the original**
6 H New Change the Type 1 field for row 5: Distributor Name back to its
original value
checked are: Distributor Name.
8
9
10
11
12
13
e distributor
Test Summary

or row 5: Distributor Name **Make sure Row should be updated with the different values inserted, no
ng the values back to the original** new row inserted
new row inserted
r row 5: Distributor Name to Null instead Should receive appropriate error message that this field cannot
ake sure to complete Test 6 to bring be a null value
iginal**
r row 5: Distributor Name back to its Row should be updated with the original values inserted, no
new row inserted
king storage) after each record, there is a should be null. Compare to GP source data.
ame.
Pass
Fail
DistributorKey = 5
y
y

Actual Results
Comments
Dimension Table: DimNBBGeo
Tester's Name:
Description: Shows the geography of warehouse groupings called areas
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Change the Type 1 fields for row 12: MarketName, Area Name,
Region Name, and Division Name **Make sure to complete Test
3 to bring the values back to the original**
MarketName, Area Name, Region Name, and Division Name.
checked are: Market Name, Area Name, Region Name, and
Division Name.
RowChangeReason.
7
8
9
10
11
12
13
use groupings called areas
Test Summary

or row 12: MarketName, Area Name, Row should be updated with the different values inserted, no
n Name **Make sure to complete Test new row inserted
k to the original**
Region Name, and Division Name. new row inserted
king storage) after each record, there is a should be null. Compare to source data.
e, Area Name, Region Name, and
Pass
Fail
NBBGeoKey = 12
y
y

Actual Results
Comments
Dimension Table: DimCleansedAccount
Tester's Name:
Description: Cleansed store attributes to each outlet across US which is authorized t
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Change the Type 1 fields for row 500: StoreBannerName,
LicenseName, Street Address, City, State, Zip, Country Name, and
Phone Number. **Make sure to complete Test 3 to bring the
values back to the original**
StoreBannerName, LicenseName, Street Address, City, State, Zip,
Country Name, and Phone Number.
5 H New Change the Type 1 fields for row 500: Chain Store Number,
Franchise Indicator, Chain Status, and Chain Hierarchy Level.
original**
Chain Store Number, Franchise Indicator, Chain Status, and Chain
Hierarchy Level.
9 H New Change the Type 1 fields for row 500: Class of Trade, Sub-Class of
Trade, Cuisine Type, Premise Type, and Store Status. **Make sure
Class of Trade, Sub-Class of Trade, Cuisine Type, Premise Type,
and Store Status.
13 H New Change the Type 1 fields for row 500: Malt Beverage Indicator,
Wine Beverage Indicator, Spirits Indicator, Distribution Center
Code, Latitude, and Longitude. **Make sure to complete Test 15
to bring the values back to the original**
Malt Beverage Indicator, Wine Beverage Indicator, Spirits Indicator,
Distribution Center Code, Latitude, and Longitude
17 H New Change the Type 1 fields for row 500: FIPS Code, MSA Code,
Account Cluster, Open Date, and Closed Date. **Make sure to
complete Test 19 to bring the values back to the original**
18 M Check that the updated row is in the audit tables
New
19 L Change the Type 1 fields for 1 row back to the original values:
FIPS Code, MSA Code, Account Cluster, Open Date, and Closed
Date.
New
20 L Check that the updated row is in the audit tables
New
21 H Change the Type 1 fields for row 500: Immediate Owner (IO), IO
Address, IO City, IO State, IO Zip, and IO Phone. **Make sure to
New
New
Immediate Owner (IO), IO Address, IO City, IO State, IO Zip, and IO
Phone.
New
New
25 H Change the Type 1 fields for row 500: Divisional Break (DB), DB
Address, DB City, DB State, DB Zip, and DB Phone. **Make sure
New
New
Divisional Break (DB), DB Address, DB City, DB State, DB Zip, and
DB Phone.
New
New
29 H Change the Type 1 fields for row 500: Buying Office (BO), BO
Address, BO City, BO State, BO Zip, and BO Phone. **Make sure
New
New
Buying Office (BO), BO Address, BO City, BO State, BO Zip, and
BO Phone.
New
New
33 H Change the Type 1 fields for row 500: Corporate HQ (HQ), HQ
Address, HQ City, HQ State, HQ Zip, and HQ Phone. **Make sure
New
New
Corporate HQ (HQ), HQ Address, HQ City, HQ State, HQ Zip, and
HQ Phone.
New
New
37 H Initialization During the ETL process: If the code does not re-
checked are: StoreBannerName, LicenseName, Street Address,
Address 2, City, State, Zip, County Name, Country Name, Phone
Number, Chain Code, Chain Store Number, Chain Hierarchy Level
1, Class of Trade, Sub-Class of Trade, Cuisine Type, Premise
Type, Store Status, Malt Beverage Indicator, Wine Beverage
Indicator, Spirits Indicator, Distribution Center Code, Latitude, and
Longitude, FIPS Code, MSA Code, Account Cluster, Open Date,
and Closed Date, Immediate Owner (IO), IO Address, IO City, IO
State, IO Zip, IO Phone, Divisional Break (DB), DB Address, DB
City, DB State, DB Zip, DB Phone, Buying Office (BO), BO
Address, BO City, BO State, BO Zip, BO Phone, Corporate HQ
(HQ), HQ Address, HQ City, HQ State, HQ Zip, HQ Phone.
New
38 H Check Type 2 fields as these are derived in the ETL. These are
Chain Code, Chain Store Number, Chain Hierarchy Level 1, Store
Status, Distribution Center Code, Account Cluster, Open Date, and
Closed Date, Immediate Owner, Divisional Break, Buying Office,
Corporate HQ, RowIsCurrent, RowStartDate, RowEndDate, and
RowChangeReason.
New
39 H Duplicate ID Check for VIPID - VIP Number. This is a unique
number assigned by VIP to uniquely identify each outlet.
New
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
outlet across US which is authorized to sell alcohol
Test Summary

or row 500: StoreBannerName, Row should be updated with the different values inserted, no
ess, City, State, Zip, Country Name, and new row inserted
ure to complete Test 3 to bring the
al**
eName, Street Address, City, State, Zip, new row inserted
Number.
or row 500: Chain Store Number, Row should be updated with the different values inserted, no
Status, and Chain Hierarchy Level. new row inserted
Test 7 to bring the values back to the
chise Indicator, Chain Status, and Chain new row inserted
or row 500: Class of Trade, Sub-Class of Row should be updated with the different values inserted, no
mise Type, and Store Status. **Make sure new row inserted
ing the values back to the original**
of Trade, Cuisine Type, Premise Type, new row inserted
or row 500: Malt Beverage Indicator, Row should be updated with the different values inserted, no
Spirits Indicator, Distribution Center new row inserted
ude. **Make sure to complete Test 15
to the original**
Wine Beverage Indicator, Spirits Indicator, new row inserted
Latitude, and Longitude
or row 500: FIPS Code, MSA Code, Row should be updated with the different values inserted, no
te, and Closed Date. **Make sure to new row inserted
g the values back to the original**
ccount Cluster, Open Date, and Closed new row inserted
or row 500: Immediate Owner (IO), IO Row should be updated with the different values inserted, no
IO Zip, and IO Phone. **Make sure to new row inserted
Address, IO City, IO State, IO Zip, and IO new row inserted
or row 500: Divisional Break (DB), DB Row should be updated with the different values inserted, no
e, DB Zip, and DB Phone. **Make sure new row inserted
Address, DB City, DB State, DB Zip, and new row inserted
or row 500: Buying Office (BO), BO Row should be updated with the different values inserted, no
e, BO Zip, and BO Phone. **Make sure new row inserted
dress, BO City, BO State, BO Zip, and new row inserted
or row 500: Corporate HQ (HQ), HQ Row should be updated with the different values inserted, no
e, HQ Zip, and HQ Phone. **Make sure new row inserted
ddress, HQ City, HQ State, HQ Zip, and new row inserted
Name, LicenseName, Street Address,
, County Name, Country Name, Phone
in Store Number, Chain Hierarchy Level
ss of Trade, Cuisine Type, Premise
everage Indicator, Wine Beverage
Distribution Center Code, Latitude, and
SA Code, Account Cluster, Open Date,
te Owner (IO), IO Address, IO City, IO
ivisional Break (DB), DB Address, DB
B Phone, Buying Office (BO), BO
e, BO Zip, BO Phone, Corporate HQ
y, HQ State, HQ Zip, HQ Phone.
Number, Chain Hierarchy Level 1, Store
Code, Account Cluster, Open Date, and
wner, Divisional Break, Buying Office,
ent, RowStartDate, RowEndDate, and
PID - VIP Number. This is a unique These values should be unique and no duplicates.
o uniquely identify each outlet.
Pass
Fail
CleansedAccountKey = 500
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y
y

Actual Results
Comments
Dimension Table: DimDataStatus
Tester's Name:
Description: Is the data approved or not at the warehouse level
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Change the Type 1 fields for row 12: DateApprovedFor,
DateApprovedOn, and Approved By. **Make sure to complete
DateApprovedFor, DateApprovedOn, and Approved By.
5 H New Constraints: During constraint testing, the objective is to validate

DataStatusKey (Status of the Date), Date, and DistWarehouseKey .
checked are: DateApprovedOn and Approved By.
7
8
9
10
11
12
13
warehouse level
Test Summary

or row 12: DateApprovedFor, Row should be updated with the different values inserted, no
proved By. **Make sure to complete new row inserted
provedOn, and Approved By. new row inserted
aint testing, the objective is to validate All contraints should be populated and unique.
y keys, foreign keys, indexes, and
r this dimension are:
he Date), Date, and DistWarehouseKey .
dOn and Approved By.
Pass
Fail
DataStatusKey = 12
y
y

Actual Results
Comments
Dimension Table: DimNBBRole
Tester's Name:
Description: Various roles at NBB.
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Change the Type 1 fields for row 6: Role Name. **Make sure to
Role Name.
5 H New Add new Role Name.
6 H New Check that the updated row is in the audit tables

7 H New Delete new Role Name.
8 H New Check that the updated row is in the audit tables
checked are: NBBRole (i.e. Role Name).
10
11
12
13
Test Summary

or row 6: Role Name. **Make sure to Row should be updated with the different values inserted, no
the values back to the original** new row inserted
new row inserted
Rows updated should be 1 and Rows deleted should be 1
. Role Name).
Pass
Fail
NBBRoleKey = 6
y
y
y
y
Actual Results
Comments
Dimension Table: DimState
Tester's Name:
Description: State Codes and descriptions
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Change the Type 1 fields for row 48: State ID and State
Description. **Make sure to complete Test 3 to bring the values
State ID and State Description.
5 H New Add new State ID and State Description.

7 H New Delete new State ID and State Description.
checked are:State Description.
10 H New Negative value check. Change the Type 1 field for row 5: State ID
to Null instead of their current value. **Make sure to complete
11 H New Change the Type 1 field for row 5: State ID back to its original value
instead of the null value.
12
13
Test Summary

or row 48: State ID and State Row should be updated with the different values inserted, no
o complete Test 3 to bring the values new row inserted
tion. new row inserted
e Description. Rows updated should be 1 and Rows inserted should be 1
tate Description. Rows updated should be 1 and Rows deleted should be 1
tion.
ange the Type 1 field for row 5: State ID Should receive appropriate error message that this field cannot
ent value. **Make sure to complete be a null value
es back to the original**
r row 5: State ID back to its original value Row should be updated with the original values inserted, no
new row inserted.
Pass
Fail
StateKey = 48
y
y
y
y

Actual Results
Comments
Dimension Table: DimNBBSalesOrg
Tester's Name:
Description: NBB organizational people and hierarchy
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Change the Type 1 fields for row 65: Employee Title, Name of
Employee, Reports To, Job Function, DataWarehouseID, Manager
Flag. **Make sure to complete Test 3 to bring the values back
to the original**
Employee Title, Name of Employee, Reports To, Job Function,
DataWarehouseID, Manager Flag.
5 H New Add new Employee

7 L New Delete new employee added in Test 5 to bring data back to original
state and test delete functionality.
checked are: Employee Title, Reports To, Job Function,
DistWarehouseID, and ManagerFlag.
historical changes need to be tracked. RowIsCurrent,
RowStartDate, RowEndDate, and RowChangeReason.
11
12
13
ierarchy
Test Summary

or row 65: Employee Title, Name of Row should be updated with the different values inserted, no
b Function, DataWarehouseID, Manager new row inserted
plete Test 3 to bring the values back
Employee, Reports To, Job Function, new row inserted
er Flag.

ed in Test 5 to bring data back to original Rows updated should be 1 and Rows deleted should be 1
onality.
le, Reports To, Job Function,
nagerFlag.
be tracked. RowIsCurrent, date/time and reasons.
te, and RowChangeReason.
Pass
Fail
NBBSalesOrganizationKey = 65
y
y
y
y

Actual Results
Comments
Dimension Table: DimNBBPersonnelMap
Tester's Name:
Description: Maps the hierarchy of the NBB personnel.
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Change the Type 1 fields for row 65: NBB Role and Distributor
Warehouse. **Make sure to complete Test 3 to bring the values
NBB Role and Distributor Warehouse.
5 H New Add new NBB Role

7 H New Delete new NBB Role added in Test 5 to bring data back to original
9 H New Change the Type 1 field for row 65: NBB Role and Distributor
Warehouse to Null instead of their current value. **Make sure to
10 H New Change the Type 1 field for row 65: NBB Role and Distributor
Warehouseback to its original value
11
12
13
ersonnel.
Test Summary

or row 65: NBB Role and Distributor Row should be updated with the different values inserted, no
to complete Test 3 to bring the values new row inserted
Warehouse. new row inserted

ed in Test 5 to bring data back to original Rows updated should be 1 and Rows deleted should be 1
onality.
r row 65: NBB Role and Distributor Should receive appropriate error message that this field cannot
of their current value. **Make sure to be a null value
r row 65: NBB Role and Distributor Row should be updated with the original values inserted, no
nal value new row inserted
Pass
Fail
NBBPersonnelKey = 65
y
y
y
y

Actual Results
Comments
Dimension Table: DimSyndicatedData
Tester's Name:
Description:
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Change the Type 1 fields for row 5: Dist Warehouse Key,
Syndicated Data Type, and Syn Region Name. **Make sure to
3 L New Change the Type 1 fields for 1 row back to the original values: Dist
Warehouse Key, Syndicated Data Type, and Syn Region Name.
5 H New Add new Syndicate Data Type.

7 H New Delete new Syndicate Data Type. added in Test 5 to bring data
back to original state and test delete functionality.
9
10
11
12
13
Test Summary

or row 5: Dist Warehouse Key, Row should be updated with the different values inserted, no
d Syn Region Name. **Make sure to new row inserted
for 1 row back to the original values: Dist Row should be updated with the original values inserted, no
ed Data Type, and Syn Region Name. new row inserted
ype. Rows updated should be 1 and Rows inserted should be 1

a Type. added in Test 5 to bring data Rows updated should be 1 and Rows deleted should be 1
est delete functionality.
Pass
Fail
SyndicateDataKey = 5
y
y
y
y
Actual Results
Comments
Dimension Table: DimCoreFlavor
Tester's Name:
Description: List of the current core flavors to be watched by warehouse.
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Change the Type 1 fields for row 16: Distributor Warehouse , Item,
Core Flag, and Grouping Name. **Make sure to complete Test 3
to bring the values back to the original**
Distributor Warehouse , Item, Core Flag, and Grouping Name.
5 H New Add new Core Flavor.

7 H New Delete new Core Flavor. added in Test 5 to bring data back to
original state and test delete functionality.

CoreFlavorKey, DistWarehouseKey, and ItemKey .
checked are: Core Flag, Grouping Name, and Agreggation Level.
12
13
be watched by warehouse.
Test Summary

or row 16: Distributor Warehouse , Item, Row should be updated with the different values inserted, no
Name. **Make sure to complete Test 3 new row inserted
to the original**
em, Core Flag, and Grouping Name. new row inserted

dded in Test 5 to bring data back to Rows updated should be 1 and Rows deleted should be 1
te functionality.
houseKey, and ItemKey .
rouping Name, and Agreggation Level.
Pass
Fail
CoreFlavorKey = 16
y
y
y
y

Actual Results
Comments
Dimension Table: DimDistPersonnel
Tester's Name:
Description: Brief description of the TableName table
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Change the Type 1 fields for row 20: VIP ID, Employee ID, District
Sales Manager, District Sales Rep, Employee Role. **Make sure to
3 L New Change the Type 1 fields for 1 row back to the original values: VIP
ID, Employee ID, District Sales Manager, District Sales Rep,
Employee Role.
5 H New Add new record with VIP ID, Employee ID, District Sales Manager,
District Sales Rep, Employee Role.
7 H New Delete new record added in Test 5 to bring data back to original
9 H New Duplicate ID Check for VIPID - VIP Number. This is a unique

number assigned by VIP to uniquely identify each outlet.
checked are: ParentKey, VIPID, Employee ID, District Sales
Manager, District Sales Rep, and Employee Role.
12
13
me table
Test Summary

or row 20: VIP ID, Employee ID, District Row should be updated with the different values inserted, no
les Rep, Employee Role. **Make sure to new row inserted
for 1 row back to the original values: VIP Row should be updated with the original values inserted, no
ales Manager, District Sales Rep, new row inserted
D, Employee ID, District Sales Manager, Rows updated should be 1 and Rows inserted should be 1
ee Role.
n Test 5 to bring data back to original Rows updated should be 1 and Rows deleted should be 1
onality.
PID - VIP Number. This is a unique These values should be unique and no duplicates.
o uniquely identify each outlet.
VIPID, Employee ID, District Sales
ep, and Employee Role.
Pass
Fail
DistPersonnelKey = 20
y
y
y
y

Actual Results
Comments
Dimension Table: DimDistWarehouseSalesRepMap
Tester's Name:
Description: Distributor Sales Rep mapping.
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Change the Type 1 fields for row 56: DistributorAccountKey, NBB
Personnel, NBB Role, Sales Manager, and Sales Rep. **Make
original**
DistributorAccountKey, NBB Personnel, NBB Role, Sales Manager,
and Sales Rep.
5 H New Add new record with NBB Personnel, NBB Role, Sales Manager,
and Sales Rep.
7 H New Delete new record added in Test 5 to bring data back to original

DistSaleRepMApKEy, DistWarehouseAccountKey,
NBBPersonnelMapKey, and NBBRoleKey.
checked are: SalesMgrKey and SalesRepKey.
12
13
Test Summary

or row 56: DistributorAccountKey, NBB Row should be updated with the different values inserted, no
es Manager, and Sales Rep. **Make new row inserted
o bring the values back to the
B Personnel, NBB Role, Sales Manager, new row inserted
Personnel, NBB Role, Sales Manager, Rows updated should be 1 and Rows inserted should be 1
n Test 5 to bring data back to original Rows updated should be 1 and Rows deleted should be 1
onality.
WarehouseAccountKey,
nd NBBRoleKey.
y and SalesRepKey.
Pass
Fail
DistSalesRepMapKey = 56
y
y
y
y

Actual Results
Comments
Fact Table: FactDailySales
Tester's Name:
Description: Actual daily sales from distributors to accounts (and chain accounts) at account by day by sku lev
Priority Status

1 H New Add new Daily Sale record and check that new record is added to Rows added should be 1 and Rows inserted sh
table and all required fields are populated from the appropriate
dimensions:
Sales Key, Item Key, Distributor Warehouse Key, Cleansed
Account Key, DistAccount Key, DateKey, NBBPersonnelKey,
FlavorKey, PackageKey, PackageTypeKey, ReleaseTypeKey,
CoreFlavorKey, PremiseKey, COTKey, Units, ce, bbl, hl, and Raw
Units.
3 H New For newly added record in Test 1 verify calculated value for case Value should be Units * conversion_ce
equivalent (ce)
4 H New For newly added record in Test 1 verify calculated value for barrel Value should be Units * conversion_bbl
equivalent (bbl)
5 H New For newly added record in Test 1 verify calculated value for Value should be Units * conversion_hl
hectoliter equivalent (hl)
6 H New Verify YTD calculations. Year to Date = Days this year since last reporte
7 H New Constraints: During constraint testing, the objective is to validate All contraints should be populated and unique.T
unique constraints, primary keys, foreign keys, indexes, and all created during the ETL Process.
Sales Key, Item Key, Distributor Warehouse Key, Cleansed
Account Key, DistAccount Key, DateKey, NBBPersonnelKey,
CoreFlavorKey, PremiseKey, and COTKey.
initialize the cursor (or working storage) after each record, there is a should be null. Compare to VIP source data.
checked are: Net Unit Price and Frontline Price.
9 H New Source to Target field-to-field data initialization load. Fields to check All values should be populated as they are not
are: Units, ce, bbl, hl, and original units. Null. Compare to VIP data source.
10
11
12
13
14
15
ses
n accounts) at account by day by sku level including pricing information
Test Summary
Total Pass 0
Total Fail 0
Total N/A 9

Rows added should be 1 and Rows inserted should be 1 Run the following SQL statement against NBB DW: To be added
y
Value should be Units * conversion_ce Run the following SQL statement against NBB DW: To be added
Lookup to the conversion table and multiple units by the conversion

factor for ce.
Value should be Units * conversion_bbl Run the following SQL statement against NBB DW: To be added

factor for bbl.
Value should be Units * conversion_hl Run the following SQL statement against NBB DW: To be added

factor for hl.
Year to Date = Days this year since last reported full month. Run the following SQL statement against NBB DW: To be added
All contraints should be populated and unique.These Keys are Run the following SQL statement against NBB DW: To be added
all created during the ETL Process.
should be null. Compare to VIP source data.
All values should be populated as they are not allowed to be Run the following SQL statement against NBB DW: To be added
Null. Compare to VIP data source.
Pass
Fail
Comments
Fact Table: FactMonthlySales
Tester's Name:
Description: Shows 100% of NBB network but only at the distwarehouse level by mo
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Add new Monthly Sale record and check that new record is added
to table and all required fields are populated from the appropriate
dimensions:
Monthly Sales Key, Item Key, Distributor Warehouse Key,
DistAccount Key, NBBPersonnelKey, DataStatusKey, Units, ce, bbl,
hl, and Raw Units.
3 H New For newly added record in Test 1 verify calculated value for case
equivalent (ce)
4 H New For newly added record in Test 1 verify calculated value for barrel
equivalent (bbl)
5 H New For newly added record in Test 1 verify calculated value for

Sales Key, Item Key, Distributor Warehouse Key, Date Key, NBB
Personal, and Data Status Key.
checked are: Manual Bad Data Flag.
8 H New Source to Target field-to-field data initialization load. Fields to check

are: Units, ce, bbl, and hl.
9
10
11
12
13
t only at the distwarehouse level by month.
Test Summary

cord and check that new record is added Rows added should be 1 and Rows inserted should be 1
elds are populated from the appropriate
Key, Distributor Warehouse Key,

sonnelKey, DataStatusKey, Units, ce, bbl,
n Test 1 verify calculated value for case Value should be Units * conversion_ce
n Test 1 verify calculated value for barrel Value should be Units * conversion_bbl
n Test 1 verify calculated value for Value should be Units * conversion_hl
raint testing, the objective is to validate All contraints should be populated and unique.These Keys are
y keys, foreign keys, indexes, and all created during the ETL Process.
or this dimension are:
ributor Warehouse Key, Date Key, NBB
s Key.
TL process: If the code does not re- All fields from original data where a Null value is expected
rking storage) after each record, there is a should be null. Compare to VIP source data.
l values may contain data from a previous
Data Flag.
ield data initialization load. Fields to check All values should be populated as they are not allowed to be
Pass
Fail
y

factor for ce.

factor for bbl.

factor for hl.

Actual Results
Comments
Fact Table: FactNonBuyPOD
Tester's Name:
Description: Non-Buy actual sales used for Points of Distribution (POD)
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Add new Non-Buy POD record and check that new record is added
to table and all required fields are populated from the appropriate
dimensions:
POD Key, Cleansed Account Key, Dist Warehouse Key, ItemKey,
DateKey, NBBPersonnelMapKey, CoreFlavorKey, PremiseKey,
COTKey, and Units.

POD Key, Cleansed Account Key, Distributor Account Key, Item
Key, Flavor Key, Package Key, Package Type Key, Release Type
Key, Date, NBB Personal, Core, Premise Key, and COT Key.
checked are: Units, Manual Bad Data Flag, and Aggregation Level.
5 H New Need to verify that Non Buys have no volume.
6
7
8
9
10
11
12
13
oints of Distribution (POD)
Test Summary

cord and check that new record is added Rows added should be 1 and Rows inserted should be 1
lds are populated from the appropriate
unt Key, Dist Warehouse Key, ItemKey,

PackageTypeKey, ReleaseTypeKey,
apKey, CoreFlavorKey, PremiseKey,
aint testing, the objective is to validate All contraints should be populated and unique.These Keys are
unt Key, Distributor Account Key, Item
Key, Package Type Key, Release Type
Core, Premise Key, and COT Key.
king storage) after each record, there is a should be null. Compare to VIP source data.
al Bad Data Flag, and Aggregation Level.
ys have no volume. For non buys Units field will be null.
Pass
Fail
y

Actual Results
Comments
Fact Table: FactPODGoal
Tester's Name:
Description: This stores the goals for Points of Distribution.
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Add new POD Goal record and check that new record is added to
dimensions:
POD Goals Key, NBBPersonnelMapKey, FlavorKey,
PackageTypeKey, ReleaseTypeKey, PackageKey, PremiseKey,
Dist Warehouse Key, CoreFlavorKey, DateKey, Item ID, and Goal.
3 H New Change the Type 1 fields for row added in Test 1: Goal. **Make
original**
Goal
7 H New Change the Type 1 field for row 20: Goal to Null instead of its
current value. **Make sure to complete Test 8 to bring the
8 H New Change the Type 1 field for row 20: Goal back to its original value

relationships. Contraints for this dimension are: POD Goals Key,
NBB Personal, Flavor Key, Package Key, Package Type Key,
Release Type Key, Premise Key,Premise Key, Distributor
Warehouse, Core Flavor Key, and Date Key.
checked are: Item ID and Aggregation Level.

are: Goal.
12
13
f Distribution.
Test Summary

and check that new record is added to Rows added should be 1 and Rows inserted should be 1
s are populated from the appropriate
onnelMapKey, FlavorKey,
eTypeKey, PackageKey, PremiseKey,
FlavorKey, DateKey, Item ID, and Goal.
or row added in Test 1: Goal. **Make Row should be updated with the different values inserted, no
o bring the values back to the new row inserted
new row inserted
r row 20: Goal to Null instead of its Should receive appropriate error message that this field cannot
e to complete Test 8 to bring the be a null value
al**
r row 20: Goal back to its original value Row should be updated with the original values inserted, no
new row inserted
r this dimension are: POD Goals Key,
, Package Key, Package Type Key,
e Key,Premise Key, Distributor
ey, and Date Key.
Aggregation Level.
eld data initialization load. Fields to check All values should be populated as they are not allowed to be
Pass
Fail
y
DPODGoalsKey = Key from Test 1
y
y
PODGoalsKey = 20

Actual Results
Comments
Fact Table: FactDistInventory
Tester's Name:
Description: Distributor Inventory
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Add new Distributor Inventory record and check that new record is
added to table and all required fields are populated from the
appropriate dimensions:
DistInventory Key,Dist Warehouse Key, DateKey, Unit Tallied,
Inventory Transaction Code, Units Delta from Last Talley, Quantity,
Quantity Units of Measure, Units, ce, bbl, hl, and RawUnits.
3 H New Change the Type 1 fields for row added in Test 1: Unit Tallied,
Inventory Transaction Code, Units Delta from Last Talley, Quantity,
Quantity Units of Measure, and Units.
original**

5 L New Change the Type 1 fields for 1 row back to the original values: Unit
Tallied, Inventory Transaction Code, Units Delta from Last Talley,
Quantity, Quantity Units of Measure, and Units.
7 H New For newly added record in Test 1 verify calculated value for case
equivalent (ce)
8 H New For newly added record in Test 1 verify calculated value for barrel
equivalent (bbl)
9 H New For newly added record in Test 1 verify calculated value for

relationships. Contraints for this dimension are: Distributor Key,
Item Key, Distributor Warehouse Key, and Date Key.
checked are: Inventory Transaction Code, Transfer Distributor
Name, Aggregation Level, From Date, and To Date.

are: Units, ce, bbl, hl, and Original Units.
13
Test Summary

ory record and check that new record is Rows added should be 1 and Rows inserted should be 1
ired fields are populated from the
rehouse Key, DateKey, Unit Tallied,

e, Units Delta from Last Talley, Quantity,
Units, ce, bbl, hl, and RawUnits.
or row added in Test 1: Unit Tallied, Row should be updated with the different values inserted, no
e, Units Delta from Last Talley, Quantity, new row inserted
and Units.
for 1 row back to the original values: Unit Row should be updated with the original values inserted, no
ion Code, Units Delta from Last Talley, new row inserted
f Measure, and Units.
Test 1 verify calculated value for case Value should be Units * conversion_ce
Test 1 verify calculated value for barrel Value should be Units * conversion_bbl
Test 1 verify calculated value for Value should be Units * conversion_hl
r this dimension are: Distributor Key,
house Key, and Date Key.
ansaction Code, Transfer Distributor
From Date, and To Date.
Original Units. Null. Compare to VIP data source.
Pass
Fail
y
DistInventoryKey = Key from Test 1
y
y

factor for ce.

factor for bbl.

factor for hl.

Actual Results
Comments
Fact Table: FactNBBShipments
Tester's Name:
Description: Tracks what is sold to the Distributor.
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Add new Distributor Shipment record and check that new record is
NBBShipmentsKey, ItemKey, DateKey, DistWarehouseKey,
SOPNumber, Net Units, and Price.
3 H New Change the Type 1 fields for row added in Test 1: SOPNumber, Net
Units, and Price
original**
SOPNumber, Net Units, and Price.

relationships. Contraints for this dimension are: Shipments Key,
Item Key, Date Key, and Distributor Warehouse Key.
checked are: SOP Number, Net Units, and Price.
9
10
11
12
13
utor.
Test Summary

ent record and check that new record is Rows added should be 1 and Rows inserted should be 1
ey, DateKey, DistWarehouseKey,

nd Price.
or row added in Test 1: SOPNumber, Net Row should be updated with the different values inserted, no
new row inserted
nd Price. new row inserted
r this dimension are: Shipments Key,
istributor Warehouse Key.
r, Net Units, and Price.
Pass
Fail
y
NBBShipmentsKey = Key from Test 1
y
y

Actual Results
Comments
Fact Table: FactAvailability
Tester's Name:
Description: Contains Availability by date of the flavors in a given geography. This da
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Add new Availability record and check that new record is added to
dimensions:
AvailabilityKey, Item Key, DistWarehouseKey,
ReplacementItemKey, Start Date, End Date.
3 H New Change the Type 1 fields for row added in Test 1:

original**
7 H New Verify period of availability.
8 H New Verify for a seasonal item that is not available for one month period
of availability.
9 H New Verify for a discounted item that is not available for one month
period of availability.

relationships. Contraints for this dimension are: Availability Key,
Item Key, and Distributor Warehouse Key.
checked are: ReplacementItemKey, Start Date and End Date.
12
13
he flavors in a given geography. This data is used strictly to validate the seasonals coming in
Test Summary

d and check that new record is added to Rows added should be 1 and Rows inserted should be 1
DistWarehouseKey,
rt Date, End Date.
or row added in Test 1: Row should be updated with the different values inserted, no
rt Date, End Date. new row inserted
rt Date, End Date. new row inserted
. For ItemKey = X where EndDate is not null check that the item
is visible for one month after the period of availability.
hat is not available for one month period Current month should be displayed.
m that is not available for one month Volume should not be displayed.
r this dimension are: Availability Key,
Warehouse Key.
tItemKey, Start Date and End Date.
e seasonals coming in from the distributors.
Pass
Fail
y
AvailabilityKey = Key from Test 1
y
y

Actual Results
Comments
Fact Table: FactOrders
Tester's Name:
Description: FactOrders captures order transactions at the order line item level. Thes
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Add new Distributor Order record and check that new record is
OrdersKey, DistWarehouseKey, ItemKey, DateKey, Units,
Distributor PO, and Price.
3 H New Change the Type 1 fields for row added in Test 1: Units, Distributor
PO, and Price.
original**
Units, Distributor PO, and Price.
7 H New Delete new Distributor Order added in Test 1.

relationships. Contraints for this dimension are: Orders Key,
Distributor Warehouse Key, Item Key, and Date Key.

are: Units, PO Number, and Price for Order.
11
12
13
actions at the order line item level. These are orders made by distributors but not yet shipped
Test Summary

record and check that new record is Rows added should be 1 and Rows inserted should be 1
eKey, ItemKey, DateKey, Units,
or row added in Test 1: Units, Distributor Row should be updated with the different values inserted, no
new row inserted
Price. new row inserted
er added in Test 1. Rows updated should be 1 and Rows deleted should be 1
r this dimension are: Orders Key,
y, Item Key, and Date Key.
d Price for Order. Null. Compare to GP data source.
ors but not yet shipped.
Pass
Fail
y
OrdersKey = Key from Test 1
y
y
OrdersKey = Key from Test 1

y

Actual Results
Comments
Fact Table: FactNBBInventory
Tester's Name:
Description: Contains record of NBB inventory. Calculate inventory basead on incom

inventory on a particular day is the sum of the deltas across time. Additionally, inven
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Insert new Inventory record and check that new record is added to
dimensions:
NBBInventoryKey, ItemKey, DateKey, and Units.
3 H New Change the Type 1 field for row 20: Units to Null instead of its
current value. **Make sure to complete Test 4 to bring the
4 H New Change the Type 1 field for row 20: Units back to its original value

relationships. Contraints for this dimension are: NBB Inventory Key,
tem Key, and Date Key.
are: Units.
7
8
9
10
11
y. Calculate inventory basead on incoming and outgoing counts. At any point in time, invento
deltas across time. Additionally, inventory is counted on a regular basis to account for error
Test Summary

y, DateKey, and Units.
r row 20: Units to Null instead of its Should receive appropriate error message that this field cannot
e to complete Test 4 to bring the be a null value
al**
r row 20: Units back to its original value Row should be updated with the original values inserted, no
new row inserted
r this dimension are: NBB Inventory Key,
Null. Compare to GP data source.
y point in time, inventory is not simply summed from the data because
sis to account for errors in deltas, shrinkage, or other discrepancies.
Pass
Fail
y
PODGoalsKey = 20

Actual Results
Comments
Fact Table: FactForecast
Tester's Name:
Description: For Business Plans and Forecasts.
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H New Insert new Forecast record and check that new record is added to
dimensions:
ForecastKey, ItemKey, FlavorKey, PackageKey,
PacckageTypeKey, ReleaseTypeKey, StateKey,
DistWarehouseKey, CoreFlavorKey, and DateKey.
3 H New Change the Type 1 fields for row added in Test 1: Business Plan
(BP) Shipments Preliminary, BP Depletions Preliminary, BP
Shipments Final, BP Depletions Final, Market Plan Goal, Monthly
Rolling Depletions, and Monthly Rolling Shipments.
original**

Business Plan (BP) Shipments Preliminary, BP Depletions
Preliminary, BP Shipments Final, BP Depletions Final, Market Plan
Goal, Monthly Rolling Depletions, and Monthly Rolling Shipments.

relationships. Contraints for this dimension are: Forecast Key, Item
Key, Flavor Key, Package Key, Package Type Key, Release Type
Key, State Key, DistWarehouseKey, CoreFlavorKey, and Date Key.
checked are: Business Plan Shipment Prelim, Business Plan
Depletions Prelim, Business Plan Shipment Final, Business Plan
Depletions Final, Market Plan Goal, Monthly Rolling Depletions,
and Monthly Rolling Shipments.
9
10
11
12
13
14
s.
Test Summary

vorKey, PackageKey,
seTypeKey, StateKey,
FlavorKey, and DateKey.
or row added in Test 1: Business Plan Row should be updated with the different values inserted, no
y, BP Depletions Preliminary, BP new row inserted
etions Final, Market Plan Goal, Monthly
onthly Rolling Shipments.
ents Preliminary, BP Depletions new row inserted
s Final, BP Depletions Final, Market Plan
etions, and Monthly Rolling Shipments.
y keys, foreign keys, indexes, and from the PROMO data source.
r this dimension are: Forecast Key, Item
Key, Package Type Key, Release Type
ouseKey, CoreFlavorKey, and Date Key.
king storage) after each record, there is a should be null. Compare to PROMO source data.
n Shipment Prelim, Business Plan
ss Plan Shipment Final, Business Plan
lan Goal, Monthly Rolling Depletions,
ments.
Pass
Fail
y
ForecastKey = Key from Test 1
y
y

Actual Results
Comments
Fact Table: FactFeaturesAdsDisplay
Tester's Name:
Description: Contains actuals and goals for Features, Ads, and Displays. Features an
Priority Status
High - H New
Medium - M Open
Low - L Closed

1 H new Source to Target field-to-field validation: Do the values in the source
fields match the values in the respective target fields? Verify
FeatureAdsDisplays records initial upload and check that new
record is added to table and all required fields are populated from
the appropriate dimensions:
FeatureAdsDisplayKey, ItemKey, FlavorKey, PackageKey,
PacckageTypeKey, PremiseKey, ReleaseTypeKey,
2 H new Verify FeatureAdsDisplays add new record is added to table and all
required fields are populated from the appropriate dimensions:
FeatureAdsDisplayKey, ItemKey, FlavorKey, PackageKey,
PacckageTypeKey, PremiseKey, ReleaseTypeKey,
3 M new Check that the updated row is in the audit tables
4 H new Change the Type 1 fields for row added in Test 2: Type of
Execution Event and Execution Goal.
original**
5 M new Check that the updated row is in the audit tables
6 L new Change the Type 1 fields for 1 row back to the original values:
Execution Event and Execution Goal.
7 L new Check that the updated row is in the audit tables
8 H new Constraints: During constraint testing, the objective is to validate

relationships. Contraints for this dimension are: FeatureAdsDisplay
Key, Item Key, Flavor Key, Package Key, Package Type Key,
PremiseKey, Release Type Key, DistWarehouseKey,
CoreFlavorKey, and Date Key.
9 H new Initialization During the ETL process: If the code does not re-
checked are: Type of Execution Event, Execution Goal, Execution
Actual, and Unit of Measure.
10
11
12
13
14
eatures, Ads, and Displays. Features and Ads to not map to an item - just like Forecast.
Test Summary

eld validation: Do the values in the source Record Count Validation: Rows updated should be X and Rows
he respective target fields? Verify inserted should be X. Where X = number of records in excel
ds initial upload and check that new spreadsheet 'AJWinterAle'.
d all required fields are populated from
s: Data Validation: All data in FactFeaturesAdsDisplay should
mKey, FlavorKey, PackageKey, appear the same as in the 'AJWinterAle' spreadsheet.
seKey, ReleaseTypeKey,
add new record is added to table and all Rows added should be 1 and Rows inserted should be 1
ed from the appropriate dimensions:
mKey, FlavorKey, PackageKey,
seKey, ReleaseTypeKey,
or row added in Test 2: Type of Row should be updated with the different values inserted, no
ution Goal. new row inserted
ution Goal. new row inserted
y keys, foreign keys, indexes, and from the AJWinterale data source.
r this dimension are: FeatureAdsDisplay
Package Key, Package Type Key,
e Key, DistWarehouseKey,
Key.
king storage) after each record, there is a should be null. Compare to AJWinterale source data.
ution Event, Execution Goal, Execution
e.
ust like Forecast.
Pass
Fail
y
FeatureAdsDisplayKey = Key from Test 2

y
y

Actual Results
Comments
Fact Table: FactSaleDay
Tester's Name:
Description: Determines Sales Day per Warehouse.
Priority Status
High - H
New
Medium - M Open
Low - L Closed

1 H New Verify FeatureAdsDisplays add new record is added to table and all
required fields are populated from the appropriate dimensions:
SaleDayKey, DateKey, Is Sale Day.
3 H New Change the Type 1 fields for row added in Test 1: IsSaleDay from
1/0 for y/n.
original**
IsSaleDay.

relationships. Contraints for this dimension are: SaleDayKey and
Date Key.

are: IsSaleDayFlag.
9
10
11
12
13
ouse.
Test Summary
Total Pass 0
Yet to be Tested

add new record is added to table and all Rows added should be 1 and Rows inserted should be 1
ed from the appropriate dimensions:
Sale Day.
w is in the audit tables Rows updated should be 1 and Rows inserted should be 1.
or row added in Test 1: IsSaleDay from Row should be updated with the different values inserted, no
new row inserted
new row inserted
y keys, foreign keys, indexes, and generated during ETL Process.
r this dimension are: SaleDayKey and
Null. Compare to GP data source.
Pass
Fail
y
SaleDayKey = Key from Test 1
y
y

Actual Results
Comments
NewBelgiumBeerDW MS 2008 Cube & Data Warehouse Test Cases
Fact Table:
Tester's Name:
Description:
Priority Status
High - H
New
Medium - M Open
Low - L Closed

1 H CUBE - Data Lifecycle: Location and Content Validation.
New
2 H DW - Data Lifecycle: Location and Content Validation.
New
3 H CUBE - Data Lifecycle: Distributor Restatements Validation.

Subsequent to the Last Full Reporting Month.
New
4 H CUBE - Data Lifecycle: Distributor Restatements Validation. Within

Current Reporting Month.
New
5 H Distributor Changes - Change in Distributor Ownership:

• Example: Distributor A Buys Distributor B, but Distributor B
remains open but changes name to Distributor A. As part of this
transaction, Distributor B’s product and territory remain the same.
New Distributor A services all of Distributor B’s former territory.
• NBB actions: Provide new distributor ID to distributor data vendor
and request that historical data Distributor B is converted to be part
of Distributor A’s history.
6 H Distributor Changes - Distributor Brand Acquisition:
• Example: Distributor A Buys Distributor B and Distributor B closes.
As part of this transaction, Distributor A absorbs all of Distributor
B’s product and territory. Distributor B’s warehouses closes and
product is transferred to Distributor A. Distributor A services all of
New Distributor B’s former territory.
• NBB actions: Provide new distributor ID to distributor data vendor
and request that historical data Distributor B is converted to be part
of Distributor A’s history.
7 H Distributor Changes - Distributor Merger:

• Example: Distributor A and Distributor B consolidate their business
into a single company.
New • NBB actions: Provide new distributor ID to distributor data vendor
and request that historical data be merged for distributor A and B.
8 H Distributor Changes - Partial Distributor Brand Acquisition:

• Example: Part of Distributor B’s territory for a given brand family is
transferred to Distributor A. Both distributors remain in business.
• NBB actions: Provide new distributor ID to distributor data vendor,
request that historical data for the part of distributor B be converted
New to Distributor A’s history and provide an outlet file for the transferred
accounts that includes zip codes.
9 H Segmentation/ Dimension - Lifecycle Segement: New Belgium has

three state & distributor segments related to lifecycle:
1. New Markets: Where distribution of NBB product less than 24
months from the current reporting month
2. Emerging Markets: Where distribution of NBB product began
New between 24 months and 48 months ago.
3. Established Markets: Where distribution of NBB product began
over 48 months ago.
10 H Segmentation/ Dimension - State Lifecycle Segement: Data

New Visibility Verification.
11 H Segmentation/ Dimension - Distributor Lifecycle Segement: Data

Visibility Verification.
New
12 H Distributor Warehouse Born on Date
As each distributor warehouse is added into the NBB cube, as a
function of new territory roll out or distributor change, a “Born On
Date” will be captured for the warehouse. This born on date will
enable queries for distributor warehouses with similar months of
New operation within new and existing territories. This field will not be
made available to Sales team users without permissions.
13 H Flavor/Package Lifecycle:
• New Flavor/Package: Flavor or Package that has been in
geography for less than 24 months.
• Emerging Flavor/Package: Flavor or Package that has been in a
geography for 24 months or greater and less than 48 months.
New • Established Flavor/Package: Flavor or Package that has been in
geography for 48 months or greater.
14 H Package, Release and Flavor Types:

• Package Type: Draft or Package
• Release Type: Seasonal, Lips of Faith
• Core Flavors: by Geography core flavors
New
15 H Conversions - Volumetric to Package Conversions & Volumetric to

Volumetric Conversions - validate auidt table properly records
changes.
New
16 H Availability Validation- Need to verify seasonal and discontinued
items changes occur properly.
New
17 H Distributor Reporting Status Labels - Verification.

Sell Days: Sell Days are defined as Monday through Friday, non-
holiday days that the individual distributor is open.
Non-Reporters: A distributor that is missing one or more “sell days”
of data.
New Restated Reports: Distributor reports modified after the original
monthly closing period.
Certified Report for the Month: Data for the given month has been
certified by the distributor brand manager.
18 H DimDisDate: Verify Calculations: 60 day last full month.

New

New

New
21 H DimDisDate: Verify Calculations: 13 week

New

New

New
24 H FactDailySales: Verify % Change Relative to Period Last Year

New calculations are accurate
25 H FactDailySales: Verify CE Change Relative to Period Last Year
New calculations are accurate
26 H FactDailySales: Verify 13 week trend calculations.
New

New

New
29 H New FactDailySales: Verify Preceding Period calculations.
30 H New
FactNonBuyPOD: Verify % Change Relative to Period Last Year
calculations are accurate
31 H FactNonBuyPOD: Verify CE Change Relative to Period Last Year
New
calculations are accurate
32 H FactNonBuyPOD: Verify 13 week trend calculations.
New

New

New
35 H New FactNonBuyPOD: Verify Preceding Period calculations.

36 H New FactNonBuyPOD: Verify Rate of Sale calculations.
37 H New FactNonBuyPOD: Verify % Physical Distribution calculations.
38 H New FactNonBuyPOD: Verify Ces associated with POD.
39 H New FactNBBInventory: Verify Units Delta calculations.
40 H New FactNBBInventory: Verify Running Delta Sum calculations.
41 H New FactForecast: BusinessPlanShipmentPrelim ces
42 H New FactForecast: BusinessPlanDepletionsPrelim ces
43 H New FactForecast: BusinessPlanShipmentFinal ces
44 H New FactForecast: BusinessPlanDepletionsFinal ces
45 H New FactForecast: MPTGoalVol ces
46 H New FactForecast: ForecastMonthlyRollingDepletions ces
47 H New FactForecast: ForecastMonthlyRollingShipments ces
48 H New FactForecast: %Actual versus Plan TY
49 H New FactForecast: %Actual versus Plan LY
50 H New FactForecast: EOM projection
51 H Chain Hierarchy - Ownership and Chain Name Validation. Need to
verify that chain SCD changes are made properly.
New
52 H Verify Fix File loaded properly.

New
53 H Verify Rollback of data works properly.
New
54
55
56
57
58
59
60
& Data Warehouse Test Cases
Test Summary
Total Pass 0
Yet to be Tested

cation and Content Validation. - Cube: There should only be up to 2 years of data from the
current month. History should have been updated to reflect
distributor consolidations and moves. If this is not true then this
test case should fail.
ion and Content Validation. - DW: Should contain data for up to 5 years from current month.
History for years 3 to 5 should not reflect distributor
consolidations and moves. If this is not true then this test case
should fail.
stributor Restatements Validation. Original data is being retained for audit trail reports. Revised
ll Reporting Month. reporting data should be available for display in the cube.
stributor Restatements Validation. Within Revised reporting data should be available for display in the
cube.
nge in Distributor Ownership: - Distributor A retains all of Distributor B's product/territory.

uys Distributor B, but Distributor B - Dist B's ID is removed and replaced with Dist A's ID.
name to Distributor A. As part of this - Dist B's name changes to Dist A.
product and territory remain the same. - Compare A's new quantity to ensure it includes B's former
Distributor B’s former territory. quantity.
w distributor ID to distributor data vendor
data Distributor B is converted to be part
ibutor Brand Acquisition: - Distributor A absorbs all of Distributor B's product/territory.
uys Distributor B and Distributor B closes. - Dist B warehouses should be updated as closed
Distributor A absorbs all of Distributor - Dist B's ID is removed and replaced with Dist A's ID
Distributor B’s warehouses closes and - Dist B history should now be apar tof Dist A history
stributor A. Distributor A services all of - Need to verify that Dist B Sales are now apart of Dist B Sales.
ory.
data Distributor B is converted to be part
ibutor Merger: - Dist B gets new ID

nd Distributor B consolidate their business - Check that Dist B's ID is removed
- Verify that Dist B's new sales matches B's old sales
data be merged for distributor A and B.
al Distributor Brand Acquisition: - For specific brand verify loss of historical sales for Dist B
tor B’s territory for a given brand family is equals new sales for Dist A
. Both distributors remain in business. - Verify that accounts move from Dist B to Dist A
w distributor ID to distributor data vendor,
for the part of distributor B be converted
nd provide an outlet file for the transferred
codes.
- Lifecycle Segement: New Belgium has - Need to check that Distributor segments show as new,
gments related to lifecycle: emerging, or established as appropriate:
distribution of NBB product less than 24 a. Verify new markets convert to emerging
porting month b. Verify emerging marktets convert to established
ere distribution of NBB product began c. Verify established markets remain as established
8 months ago. - Need to test and ensure that changes to different lifecycle is
here distribution of NBB product began only made when rolling over year from Dec 31.
- State Lifecycle Segement: Data State Distributor lifecycle segment will be the only market
lifecycle segment made available to the sales team.
- Distributor Lifecycle Segement: Data Distributor lifecycle segment will not be visible to sales team
users without permissions.
n on Date a. Sales user without appropriate permissions should not be
use is added into the NBB cube, as a able to see this date.
l out or distributor change, a “Born On b. Need to add new warehouse and ensure that 'Born on Date'
he warehouse. This born on date will is populated.
or warehouses with similar months of c. Need to check that when Dist A and Dist B merge where Dist
existing territories. This field will not be A Warehouse is now Dist B Warehouse that Dist B retains its
am users without permissions. original Born on Date.
- Need to check that flavor/package lifecycles age beyond 24

vor or Package that has been in and 48 months as new, emerging, or established as
months. appropriate:
e: Flavor or Package that has been in a a. Verify new flavor/package convert to emerging
or greater and less than 48 months. b. Verify emerging flavor/package convert to established
age: Flavor or Package that has been in c. Verify established flavor/package remain as established
or greater. - Need to test and ensure that changes to different lifecycle is
only made when rolling over year from Dec 31.
vor Types: a. Package Type - There should only be d'raft' or 'package'

ackage package types.
Lips of Faith b. Release Type - There should only be 'seasonal' or 'Lips of
phy core flavors Faith' release types.
c. Verify that a release type does not overlap multiple
categories.
d. Verify that a package type is only in one release type.
o Package Conversions & Volumetric to If changes are made the Conversion utility table then the Audit
validate auidt table properly records table should properly record (i.e track) what was changed.
d to verify seasonal and discontinued Seasonals:
erly. • If a seasonal item has been discontinued, replace the item
with the current seasonal item.
• If seasonal item’s ending availability date is greater than 3
months ago - flag the item.
• If seasonal item’s ending availability date is greater than 4
months ago - change flavor to reflect current month’s seasonal.
Discontinued Items:
• If discontinued item’s (not seasonal) ending availability is
greater than 3 months ago - flag the item.
us Labels - Verification. a. Verify that no sales happen on non-sell days

defined as Monday through Friday, non- b. Verify that distributors missing data on a sell day is
dual distributor is open. designated as a non-reporter
or that is missing one or more “sell days” c. Verify that changes made after already reported are noted, if
after month is closed.
utor reports modified after the original d. Verify that certified data works.
nth: Data for the given month has been

brand manager.
ations: 60 day last full month. Data displayed should be 60 days since last reported full month.
ations: 90 day last full month. Data displayed should be 90 days since last reported full month.
ations: 180 day last full month. Data displayed should be 180 days since last reported full
month.
ations: 13 week Data displayed should be 13 weeks rolling since last reported
full month
full month
full month
Change Relative to Period Last Year Need business rule/calculation
Change Relative to Period Last Year Need business rule/calculation
week trend calculations. Data displayed should be 13 weeks rolling since last reported
full month
full month
full month
ceding Period calculations. Need business rule/calculation
% Change Relative to Period Last Year Need business rule/calculation
CE Change Relative to Period Last Year Need business rule/calculation
3 week trend calculations. Data displayed should be 13 weeks rolling since last reported
full month
full month
full month
receding Period calculations. Need business rule/calculation

ate of Sale calculations. Need business rule/calculation
% Physical Distribution calculations. Need business rule/calculation
es associated with POD. Need business rule/calculation
Units Delta calculations. Need business rule/calculations.
Running Delta Sum calculations. Need business rule/calculations.
anShipmentPrelim ces Need business rule/calculations.
anDepletionsPrelim ces Need business rule/calculations.
anShipmentFinal ces Need business rule/calculations.
anDepletionsFinal ces Need business rule/calculations.
l ces Need business rule/calculations.
nthlyRollingDepletions ces Need business rule/calculations.
nthlyRollingShipments ces Need business rule/calculations.
sus Plan TY Need business rule/calculations.
sus Plan LY Need business rule/calculations.
tion Need business rule/calculations.
hip and Chain Name Validation. Need to The cube should have a table that shows current chain name
ges are made properly. and ownership structure as a reference to the user. This table
is supposed to be automatically updated for changes in the
ownership structure.
***NOTE: This testing is to be at the cube level. SCD Type 1
updates to individual fields is a part of the DimCleansedAccount
ETL test scripts and is not intended to be repeated here.
erly. For purposes of this testing look at the number of records in the
Fix File and compare to the number of records updated in the
ETL and verify they are the same.
rks properly. Pick a record you want to rollback to original values. A

successful test will provide the ability to restore to a historical
data view.
Pass
Fail
Run ETL and verify date range of data.
- Write appropriate query to change ownership of Dist B to Dist A.

- Write query to verify Dist B territory history is now a apart of Dist. A.
- Write appropriate query to change ownership of Dist B to Dist A, close
Dist B warehouses
- Write query to verify Dist B product/territory/sales history is now a apart
of Dist. A.
- Write appropriate query to change ownership of Dist B to Dist A, close

Dist B warehouses and sales
- Write query to verify Dist B product/territory/sales history is now a apart
of Dist. A.
- Write appropriate query to move brnad from Dist B to Dist A

- Write query to verify Dist Baccounts history for selected brand is now a
apart of Dist. A.
a. Write query to change new market to emerging, be sure to change

date of NBB product to be > 24 months but less < 48 if needed.
b. Write query to change emerging market to established be sure to
change date of NBB product to be > 48 mo if needed.
c. Write query to change establisehd market year to increment another
year such that it is still > 48 mo.
Run ETL and then using appropriate query ensure that only market
lifecycle segment data is displayed for a sales user.
Run ETL and then using appropriate query ensure that only market
lifecycle segment data is displayed for a sales user. Need to run two
queries. One with appropriate user permissions and one without the
appropriate user permsissions.
a. Run ETL and then using the appropriate query ensure Born on Date is
ony visible to appropriate sales users. Need to run two queries. One with
appropriate user permissions and one without the appropriate user
permsissions.
b. Run query to add new warehouse. Obtain DIstWarehouseKey and
check to ensure 'Born on Date' is populated correctly.
c. Run query to merge data for two warehouses. Then run different query
to verify Dist B retains is original Born on Date. Be sure to record the
original value of the Born on Date prior to merging the two Distributor
Warehouses.
a. Write query to change new flavor/package to emerging, be sure to

change date of NBB product to be > 24 months if needed.
b. Write query to change emerging flavor/package to established be sure
to change date of NBB product to be > 24 mo but < 48 mo if needed.
c. Write query to change establisehd flavor/package year to increment
another year such that it is still > 48 mo.
For expected results a - d queries will be established and recorded here.
Make a change to the Conversion utility table using a query and then
check the audit table for a new record. Run the following SQL statement
against the NBB DW: Select PrimarySourceDatabase,
PrimarySourceTableName, DestinationDatabase,
DestinationTableName, InsertStdRowCnt, UpdateRowCnt, PkgName
From AuditTableProcessing, AuditPkgExecution Where
y
Makes changes according to business process as listed in expected
results and then run appropriate query against FactAvailability table to
verify changes.
For expected results a - d queries will be established and recorded here.


*Need to pick a current record and a date to rollback to.

Actual Results
Comments

NewBelgiumDW Unit Test Scenarios

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

NewBelgiumDW Unit Test Scenarios

Загружено:

Авторское право:

Доступные форматы

NewBelgiumBeerDW MS 2008 ETL Framework

Dimension, Fact Table & Cube Testing Summary

% Pass Dimension Table Assigned To # Tests

% Pass Fact Table Assigned To # Tests

ID Priority Status Scenario Expected Result

Expected Result Testing Steps

ID Priority Status Scenario Expected Result

Expected Result Testing Steps

ID Priority Status Scenario Expected Result

Rows updated should be 1 and Rows inserted should be 1.

Row should be updated with the original values inserted, no

Should receive appropriate error message that these fields

Row should be updated with the original values inserted, no

All contraints should be populated and unique.

All fields from original data where a Null value is expected

1 new row should be added. InsertAuditKey should be

Run the following SQL statement against NBB DW: To be added

Run the following SQL statement against NBB DW: To be added

Run the following SQL statement against NBB DW: To be added

Run the following SQL statement against NBB DW: To be added

Run the following SQL statement against NBB DW: To be added

Run the following SQL statement against NBB DW: To be added

ID Priority Status Scenario Expected Result

Expected Result Testing Steps

ID Priority Status Scenario

Scenario Expected Result

ID Priority Status Scenario Expected Result

Expected Result Testing Steps

ID Priority Status Scenario Expected Result

Expected Result Testing Steps

ID Priority Status Scenario Expected Result

Expected Result Testing Steps

ID Priority Status Scenario

2 M New Check that the updated row is in the audit tables

4 L New Check that the updated row is in the audit tables

Scenario Expected Result

ID Priority Status Scenario

2 M New Check that the updated row is in the audit tables

4 L New Check that the updated row is in the audit tables

easonal or lips of death

Scenario Expected Result

ID Priority Status Scenario

4 L New Check that the updated row is in the audit tables

Scenario Expected Result

ID Priority Status Scenario

2 M New Check that the updated row is in the audit tables

4 L New Check that the updated row is in the audit tables

Scenario Expected Result

Run the following SQL statement against NBB DW: To be added

ID Priority Status Scenario

4 L New Check that the updated row is in the audit tables

use groupings called areas

Scenario Expected Result

Run the following SQL statement against NBB DW: To be added

ID Priority Status Scenario

2 M New Check that the updated row is in the audit tables

4 L New Check that the updated row is in the audit tables

8 L New Check that the updated row is in the audit tables

10 M New Check that the updated row is in the audit tables

12 L New Check that the updated row is in the audit tables

16 L New Check that the updated row is in the audit tables

18 M Check that the updated row is in the audit tables

outlet across US which is authorized to sell alcohol

Scenario Expected Result