> 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/exporting-and-using-reports-for-audits.md).

# Exporting & Using Reports for Audits

Every test cycle in SeaLights for ABAP produces a downloadable coverage analysis that is retained permanently after the cycle closes. The report is structured in business terms — App Area, Executable, Object — and is reproducible at any point in the future without reconstruction. It is the primary artifact for release sign-off, compliance documentation, and audit evidence related to SAP testing.

***

### Business Value & Key Use Cases

* **Release sign-off documentation** — The coverage report provides release owners with a structured, shareable artifact showing exactly what was tested, at what coverage percentage, organized by business process. It replaces manually assembled test evidence with an automatically generated, always-current record.
* **Audit and compliance evidence** — Regulated industries (pharmaceutical, financial services, utilities) require documented evidence that testing was performed and that specific changes were verified. SeaLights coverage reports provide this evidence per cycle, per release, without requiring the team to reconstruct what was tested after the fact.
* **Gap acceptance documentation** — The Test Gaps download records every changed object that was not covered by a test. When combined with a formal risk acceptance decision recorded in the team's governance tooling, this becomes the paper trail showing that untested changes were consciously managed, not overlooked.
* **Cross-team visibility** — Reports in business terms can be shared with business stakeholders, project managers, and governance boards who are not in SeaLights — giving non-technical audiences an accurate view of release readiness without requiring them to interpret test tooling outputs.

#### Impact Metrics

Coverage evidence that would require manual collation of test results, execution logs, and object-level change records — typically a multi-hour exercise before a release board — is available as a download at any point during or after a cycle. Retained permanently, it is accessible for re-audit years after the release without any dependency on the team members who ran the cycle.

***

### Detailed Functionality

#### Available Exports Per Cycle

Each cycle produces four downloadable artifacts:

<table><thead><tr><th width="178.9296875">Export</th><th>Content</th><th>Available From</th></tr></thead><tbody><tr><td><strong>Change Analysis</strong></td><td>Full impact assessment: impacted executables, risk rankings, changed objects, app areas affected</td><td>Change Analysis tab → Download Change Analysis</td></tr><tr><td><strong>Recommended Tests to Run</strong></td><td>The full covering test list and the optimal test sub-set with test identifiers and classification</td><td>Tests to Run tab → Download Test Recommendations</td></tr><tr><td><strong>Test Gaps</strong></td><td>All changed objects with no covering test, organized by app area and executable, including transport IDs</td><td>Test Gaps tab → Download Test Gaps</td></tr><tr><td><strong>Coverage Analysis</strong> </td><td>All changed objects with no covering test, post executions</td><td>Test Cycles →  Coverage Analysis per Cycle → Download Up to date Test Gaps</td></tr></tbody></table>

The Coverage Report itself — the App Area → Executable → Object hierarchy with coverage percentages — is accessible from the **Coverage Analysis** section and is exportable for any cycle, open or closed.

#### Permanent Retention of Closed Cycle Records

When a cycle is closed, its entire record is locked and retained indefinitely:

* The coverage report at the point of close is preserved exactly as it was
* The change analysis, test recommendations, and test gaps exports remain available
* The cycle remains visible in the Test Cycles list with its creation date, close date, creator, landscape, system, and transport count
* No data from a closed cycle is modified, purged, or archived out of reach

This means that a coverage analysis for a release from 6 or 12 months ago can be retrieved and shared with an auditor without any reconstruction effort — the record exists exactly as it was at the time of sign-off.

#### Using Reports for Formal Sign-Off

The recommended approach for using SeaLights outputs in a formal release sign-off process:

1. **Before testing begins** — Download the Change Analysis as the pre-test risk record: what changed, which executables are most at risk, and what the full impact scope is.
2. **During testing** — Monitor coverage in the Coverage Analysis section as tests execute. The live report shows release owners which business areas are verified and which remain open.
3. **Before close** — Download the Test Gaps report. For every remaining gap, record a formal decision (test manually, write a new test, or accept the risk) in the team's release governance tooling.
4. **At close** — Close the cycle to lock the coverage record. The final coverage report is now the permanent sign-off artifact for this release.
5. **For audit** — Retrieve the closed cycle's coverage report and change analysis exports from the Test Cycles list at any time. No reconstruction required.

#### Using Reports Across Multiple Stakeholders

Because the coverage report is organized in business terms rather than ABAP object names, the same download can be shared with audiences at different levels:

| Audience                            | What They Look At                                                                                     |
| ----------------------------------- | ----------------------------------------------------------------------------------------------------- |
| **Business owners / process leads** | App Area coverage percentage — is Finance covered? Is Purchasing covered?                             |
| **Release managers**                | Executable-level coverage — which specific processes have been verified?                              |
| **QA leads**                        | Test Gaps export — which specific objects still need coverage decisions?                              |
| **Auditors / compliance**           | Change Analysis + Coverage Report — what changed, what was tested, what was formally accepted as risk |

***

### FAQ

**Q: How long are closed cycle records retained?** A: \[Configuration detail pending validation — the specific data retention policy for closed cycle records, including whether there is a maximum retention period, should be confirmed with the SeaLights team.]

**Q: Can we export coverage data for multiple cycles at once into a single consolidated report?** A: Not in the current release. Each cycle's exports are independent. Cross-cycle consolidation — a single coverage view spanning multiple cycles for the same release — is \[Configuration detail pending validation].

**Q: The coverage report shows a lower percentage than our test execution logs suggest. Why?** A: Coverage in SeaLights reflects observed execution — tests that ran and were reported back to SeaLights and that demonstrably exercised changed objects. Tests that ran but were not reported, or that ran but did not reach the changed object at runtime, are not counted. The SeaLights percentage reflects verified coverage, which may be lower than the percentage of planned tests that were executed.

**Q: Can we customize the coverage report format for our organization's audit template?** A: \[Configuration detail pending validation — custom export formats or templates are not available in the current release. The exported report is in a fixed structure.]

**Q: Is there a way to add comments or notes to a coverage report before sharing it?** A: Not directly in SeaLights. The export is a structured data file. Teams typically annotate or supplement the SeaLights export in their release management tooling (e.g., attaching it to a release record in Jira, SAP Solution Manager, or a quality management system) where free-text context can be added alongside the artifact.


---

# 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/exporting-and-using-reports-for-audits.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.