Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 4 of 5

Refresh resilience

18 min

Listen to this lesson

0:00 / 6:56

A refresh copies a source system, usually production, over a test system. For testers it is a gift: realistic volumes, current master data and real edge cases. For automation it is a reset button pressed by someone else. Everything the suite created is gone, number ranges jump to production's values, and some configuration may differ from what was transported. Contoso refreshes CMQ from production several times during the program, and after the conversion, the Wave 2 load of Alternadores del Norte into company code 1910 adds thousands of new records the suite has never seen.

Discover, do not remember

The core rule is simple: a test should find the data it needs at run time by its characteristics, not by a key someone wrote down. Instead of "customer 1000123", the test asks for "a customer in sales area 1710 / 10 / 00 with no posting or sales block, with a credit limit above the order value, tagged as automation-owned". Instead of "material CMC-ALT-100 in plant 1710", it checks that the material exists, is extended to the plant and sales organization, and has stock, and fails clearly if not.

After a refresh, discovery still works because the test asks for characteristics, not for a key someone wrote down.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-302
  1. Does the test create this record itself?Yes → use the key returned by the API · No → continue
  2. Is it stable reference data (plant, sales area, company code)?Yes → use the configured value and verify it exists at run start · No → continue
  3. Is it a named showcase record (CMC-ALT-100)?Yes → look it up and check its required attributes · No → continue
  4. Is it consumable or state-dependent?Yes → reserve from a pool by criteria · No → discover by query with clear criteria
Deciding how a test obtains each piece of data.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-302

Number ranges after a refresh

SAP assigns document numbers from number range intervals. After a copy, the test system continues from the source system's current number level, so any document number a script remembered may now belong to an unrelated production document, or not exist. Number ranges can also be buffered in main memory: SAP's documentation on the number range buffer notes that buffered numbers lost on a rollback or server shutdown create gaps, and that numbers may not be issued in strictly ascending order. Tests must therefore never compute the next document number or assume consecutive numbers; they read the number from the response or the success message.

Preparing for the refresh

Refreshes are planned events, so the automation should have a runbook for them. Sam, the Basis lead, already runs post-copy steps such as converting logical system names with transaction BDLS and adjusting RFC destinations in SM59 so the copy does not talk to production partners. The automation team adds its own steps to the same plan.

  1. T-5 daysAnnounceBasis publishes the refresh window; automation pauses scheduled runs for it.
  2. T-1 dayExportExport anything worth keeping that only lives in CMQ, such as data factory settings and test user lists.
  3. RefreshCopy and post-copyBasis copies, converts logical systems, fixes destinations and locks production-only jobs.
  4. T+1Re-seedRecreate test users, roles and automation-owned master data; rebuild pools to target.
  5. T+1Smoke runRun a short smoke suite that checks connections, users and key reference data.
  6. T+2Full regressionResume the nightly suite; compare failure rate with the last pre-refresh run.
An automation runbook aligned with a system refresh.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-302

Seeding scripts

The re-seed step only works if it is scripted. Keep a seeding script, run by the pipeline, that creates every automation-owned record that is too expensive to create per test: the test customers with their credit settings, the test suppliers with bank data placeholders, the protected product set and the initial stock pools. Make it idempotent: running it twice should not create duplicates, because it first looks for existing records by their tags and only creates what is missing.

  • Look up automation-owned records by tag; create only what is missing.
  • Read back every created key and write it to a run log, never to the scripts.
  • Validate the result: each seeded object has the attributes tests rely on.
  • Run the seed on demand and after every refresh or client copy.
An idempotent seed run can be repeated safely: it creates only what is missing and validates everything it relies on.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-302

What would you do?

After Sam refreshes CMQ from production, 60 of Priya's 180 tests fail. Most errors mention customers or documents that do not exist. What should the team change so the next refresh is uneventful?

Key points
  • Discover data at run time by characteristics; never rely on remembered keys.
  • Refreshes reset number ranges and data, and buffered ranges can leave gaps.
  • Never assert on or compute document numbers; read them from the response.
  • Align an automation runbook with the Basis refresh plan: pause, re-seed, smoke, resume.
  • Seeding scripts must be idempotent and include test users and technical users.

Check your understanding · not graded

Lesson check

  1. 1. Which approach makes a test resilient to a refresh of CMQ from production?

  2. 2. Why should a test never compute the next document number?

  3. 3. What does it mean for a seeding script to be idempotent?

  4. 4. After a refresh, which automation-owned objects must the idempotent seed recreate?