> 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/coverage-analysis-and-reporting/understanding-the-coverage-analysis.md). # Understanding the Coverage Analysis The Coverage Analysis is an automatically generated, per-cycle record showing exactly which changes were verified by tests and which were not. It is organized in three levels of business context — App Area, Executable, and Object — so every stakeholder, from business owner to auditor, can read the same report and reach the same conclusion without needing to interpret raw ABAP object names. *** ### Business Value & Key Use Cases * **Release sign-off without ABAP expertise** — Release owners, QA leads, and business stakeholders read coverage in terms they understand — Finance, Purchasing, Order-to-Cash — not in function module names and program IDs. A single report serves the whole release governance chain. * **Pinpointing where gaps remain** — The three-level hierarchy makes it immediately clear not just that coverage is incomplete, but *where* it is incomplete — which business process, which executable, which specific changed object remains unverified. * **Audit-ready by default** — Every cycle's coverage report is retained permanently and reproducible at any time. There is nothing to reconstruct after the fact. #### Impact Metrics A coverage report that would require manual cross-referencing of test results, ABAP object lists, and business process maps to produce by hand is generated automatically for every cycle. It updates in near real-time as tests execute, so release owners always have a current picture of readiness without chasing status updates. *** ### Detailed Functionality #### The Three-Level Hierarchy Coverage is reported at three levels, each answering a progressively more specific question: **L1 — App Area** The SAP functional module the change belongs to — for example, Finance (FI), Purchasing (MM-PUR), Sales (SD), or Human Resources (HR). App Areas are the business process lens: a release manager reviewing coverage can immediately see which functional domains are fully verified and which still have open risk. **L2 — Executable** The specific runnable artifact within the App Area — for example, a transaction, a Fiori app, or a business process flow like Order-to-Cash or Source-to-Pay. The Executable level is where QA leads and test managers work: it shows which programs and processes have been tested and which have not. **L3 — Object** The individual ABAP object that changed — the function module, table, class, or program modified by the transport. The Object level is where architects and auditors go when they need to verify that a specific change was exercised, not just that the surrounding executable was tested. #### Reading the Report Each row in the report displays three values:
ColumnWhat It Shows
Change Coverage %The percentage of changed objects at that level that have been exercised by at least one executed test
Untested ChangesThe count of changed objects at that level with no confirmed test coverage yet
Total ChangesThe total count of changed objects at that level in this cycle's scope
A row showing 97% coverage with 3 untested changes out of 132 total means 3 changed objects at that level have not yet been exercised by any reported test execution. Expanding the row reveals exactly which executable or object those 3 belong to. #### What "Covered" Means An object is counted as covered when a test that has been executed and reported to SeaLights has demonstrably exercised that object at runtime. This is confirmed by Day One Onward observation — not by the test being recommended, not by the test being run, but by SeaLights observing the object was actually hit during execution. This distinction is important: a test can be recommended for an executable, executed successfully, and still leave the underlying changed object uncovered if the test's execution path did not reach that object. The Coverage Report reflects observed reality, not planned intent. #### Coverage at the Cycle vs. Release Level A single coverage report corresponds to a single test cycle. For releases that span multiple cycles (e.g., a large upgrade program with several transport waves tested across separate cycles), each cycle has its own coverage record. *** ### FAQ **Q: An executable shows 100% coverage but we know not all its functions were tested. Is the report wrong?** A: Coverage is measured at the changed object level, not at the total executable level. 100% means every ABAP object that *changed in this cycle's transports* and belongs to that executable has been exercised. Unchanged parts of the executable are not in scope — SeaLights measures risk introduced by this release, not the entire executable's behavior. **Q: The App Area mapping for some of our custom Z-programs looks wrong. Can this be corrected?** A: Yes. SeaLights automatically maps custom transactions and objects to business areas, but this mapping may not always align with the team's own classification. More accurate business context mapping for custom objects is included in Service Pack 1. \[Configuration detail pending validation — the mechanism for overriding or correcting App Area mappings for specific custom objects.] **Q: Can we filter the report to show only uncovered changes?** A: \[Configuration detail pending validation — filtering the Coverage Analysis view to show only rows with remaining gaps is being evaluated for Service Pack 2 alongside richer reporting features.] **Q: Does the coverage report include tests that ran but were not in the SeaLights recommendation?** A: Yes. Coverage is tracked for any test that executes and reports results back to SeaLights, regardless of whether it was in the optimal set, the covering list, or neither. If a test exercises a changed object, that object is counted as covered. --- # 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/coverage-analysis-and-reporting/understanding-the-coverage-analysis.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.