Breaking the Surface UAT Testing Process and Documentation

Breaking the Surface! UAT Testing Process and Documentation for SAP Business Objects Sara Allen Associate Director Of Analytics July 8 th, 2013

UAT-User Acceptability Testing Process Overview • • Data Prep Data validation Joins BO Attributes Changes Critical Dates Report Validation Misc. Test https: //www. mtholyoke. edu/datawarehouse/documents-and-templates

Overall Use of the Document: • Tabs number correlate with the Test Case o • • Example: 400 correlate with Critical Dates Test Case Home Page: Date Tested and Sign offs- List the Names of all the testers Test Cases: o Test ID numbers for each item Example 100 -1 o List the Query criteria when applicable o List the expected results o PASS/FAIL o Retest Date o Comments- start with the date- then your comment-your initials. • Example: 7/1/12 - Smith was listed instead of Jones-SA

Data Prep – Regroup and really think through what we have. • Circle back to the Data Inventory - do we have what we need? anything we don't? • • • Naming Organization (in universe) Domain validation - do the attribute names describe the values in the data • Data types, Format

• Data validation (100) – This test case validates all of the data attributes and ensures that those data elements are displaying the correct values and the correct format, examples; mm/dd/yyyy, $, commas, text vs. numeric. Is everything there that we need?

• Joins (200) - This test case validates how the data elements are joined with the tables at the source level. How are the attributes are joined/ fit together and what is the query criteria.

• Counts and BO Created Attributes (300) - This test case validates that all the counts are counting accurately and that all attributes created only in BO function as defined in the requirements. Essentially testing the measures created by the Data Architect and validate the query criteria behind them.

• Changes (400) - Tests the changes to the source system and how they are reflected in BO. Tests that all "track" data elements defined in the requirements, are actually tracking the history. This test case is testing how new data is introduced, which in essence is tracking the business process. We want to see how the data is populated, refreshed and tracked.

• Critical Dates (500) Testing that all critical dates and/or snapshots function as they should. Testing a point in time.

• Report Validation (600) - Reconcile reports run from the core system against reports created and produced in BO. • Misc. Test (700) - Any misc. test scenarios determined to test during UAT

Looking Ahead • What’s Next? Universe will go into Production/Swan. Tidbits of advice to make testing less painful: • • • Ask for help Patience is a virtue Communication is a must THANK YOU! Power. Point presentation is saved on AMBR under datawarehouse>users-group.