> For the complete documentation index, see [llms.txt](https://docs.sealights.io/knowledgebase/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealights.io/knowledgebase/knowledge-base/sealights-for-abap/intro-to-sealights/glossary.md). # Key Concepts & Glossary {% hint style="info" %} This page defines every term, object, and concept used across SeaLights for ABAP documentation. Use it as a reference when reading any other page in this documentation area. Terms are grouped by theme, then listed alphabetically within each group. {% endhint %} ### 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
TermOne-Line Definition
TransportSAP package of changes moved between systems; the input to a test cycle
ABAP ObjectIndividual SAP artifact (program, table, class, etc.) changed by a transport
ExecutableRunnable SAP artifact (transaction, program, app) that depends on ABAP objects
LandscapeLogical grouping of SAP systems in a shared pipeline
SystemA specific SAP instance (e.g., QA1, Dev) within a landscape
Test CycleThe primary unit of work; scopes analysis to specific transports and produces three outputs
Most-At-Risk ExecutableTop-ranked executables that most urgently need test coverage in a cycle
Business CriticalityManual flag that forces an executable to highest risk priority when impacted
Covering TestAny test that exercises at least one most-at-risk executable
Optimal Test SetThe smallest combination of covering tests that covers all most-at-risk executables
Test GapA changed object with no covering test in the repository
Transport RangeThe defined boundary (by transport or date) of what a cycle includes
Day ZeroPre-execution phase; structural analysis only, no history required
Day One OnwardPost-execution phase; observed results refine future recommendations
App AreaL1 business grouping in coverage reports (e.g., Finance, HR)
Coverage ReportAuto-generated per-cycle report organized by App Area → Executable → Object
Test RepositoryExternal tool where tests are stored; SeaLights reads from it for recommendations
SAP Solution ExtensionsSAP certification program under which SeaLights for ABAP is qualified
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.sealights.io/knowledgebase/knowledge-base/sealights-for-abap/intro-to-sealights/glossary.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.