> 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/test-cycles/working-with-test-gaps.md). # Working with Test Gaps The **Test Gaps** tab answers the question: *what changed that has no test at all?* It surfaces every changed ABAP object in the cycle's transport scope for which no covering test exists in the connected test repository. Each entry is a change that will reach production with no documented verification unless the team acts. For every gap, teams make an explicit decision: test it manually, write a new test, or formally accept the risk. *** ### Business Value & Key Use Cases * **Making invisible risk visible** — Without the Test Gaps tab, changed objects with no test coverage pass through the release process silently. Every entry in the tab is a risk that would otherwise go undocumented. * **Driving gap closure** — The gap list is the starting point for every resolution decision in a cycle — assigning manual testers, raising new automation requests, or recording a formal risk acceptance. * **Building coverage over time** — Recurring gaps across multiple cycles identify persistent blind spots in the test repository, guiding long-term test authoring priorities. * **Audit documentation** — Formally accepted gaps, recorded per cycle, provide auditors with evidence that coverage limitations were known and consciously managed. *** ### Detailed Functionality #### The Three Resolution Options Every gap requires an explicit decision. No action is not an option — an undocumented gap that reaches production is unmanaged risk. **Test manually** — Execute a manual test against the affected executable in this cycle and report the result back to SeaLights. The fastest resolution for one-off changes or low-automation areas. **Write a new automated test** — Create a test in the connected repository that covers the affected executable. The gap closes in future cycles once the test is executed and reported. **Accept the risk** — Document a formal decision that the gap is known, assessed, and accepted for this release. Record the rationale in the team's release governance tooling. SeaLights provides the gap data; the decision and its documentation are managed externally. #### Gaps and the Carry Over Mechanism Unresolved gaps do not disappear when a cycle closes. If the next cycle is created with **Carry Over**, all open gaps are inherited automatically — so nothing is silently dropped between cycles. Gaps that were resolved (covered by an executed test) are not carried forward; only genuinely unresolved ones are. #### Gaps Reduce Over Time As new tests are written and added to the repository, subsequent cycles surface fewer gaps for the same executables. A consistent gap-closure practice across release cycles produces a test repository that is progressively better aligned to the real risk profile of the SAP landscape. *** ### FAQ **Q: We have a test that covers a gapped object but it's not being recognized. Why?** A: The test likely hasn't been executed and reported back to SeaLights in this cycle yet. Coverage is based on observed execution, not test metadata. Once the test runs and results are reported, the object should leave the gap list. **Q: Can we mark a gap as accepted directly in SeaLights?** A: Not in the current release. Risk acceptance is documented outside SeaLights in the team's governance tooling. \[Configuration detail pending validation — in-product risk acceptance is being evaluated for a future release.] **Q: The gap count is very high on our first cycle. Is this expected?** A: Yes, particularly for large transport sets or when the repository hasn't been validated against this specific transport set before. The gap count reflects the actual state of coverage — not a system error. Use the app area breakdown in the download to prioritize where new tests are most needed. **Q: Does the same object appear multiple times if it was modified by several transports?** A: No. The gap list is de-duplicated at the object level. What matters is whether the object has coverage — not how many transports modified it. --- # 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/test-cycles/working-with-test-gaps.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.