Most-At-Risk Ranking
Core Capability
Not all impacted executables carry equal risk. Most-At-Risk Ranking takes the full set of executables surfaced by the dependency map and applies five heuristics — in priority order — to rank them from highest to lowest risk. The output is the Most-At-Risk set: the executables that most urgently need test coverage in this cycle. This ranked list drives both the test recommendations in Step 3 and the coverage reporting throughout the cycle.
Interface Experience and Navigation
The Most-At-Risk Executables count is surfaced in the Change Analysis tab as one of the four headline metrics. The ranked list itself drives the Tests to Run tab — the tests recommended are those that cover the most-at-risk executables, not the full impacted set. There is no separate ranking view in the UI; the ranking is expressed through the test recommendations and coverage outputs.
Business Value & Key Use Cases
Testing what matters, not everything — The impacted executable count in a large release can run into the hundreds. Testing all of them exhaustively is neither feasible nor necessary. The Most-At-Risk set identifies the subset where test coverage is genuinely critical, so effort is concentrated where it matters most.
Objective prioritization — Risk ranking is based on defined, consistent heuristics rather than individual judgment or tribal knowledge about which programs are "important." Every team, on every cycle, applies the same logic.
Business-critical process protection — The highest-priority heuristic allows teams to permanently flag their most critical executables so they are always prioritized regardless of where the change landed in the dependency chain.
Impact Metrics
In a cycle with hundreds of impacted executables, Most-At-Risk Ranking typically reduces the test-relevant set to a fraction of the full impacted count — without dropping any genuinely high-risk executable from the recommendation. The result is a test list scoped to real risk, not worst-case surface area.
Detailed Functionality
The Five Heuristics
Heuristics are applied in priority order. A higher-priority heuristic always outweighs a lower one — an executable ranked up by heuristic 1 is not demoted by heuristic 5.
1. Business Criticality
Executables that have been manually flagged as business-critical are always included in the Most-At-Risk set when they appear in the dependency map — regardless of how they score on any other heuristic. This is the team's override: if a process is mission-critical, it is always prioritized.
Business-critical executables are uploaded and managed directly in the product. This list is persistent across cycles — it does not need to be re-entered per cycle.
This is the only heuristic that teams can configure. All others are determined by SeaLights automatically.
2. New or Changed Executable
If the executable itself is brand-new or was directly modified by one of the cycle's transports, it is treated as high risk regardless of usage history. New objects have no established behavior baseline and no prior test evidence — they are unknown quantities by definition.
3. Dependency Depth
The closer an executable sits to the changed object in the dependency graph, the stronger the risk signal. An executable that directly calls a changed function module is ranked higher than one that reaches the same object through three intermediate layers. Shorter dependency paths mean the change has a more direct and likely impact on that executable's behavior.
4. Functional Relevance
Executables that belong to the same SAP functional module as the changed object — or a closely related one — are ranked higher than executables in unrelated modules. A change in a Purchasing object is more likely to affect Purchasing and Materials Management executables than Finance ones. This heuristic reduces false positives from distant cross-module dependencies.
5. Usage Frequency
Among executables that score similarly on the first four heuristics, the one used most frequently in production is ranked higher. High-usage executables affect more users and more business processes — a failure there has a broader blast radius than a failure in a rarely-used program.
The Most-At-Risk Set in Practice
The five heuristics together produce a ranked list where the top entries are executables that are: flagged as critical, or newly changed, or directly dependent on the changed object, or functionally adjacent to it, or heavily used in production — and typically some combination of all of these. These are the executables that warrant verified test coverage before the release proceeds.
The rest of the impacted executables — those ranked lower — are not ignored. They still appear in the Impacted Executables count in the Change Analysis tab. But they are not prioritized in the test recommendations, because the structural and contextual signals suggest their risk in this specific cycle is lower.
FAQ
Q: How do we flag an executable as business-critical? A: Business-critical executables are uploaded as a list and managed directly in the SeaLights product. The list is persistent and applies to all future cycles on the connected landscape. [Configuration detail pending validation — specific upload format and management UI steps for the business-critical list, available in Service Pack 2.]
Q: Can we adjust the weight or order of the five heuristics? A: No. The heuristic priority order is fixed. The only configurable input is the business-critical executable list, which feeds heuristic 1. All other heuristics are applied automatically based on system data.
Q: An executable we consider high-risk isn't appearing in the Most-At-Risk set. Why? A: The most likely reasons are: (a) the executable is not production-active and was excluded from the dependency map, (b) the executable has no dependency on any of the changed objects in this cycle's transports, or (c) the executable has not been added to the business-critical list. If it should always be prioritized when impacted, adding it to the business-critical list ensures it is never deprioritized.
Q: Does the Most-At-Risk set change during the cycle as tests execute? A: No. The Most-At-Risk set is determined at cycle creation from the dependency map and heuristics. It is fixed for the lifecycle of the cycle. What changes as tests execute is the coverage status of those executables — which ones have been verified and which remain unverified.
Part of the Day Zero: Structural Analysis section | SeaLights for ABAP
Last updated
Was this helpful?