Lesson 3 of 5
Refreshes, copies and number ranges
9 min
Listen to this lesson
Test data does not stay put. Systems are refreshed from production, clients are copied, and number ranges move on independently of what testers expect. Each of these events can make yesterday's data plan useless. This lesson explains what each event does so you can plan around it.
System copy versus client copy
A system copy (often called a refresh) replaces an entire system, for example QAS, with a copy of another, usually production. Everything is overwritten: all clients, all data, all configuration and all repository objects. Any transports that were imported into QAS but not yet into production are gone and must be re-imported. Test users, test data and in-flight test documents disappear unless they are exported first and restored afterwards.
A client copy copies one client's data into another client, inside the same system (a local copy) or from another system (a remote copy). What is copied depends on the copy profile. For example, SAP_ALL copies all client data except change documents and local data, SAP_CUST copies client-specific customizing and removes application data, and SAP_USER copies only users, roles and authorization profiles. Every profile except SAP_USER deletes the target client's existing customizing and application data first.
| Event | Scope | What testers lose | What testers gain |
|---|---|---|---|
| System copy (refresh) PRD → QAS | Whole system | Test data, test users, transports not yet in PRD, in-flight documents | Realistic, current master and transactional data |
| Client copy with SAP_ALL | One client | Everything in the target client | A full copy of the source client's data |
| Client copy with SAP_CUST | One client | Application data in the target client | Clean customizing; data must be created or loaded |
| Client copy with SAP_USER | Users only | Nothing else | User master records and roles from the source |
Planning around a refresh
- T-10 daysAnnounceTell testers the refresh date; freeze new test data creation
- T-5 daysInventoryList transports in QAS but not PRD; export test users and roles; record reusable test data sets
- T-0CopyBasis copies PRD to QAS; personal data is scrambled before testers get access
- T+1 dayRestoreRe-import pending transports; restore test users; adjust number ranges and interfaces
- T+2 daysVerifyRun a smoke test and data readiness checks before reopening testing
Interfaces deserve special attention. After a refresh, QAS holds production's partner configuration and connection settings until Basis changes them. A copied system that still points at a production partner can send real messages. Post-copy steps that redirect or deactivate connections are part of every refresh runbook; as a tester, ask to see them done before you run interface tests.
Background jobs need the same care. Production's job schedule is copied with the system, so a refreshed QAS can start output, payment or interface jobs that nobody planned. The usual runbook suspends released jobs during the copy and reviews them before release. If a test depends on a scheduled job, such as a nightly billing run, confirm it was restored with the right variant and user.
Number ranges that confuse tests
Every document number comes from a number range interval, assigned to a number range object (maintained in transactions such as SNRO, or the application's own maintenance transaction). Number ranges cause three kinds of test confusion:
- Gaps and order. Many number range objects are buffered in application server memory for performance. Each server reserves a block of numbers, so numbers can skip and are not always assigned in creation order. A test that expects sales order 1000458 straight after 1000457 is testing the wrong thing.
- Refresh collisions. After a refresh, QAS number range status matches production at the time of the copy. Document numbers that testers wrote down before the refresh may now belong to different, production-copied documents.
- External numbering. Some objects, such as products or business partners in some setups, use externally assigned numbers. A test data script that reuses the same number fails the second time because the number already exists.
What would you do?
Luis, Contoso's cutover manager, plans a QAS refresh from production the week before Priya's regression cycle. Which preparation matters most for the test team?
- A system copy overwrites a whole system, including transports not yet in production.
- A client copy's effect depends on its copy profile; most profiles wipe the target client first.
- Re-import pending transports, restore test users and redirect interfaces after every refresh.
- Buffered number ranges can skip numbers and assign them out of order; never assert exact next numbers.
Check your understanding · not graded
Lesson check
1. What happens to transports imported into QAS but not yet into production when QAS is refreshed from production?
2. Which client copy profile copies only users, roles and authorization profiles?
3. Why can document numbers skip or appear out of creation order?
4. Why must interfaces be checked immediately after a production-to-QAS copy?