Key Concepts & Glossary
SAP Concepts (as Used in SeaLights Context)
These are standard SAP terms whose meaning within SeaLights may differ slightly from general SAP usage. Understanding how SeaLights interprets these is essential for implementation and cycle setup.
Transport (Transport Request)
The standard SAP mechanism for moving changes — code, configuration, or customization — between SAP systems (e.g., from Development → Quality Assurance → Production). In SeaLights, a transport is the primary input unit for change analysis. When you create a test cycle, you select one or more transports; SeaLights analyzes every ABAP object those transports touched.
ABAP Object
Any individual artifact that lives inside SAP and can be changed via a transport: programs, function modules, classes, methods, database tables, data elements, BAPIs, IDocs, and more. SeaLights tracks changes at the ABAP object level and maps those objects to the executables that depend on them.
SeaLights focuses exclusively on objects that actually changed in the imported transports — not the entire SAP object inventory.
Executable
An ABAP artifact that can be directly triggered or run in an SAP system — for example, a transaction, a program, or a Fiori app.
SeaLights only considers executables that are actively used in the production system (based on usage data pulled from SAP tables). Unused executables are excluded, keeping the analysis focused on real business risk.
Distinction: An ABAP object is what changed; an executable is what a user or test runs. One executable may depend on many objects; one object change may impact many executables.
Landscape
In SeaLights, a Landscape represents a logical grouping of SAP systems that belong to the same development-to-production pipeline — for example, "Europe Finance" or "Asia Pacific Logistics." When creating a test cycle, you select the landscape first, then the specific system within it.
System
A specific SAP instance within a landscape, identified by its system ID (SID) and purpose — for example, a QA system (QA1, QA2) or a Development system (Dev). SeaLights maps its dependency and usage data to a specific system.
Test Repository
The external test management tool where your test cases are stored and executed. SeaLights connects to your test repository to read test definitions and build recommendations. When creating a cycle, you select which test repository to query (e.g., qTest, Tosca). For supported integrations, execution results are also reported back to SeaLights from the repository after tests run.
App Area
The highest-level business grouping in SeaLights coverage reports — equivalent to an SAP functional module or business domain. Examples: Finance (FI), Human Resources (HR), Sales (SD), Purchasing (MM-PUR). Coverage is aggregated and displayed at the App Area level first, allowing release owners to assess business process risk at a glance without reading raw ABAP object names.
Test Repository
The external test management tool where your test cases are stored and executed. SeaLights reads test definitions from your repository to build recommendations, and (for supported integrations) receives execution results back. Supported repositories include Tricentis Tosca, qTest, SAP Cloud ALM, SAP Solution Manager, Worksoft Certify, Azure DevOps, Xray, Excel, and OpenText ALM/Octane.
SeaLights Core Concepts
These terms are specific to SeaLights for ABAP and define how the platform reasons about change, risk, and coverage.
Test Cycle
The fundamental unit of work in SeaLights for ABAP. A test cycle scopes a change impact analysis to a specific landscape, system, test repository, and set of transports, then produces three outputs: a Change Analysis, a Tests-to-Run recommendation, and a Test Gaps report.
Cycles have two lifecycle states:
Running — active; coverage updates automatically as tests execute (~every 15 minutes)
Closed — finalized; the cycle's report is locked and retained for audit purposes
Most-At-Risk Executable
An executable that the SeaLights risk-ranking engine has identified as the highest priority to test in a given cycle.
The Most-At-Risk list is the output of Day Zero structural analysis and requires no prior execution history.
Business Criticality
A classification that can be applied to specific executables to mark them as business-critical. When a business-critical executable is touched by a changed object, it is always ranked first in the Most-At-Risk list, regardless of the other heuristics. This ensures that your highest-stakes processes are never deprioritized.
Covering Test
A test that exercises at least one Most-At-Risk executable in the current cycle. A covering test genuinely reduces risk — but multiple covering tests may target the same executable, making some of them redundant relative to each other.
SeaLights surfaces the full list of covering tests alongside the optimal sub-set so teams can choose their risk/efficiency trade-off.
Optimal Test Set
The smallest possible combination of covering tests that still guarantees every Most-At-Risk executable is exercised at least once — nothing redundant, nothing missing. Running the optimal set is the most efficient path to full risk coverage for a given cycle.
Test Gap
A changed ABAP object for which no covering test exists in the connected test repository. Test gaps represent unverified risk. For each gap, teams must make an explicit decision:
Test manually in this cycle
Write a new automated test to close the gap permanently
Accept the risk and formally document that decision
Change Impact Analysis
The process SeaLights performs at cycle creation: tracing which ABAP objects changed in the selected transports, mapping those objects to the executables that depend on them, and ranking those executables by risk. Change impact analysis produces the Change Analysis tab results — app areas affected, impacted executables, most-at-risk executables, and changed object count.
Coverage (Change Coverage)
The percentage of Most-At-Risk executables that have been exercised by at least one test during the current cycle. Coverage is reported at three levels:
L1 — App Area (e.g., Finance, HR, Purchasing) — business process grouping
L2 — Executable (e.g., Order-to-Cash, Source-to-Pay) — the runnable artifact
L3 — Object — the specific ABAP object that changed
Day Zero / Day One
Two phases that describe when and how SeaLights produces and refines its analysis.
Day Zero
The phase that begins the moment a test cycle is created, before any test has been executed. In Day Zero, SeaLights relies entirely on structural analysis — the dependency map and risk heuristics — to produce a recommended test set. No execution history is required, which means value is available from the very first cycle.
Day One Onward
The phase that begins after tests execute and report back to SeaLights. In this phase, SeaLights observes which underlying ABAP objects each test actually touched at runtime (versus which objects it was predicted to cover). Confirmed links are retained and strengthened; predicted links that were never exercised are dropped from future recommendations. This learning loop makes every subsequent cycle more accurate without any manual intervention.
Quick Reference: Terms at a Glance
Transport
SAP package of changes moved between systems; the input to a test cycle
ABAP Object
Individual SAP artifact (program, table, class, etc.) changed by a transport
Executable
Runnable SAP artifact (transaction, program, app) that depends on ABAP objects
Landscape
Logical grouping of SAP systems in a shared pipeline
System
A specific SAP instance (e.g., QA1, Dev) within a landscape
Test Cycle
The primary unit of work; scopes analysis to specific transports and produces three outputs
Most-At-Risk Executable
Top-ranked executables that most urgently need test coverage in a cycle
Business Criticality
Manual flag that forces an executable to highest risk priority when impacted
Covering Test
Any test that exercises at least one most-at-risk executable
Optimal Test Set
The smallest combination of covering tests that covers all most-at-risk executables
Test Gap
A changed object with no covering test in the repository
Transport Range
The defined boundary (by transport or date) of what a cycle includes
Day Zero
Pre-execution phase; structural analysis only, no history required
Day One Onward
Post-execution phase; observed results refine future recommendations
App Area
L1 business grouping in coverage reports (e.g., Finance, HR)
Coverage Report
Auto-generated per-cycle report organized by App Area → Executable → Object
Test Repository
External tool where tests are stored; SeaLights reads from it for recommendations
SAP Solution Extensions
SAP certification program under which SeaLights for ABAP is qualified
Last updated
Was this helpful?