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

Lesson 3 of 5

How changes arrive: transports and import status

8 min

Listen to this lesson

0:00 / 15:09

Configuration and code move between SAP systems in transport requests. A consultant changes a pricing procedure in development; the system records the change in a request. When the work is ready, the request is released. The Basis or release team imports it into QAS, and later, after testing and approval, into production. The tooling is SAP's Change and Transport System, administered through the Transport Management System (STMS).

Two kinds of request

  • Customizing requests record client-specific customizing made in one source client, such as Contoso's sales document types or pricing procedure.
  • Workbench requests record repository objects (programs, enhancements, dictionary objects) and cross-client customizing. Their effect is not limited to one client.
  • Each request holds one or more tasks, one per person who worked on it. Tasks are released first, then the request.
  • Requests are viewed and managed in the Transport Organizer, transactions SE09 and SE10.
  1. Day 1Change recordedConsultant fixes the tax code in DEV; request recorded with the change
  2. Day 1Unit tested and releasedConsultant checks it in DEV, releases task and request
  3. Day 2Imported to QASRequest lands in the QAS import queue and is imported into client 100
  4. Day 2–3Confirmed and regressedTester re-runs the failed case and related regression, recording the request number
  5. Release dateImported to PRDAfter approval, the same request is imported into production with the release
The life of one transport request from fix to production.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-102

Why import status matters

A test result is only meaningful for a known set of imported changes. If a defect fix is released in DEV but not yet imported into QAS, re-testing it in QAS will fail and the defect looks unfixed. If ten transports were imported between Monday's run and Wednesday's run, a test that failed Monday and passed Wednesday may have been fixed by any one of them, or broken again by another.

Order matters too. Transports are generally imported in the sequence they sit in the import queue. If transport B depends on an object created in transport A and B is imported first, it can fail with errors, or worse, appear to import while the dependent configuration is incomplete. Release managers watch for these dependencies; testers notice them as strange failures right after an import.

Customizing transports also have a quirk worth knowing: unlike workbench objects, customizing entries are not locked to one request. Two consultants can record different values for the same table entry in two requests, and whichever is imported last wins. If a setting that worked yesterday is back to an old value today, compare the recent imports for the same object before assuming someone broke it on purpose.

  1. MondayRequest A recordedConsultant 1 sets the fleet pricing procedure entry to value X
  2. TuesdayRequest B recordedConsultant 2 sets the same entry to value Y for a different reason
  3. WednesdayB imported into QASTests run with value Y and pass
  4. ThursdayA imported into QASValue X now wins; yesterday's passing test fails
Customizing entries are not locked to one request, so whichever transport is imported last sets the value you test.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-102

Recording the baseline

Good test evidence states the build or transport baseline it was run against: the date of the last import, the release or wave identifier, or the specific transport numbers for a fix. Many programs bundle transports into numbered builds imported at set times, which makes the baseline easy to record. For a defect retest, always record the request that carried the fix.

Some changes do not travel by transport at all. Master data such as business partners and products, condition records in many setups, number range intervals in some projects, and settings flagged as current settings that can be maintained directly in each system all change outside the transport path. Your baseline therefore has two parts: the transports imported and the data state of the client. Note both.

Software releaseFor example SAP S/4HANA 2025 with its support package stack
Transport baselineIntegration build 7, or the specific fix transports imported
Data maintained in the systemBusiness partners, products, condition records, number ranges
Client data stateRefresh date and test data created since
A complete test baseline has layers: the release, the transports, and the data that changes outside the transport path.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-102
Evidence itemContoso example
System and clientS/4HANA QAS, client 100
BaselineIntegration build 7, imported Tuesday 06:00
Fix transport for retestCustomizing request for the tax code fix, import confirmed in STMS
Data refreshQAS refreshed from a production copy four weeks ago

Landscape facts every test run and retest should record.

What would you do?

A developer tells Priya that defect 214 is fixed and the transport is released. Priya re-runs the test in QAS client 100 and it still fails. What should she check first?

Key points
  • Changes move DEV → QAS → PRD in transport requests, managed through STMS.
  • Customizing requests carry client-specific settings; workbench requests carry repository objects and cross-client customizing.
  • A test result is valid only for a known set of imported transports.
  • Record the baseline in every test run, and the fix transport in every retest.
  • Reconcile the release's transport list with what was in QAS when tests ran.

Check your understanding · not graded

Lesson check

  1. 1. Which type of transport request records changes to ABAP programs?

  2. 2. A fix is released in DEV but not imported into QAS. What happens if you retest in QAS?

  3. 3. Which transaction is used to manage import queues across the landscape?

  4. 4. Why record the transport baseline in test evidence?