> 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/multi-app-coverage-report.md).

# Creating Coverage Analysis Manually

Coverage reports in SeaLights for ABAP can be created independently of the test cycle flow — either manually through the **Coverage Analysis** wizard, or programmatically via the SeaLights API. This allows teams to define a custom transport scope and coverage collection boundary at any time, without being tied to an existing test cycle. The result is a named, persistent coverage report that sits alongside cycle-generated reports in the Coverage Analysis workspace.

***

### Business Value & Key Use Cases

* **Release-level reporting across multiple cycles** — When a release spans several test cycles, a manually created report can consolidate coverage across the full transport range of the release, providing a single coverage artifact for sign-off rather than one per cycle.
* **Ad-hoc impact assessment** — Teams can create a coverage report for a specific transport range at any time — for example, to assess coverage for a hotfix, a specific feature branch, or a retrospective review — without having to create or modify a test cycle.
* **CI/CD and pipeline integration** — Via the API, test execution results from automated pipelines, non-standard test tools, or custom frameworks can be reported directly to SeaLights and reflected in a coverage report, without requiring those tools to be connected as a formal test repository.
* **Cross-system coverage consolidation** — A single report can collect coverage from multiple systems within the same landscape, giving a unified view across environments (e.g., QA1 and QA2 combined) that a single cycle — scoped to one system — cannot provide.

#### Impact Metrics

Manual report creation decouples coverage visibility from the test cycle workflow, making it accessible to teams with non-standard testing pipelines, complex multi-system landscapes, or release reporting requirements that don't map cleanly to a single cycle boundary.

***

### Detailed Functionality

#### The Four-Step Wizard

**Step 1 — Landscape**

Select the SAP landscape the report should analyze. Only landscapes connected during onboarding are available. This selection constrains all subsequent steps — scope and coverage collection are bounded to the chosen landscape.

**Step 2 — Scope**

Define the transport range the report covers using two boundary points:

<table><thead><tr><th width="170.73046875">Field</th><th>Options</th></tr></thead><tbody><tr><td><strong>Base Transport</strong></td><td>The starting boundary — either the earliest transport on a selected date, or a specific transport ID</td></tr><tr><td><strong>Target Transport</strong></td><td>The ending boundary — defaults to the latest transport on the system, or can be set to a specific transport ID or date</td></tr></tbody></table>

A **System Selection** field below the transport range defines which system within the landscape is used to calculate the transport scope. This is the system SeaLights reads to determine which transports fall within the defined range.

**Step 3 — Coverage**

Coverage data is collected from the system selected in Step 2 by default. Optionally, coverage can be extended to additional systems within the same landscape:

**Collect coverage from additional system(s)** — when enabled, two sub-options appear:

* **Select All Relevant Systems** — automatically includes all systems in the landscape that have coverage data for the defined transport scope
* **Select Specific Systems** — manually choose which additional systems to include; selected systems are shown with their associated environments (e.g., `QA +1`)

This makes it possible to produce a single report that consolidates coverage from multiple test environments — for example, combining automated test results from QA1 with manual test results from QA2 — into one unified coverage picture.

**Step 4 — Report Name**

Enter a free-text name for the report. The name appears in the Coverage Analysis list and is the primary identifier for the report going forward. Names should be meaningful for the team and any downstream stakeholders who will use the report for sign-off or audit purposes (e.g., "Payment Group Release 25.6", "Frontend Sprint Oct").

Click **Create Report** to generate the report. It appears immediately in the Coverage Analysis list.

#### The Coverage Report List

The Coverage Analysis workspace lists all reports with four columns:

<table><thead><tr><th width="222.3359375">Column</th><th>Description</th></tr></thead><tbody><tr><td><strong>Report Name</strong></td><td>The name assigned in Step 4</td></tr><tr><td><strong>Date Range</strong></td><td>The transport scope expressed as a date range (derived from the Base and Target Transport selections)</td></tr><tr><td><strong>Code Changes Coverage</strong></td><td>The percentage of changed objects within the transport scope that were exercised by at least one test</td></tr></tbody></table>

#### Creating Reports via API

For teams integrating SeaLights into CI/CD pipelines or using test tools not connected as formal repositories, coverage data can be reported to SeaLights programmatically via the API. This allows:

* Reporting test execution results from custom or unsupported test frameworks
* Automating report creation as part of a pipeline step, without manual wizard interaction
* Integrating SeaLights coverage tracking into existing DevOps tooling

\[Configuration detail pending validation — API endpoint reference, authentication method, required payload structure, and supported operations for programmatic coverage report creation and result reporting should be confirmed and linked here from the API documentation.]

***

### FAQ

**Q: What is the difference between a manually created coverage report and the coverage report generated by a test cycle?** A: A test cycle generates its coverage report automatically, scoped to the transports and test repository defined at cycle creation. A manually created report gives more control — you define the transport range independently, can collect coverage from multiple systems, and are not tied to a specific test repository or cycle boundary. Both report types appear in the Coverage Analysis workspace and use the same three-level hierarchy (App Area → Executable → Object).

**Q: Can a manually created report include coverage from a Tosca test run and a qTest run at the same time?** A: Yes — if both systems reported their execution results to SeaLights and both systems are selected in Step 3 (Coverage), their combined coverage is reflected in the report.

**Q: Can I edit the transport scope or system selection after the report is created?** A: \[Configuration detail pending validation — whether manually created reports can be edited after creation, or whether a new report must be created to change the scope.]

**Q: The Code Changes Coverage shows a dash (—) for one of our reports. What does that mean?** A: A dash indicates that no coverage data has been collected for the defined transport scope yet — either no tests have been executed and reported for those transports, or the report was created but no execution results have arrived. The metric will populate once coverage data is received.

**Q: How is the Date Range in the report list determined?** A: The date range is derived from the Base and Target Transport selections in Step 2. SeaLights translates the transport boundary into the date range spanned by those transports on the selected system.

**Q: Can I share a manually created report with someone who does not have SeaLights access?** A: The report is viewable within SeaLights by any user with access to the Coverage Analysis section. For external sharing, use the export function to download the coverage data. \[Configuration detail pending validation — confirm export options available for manually created reports versus cycle-generated reports.]


---

# 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/multi-app-coverage-report.md?ask=<question>&goal=<endgoal>
```

`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.