Most at Risk Executables

SeaLights identifies the smallest set of application entry points that must be tested to guarantee coverage of every meaningful change in a release, eliminating both over-testing and under-testing.

---

What Is Most-at-Risk?

When a release changes SAP objects (programs, functions, tables) SeaLights traces those changes through the full dependency graph and identifies which used executables (transactions, APIs, Fiori apps) are genuinely exposed. This list is then optimized to the minimal set of impacted executables known as the Most-at-Risk list.

It satisfies two hard constraints simultaneously:

• Completeness: every impactful changed object is reachable through at least one most-at-risk executable.
• Minimality: the number of most-at-risk executables is as small as possible.

The result: an average 84% reduction in test scope with 100% coverage of impactful changes.

---

How It Works

Analysis runs in three sequential stages.

Stage 1 - Collect the Facts

SeaLights establishes two data sets:

• Used Executables: entry points (T-Codes, programs, APIs, Fiori apps) that real users have executed in the production system, sourced from the last 3 months of performance history. Executables never run in production do not qualify.
• Changed Objects: everything modified by the change: a transport, support pack, or custom development, read directly from the SAP change inventory.

Brand-new executable have no usage history. A new executable that has never run in production won't appear in the Used Executables set and would be invisible to this stage. The New/Changed Executable heuristic (see below) handles this case.

Stage 2 - Dependency Analysis

SeaLights navigates the full SAP object dependency graph, using table data and ABAP code scans, up to 10 dependency levels deep, finding every path between a changed object and a used executable.

Output:

• Impactful Changed Objects: changed objects with at least one path to a used executable. Objects with no such path carry no user-facing risk and are dropped.
• Impacted Executables: used executables with at least one path to an impactful changed object.

Why not just test all impacted executables? A single widely-used configuration table can have first-level dependencies on over 1,000 executables. Reporting all of them provides no prioritization — it's no better than "test everything." Stage 3 solves this.

Stage 3 - Most-at-Risk Optimization

SeaLights applies five heuristics in priority order to select the minimal set of impacted executables that satisfies both constraints. The first heuristic satisfied marks an executable as most-at-risk. If none apply, it is marked most-at-risk by default. Completeness is never sacrificed.

---

The Five Heuristics

Priority	Heuristic	Logic
1	Business Critical	Always marked most-at-risk when used, impacted, and registered in the Business Critical list — regardless of any other heuristic.
2	New / Changed Executable	Marks a brand-new changed object as most-at-risk even with zero production usage history, preventing new code from being silently skipped.
3	Depth	Prefers the impacted executable with the shortest dependency chain to the changed object. Closer = more directly exposed.
4	Functional Cost	Prefers executables whose SAP component hierarchy is closest to the changed object's component. A sales transaction is more meaningfully at risk from a sales-component change than a procurement transaction sharing only a distant technical dependency.
5	Usage	When depth and functional cost are equal, prefers the executable with the highest production usage count. Higher traffic means a larger blast radius from any defect.

---

Test Coverage - Hits, Gaps & Optimal Tests

SeaLights cross-references the Most-at-Risk list against every connected test repository and assigns each object a coverage status.

Status	Meaning	Action
Hit	A test covers this most-at-risk object.	Include it in the run.
Gap	No test exists.	Create one before the release is approved.

SeaLights also produces three test set views:

• All: every test that references any used exectuable.
• Covering: tests that cover at least one most-at-risk executable.
• Optimal: the smallest set that together covers every most-at-risk object, weighted by usage frequency. Typically 80–95% fewer tests than All.

---

Configuration

Parameter	Purpose
Business Critical Executables	CSV upload (TYPE, NAME columns). Executables listed here are always included in Most-at-Risk when used and impacted.

---

FAQ

What is the difference between "Impacted" and "Most-at-Risk"?

Impacted means a used executable has a dependency on at least one changed object. Most-at-Risk means SeaLights selected it as part of the minimal coverage set. Not all impacted executables become most-at-risk; if another executable covers the same changed object with a shorter dependency chain, the first is redundant and excluded.

Why would a heavily-used T-Code not appear in the Most-at-Risk list?

High usage alone is not enough. An executable only becomes most-at-risk if there is a dependency path to at least one impactful changed object. If the current release doesn't touch that T-Code's dependency chain, it won't appear.

What if one most-at-risk executable is reached by multiple changed objects?

SeaLights tracks all impactful changed objects per executable. A single test covering that executable exercises all of those changes simultaneously - a key driver of the overall test reduction ratio.