For the complete documentation index, see llms.txt. This page is also available as Markdown.

Reviewing Change Analysis Results

The Change Analysis tab is the first output produced after a test cycle is created. It answers the question: what changed and what is at risk? It shows how many SAP functional areas were touched, how many executables are affected, which are ranked most-at-risk, and the total count of changed ABAP objects — all derived from structural analysis before a single test runs.


Business Value & Key Use Cases

  • Pre-test risk briefing — Release managers understand the scope and concentration of risk before testing begins, enabling informed decisions about priorities and resources.

  • Stakeholder communication — The downloadable report provides a shareable impact summary in business terms, without requiring stakeholders to interpret raw ABAP object names.

  • Transport validation — Teams verify that the transports in scope match what was expected — catching missing or unexpected transports before the test run starts.


Detailed Functionality

The Four Metrics

Metric
What It Measures

App Areas

SAP functional modules (e.g., Finance, Purchasing) containing at least one impacted executable

Impacted Executables

All executables that depend on at least one changed object in the cycle's transports

Untested Changes

Total ABAP objects modified across all transports in scope, and not tested yet

Total Changes

Total ABAP objects modified across all transports in scope

The relationship between these numbers tells the real story. A high Impacted count with a low Most-At-Risk count means changes are broad but concentrated in lower-risk areas. A high Most-At-Risk count signals that changes landed in high-stakes executables and warrants careful attention.

How the Analysis Is Built

The tab is produced entirely through structural analysis — no execution history is needed:

  1. SeaLights reads the list of changed ABAP objects from the cycle's transports via SAP metadata tables (no source code accessed)

  2. Changed objects are mapped to the production-active executables that depend on them

  3. Those executables are ranked by the five risk heuristics to identify the most-at-risk set

This runs automatically within minutes of cycle creation.

Downloading the Analysis

The full export includes impacted executables, their risk rankings, the changed objects they depend on, and the app areas they belong to. It is formatted for sharing with stakeholders who do not have SeaLights access, and for archiving independently of the platform.


FAQ

Q: The Most-At-Risk count is much lower than Impacted Executables. Is something missing? A: No — this is expected. The Most-At-Risk set is a curated subset filtered by the risk heuristics. Many impacted executables are deprioritized because they are low-usage, functionally unrelated to the change, or have long dependency paths to the changed object.

Q: The Changed Objects count is higher than expected. Why? A: Transport packages — particularly support packs and third-party add-on upgrades — often contain more objects than their label suggests. The count reflects everything the transport touched, not only custom Z-objects.

Q: Does the analysis update if new transports are imported after the cycle is created? A: No. The transport scope is fixed at cycle creation. To include new transports, create a new cycle using Carry Over.

Last updated

Was this helpful?