SAP Transport Testing Checklist Before Release

Decision context

Testing a transport is two different jobs. Before release you are testing the request: is it complete, is it self-contained, does it depend on anything that is not going with it. After import you are testing the change: did the objects arrive, did they activate, does the process still work.

Most teams do the second job and skip the first, which is why the most common production incident from a transport is not a bug in the code. It is an object that was never in the request.

Adranum's part is the dependency and coverage side: which objects the change touches, what depends on them, which tests intersect that set, and what those tests returned against this exact package.

Before release: is the request complete

This is the check that catches the incident. Every item here is answerable in the development system before anything leaves it.

• Object list reviewed against what actually changed, not against what the developer intended to change.
• Dictionary objects, their dependent structures, and any table entries the code needs are all in the request or already in the target.
• Configuration in a customizing request that the workbench code depends on is identified, and the import order between the two is decided.
• Number ranges, variants, authorization objects, roles, output configuration, and text elements are checked. These are the categories most often left behind.
• No object is still assigned to an open task belonging to someone else's work in progress.
• The request contains no objects from an unrelated change, which is what makes a reversal impossible later.
• A deletion in the source is represented as a deletion in the request rather than as an object that simply stopped being included.

Before release: what breaks if this is wrong

Ordering and reversibility are decided before release, not after. Both are cheap to establish now and expensive to establish later.

• Sequence. Which other released or unreleased requests touch the same objects, and what order the target needs.
• Reversibility. What reverses this request. For most repository changes a corrective transport, for dictionary and data changes frequently nothing, which is a fact worth knowing before rather than after.
• Impact. Which programs, interfaces, and processes read the changed objects, and which of them are covered by a test.
• Coverage gaps. Which impacted paths have no test at all. A named gap is a decision, an unnamed one is a surprise.

After import: did the change land

A return code of 0 means the import mechanism worked. It says nothing about whether the change is correct or complete.

• Return code checked per phase, not only in aggregate.
• Objects confirmed present and active in the target, particularly dictionary objects and anything that had to be generated.
• The functional test executed in the target, against the imported version, by someone other than the developer.
• Interfaces and background jobs that touch the changed objects checked, because these are the paths a user-driven test never exercises.
• Authorizations verified with a real user rather than a wide test account, which is where a change looks fine and then fails for the business.
• Performance sanity checked when the change touches a selection, an index, or a frequently executed path.
• The result recorded against this package identity, so a later change to the request does not inherit the approval.

What the workflow must cover

• Completeness analysis. Compare what changed against what the request contains, and name the categories most often left behind.
• Dependency and order. Identify the objects other requests also touch and derive the required import order from evidence rather than release time.
• Test selection. Select the tests whose components, interfaces, or process paths intersect the changed objects, and expose the paths with no coverage.
• Result binding. Bind each result to the package that produced it, so a modified request loses its earlier approval automatically.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Review the object list against the actual change in development.
2. Resolve dependencies, sequence, and reversibility before release.
3. Release and import, then read the return code per phase.
4. Execute the selected tests in the target against the imported version.
5. Record results against the package identity and close or block the release.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Object list review
• Missing-category check
• Dependency and overlap report
• Reversal plan or explicit note that none exists
• Return code per phase
• Object activation state in target
• Test results bound to the package
• Named coverage gaps

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• No analysis proves a request is complete. It narrows the categories where incompleteness usually hides.
• Dynamic calls, generated code, and configuration read at runtime are not fully inferable from a static object list.
• Reversibility is a property of the change. Some dictionary and data changes have no reverse transport, and saying so is the honest answer.

Buyer checklist

• Was the object list reviewed against what actually changed?
• Which categories were checked for missing objects?
• What reverses this request, and has that been tested?
• Which impacted paths have no test?
• Are the recorded results bound to this exact package?