Define Activities – Data

What does our test scope consist of (Part Two), and how will we be creating those deliverables?

  1. Preparation Plan
  2. Test Strategy
  3. Scenarios, Checklists, and Charters
  4. Data
  5. Execution Schedule
  6. Human Resources
  7. Communication
  8. Procurement
  9. Readiness
  10. Test Execution
  11. Close Project or Phase


The second part of our scope consists of data. By “Data” we mean master data (for example Customers, Vendors, and Materials), some historical transactional data (for example stock loads) and transportable configuration data (for example Plants and Routes). We need to identify as much as possible what data we will use in our test execution, for the following reasons:

  • We can minimise the amount of effort required in setting up scenarios by adding in additional data sets. For example, we can set up a single standard Sales -> Delivery -> Billing scenario but run it multiple times by using different Sales Areas, Customers, and Materials. The multiple iterations directly impact our schedule and the required testers.
  • In SAP projects we frequently piggy-back on the Data team’s trial loads for integration and user acceptance testing; however, those data loads are also frequently incomplete or partial, so we need to be able to clearly identify the data that we want to use for testing to ensure that it is both included in the data load and is correct. Be wary of Data teams that announce that they will load (for example) 80% of data and that that should be okay for UAT – do they mean 80% of the data objects will be loaded? Or 100% of objects and 80% of data within each object? Is the 80% consistent with each other across objects, so that the Sold To, Ship To, Bill To, Payer, Material, Routes, CMIR, and Pricing is all consistent?

It’s very possible that at the point in time that we need to identify data, the business and the project do not yet know what some of the new SAP object IDs are. In these cases we should identify legacy values and trace these in the load files, so that we have as complete a picture as possible of our data requirements.

The results of our data planning should be fed back to the Data team for them to validate that the data we need is included in their load files. Any gaps will need workarounds (usually either change the data set required, or manually load and fix if there is no alternative).

At all times we need a contingency plan – what will we do if the data load is incomplete or if critical objects fail to load?


Previous Page - Define Activities - Scenarios, Checklists, and ChartersNext Page - Define Activities - Execution Schedule