> 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-recommended-tests-to-run.md).

# Working with Recommended Tests to Run

The **Tests to Run** tab answers the question: *which tests should we execute for this cycle?* It presents two recommendation tiers drawn from the connected test repository — the full covering test list (every test that exercises at least one most-at-risk executable) and the optimal test sub-set (the minimum tests needed to cover every most-at-risk executable with nothing redundant). Teams use this output to run the right tests, not all the tests.

***

### Business Value & Key Use Cases

* **Eliminating full-suite regression runs** — Teams run only the tests that cover the actual risk in the cycle. In observed deployments, this reduces execution scope by up to 96% while maintaining full coverage of every most-at-risk executable.
* **Prioritizing under time pressure** — The optimal sub-set defines the minimum viable test run for time-constrained release windows, removing subjective judgment from scope decisions.
* **Improving recommendations over time** — Every test execution reported back to SeaLights refines the dependency model, making future cycles more accurate automatically.

***

### Detailed Functionality

#### Two Tiers, One Decision

**Covering tests** — every test in the repository that exercises at least one most-at-risk executable. Running the full covering list gives maximum confidence; each most-at-risk executable is verified by at least one test, and many by several.

**Optimal tests** — the smallest subset of covering tests that still guarantees every most-at-risk executable is hit at least once. Running the optimal set is the fastest path to verified coverage with nothing left unchecked.

| Situation                                                     | Recommended tier                                                             |
| ------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Standard release with adequate time                           | Full covering list                                                           |
| Time-constrained release window                               | Optimal sub-set                                                              |
| First cycle with no execution history                         | Full covering list — builds the history that sharpens future recommendations |
| Risk-sensitive release (large upgrade, regulated environment) | Full covering list or full repository                                        |

#### How Coverage Updates After Execution

Once tests run and results are reported back to SeaLights, coverage updates automatically in the **Coverage Analysis** section, refreshing approximately every 15 minutes. The mechanism differs by repository:

* **Tricentis Tosca** — results are reported back automatically with no manual action required
* **All other repositories** — results must be reported via the repository's integration mechanism \[Configuration detail pending validation]

#### How Recommendations Get Smarter

The first cycle relies entirely on structural analysis — dependency maps and risk heuristics. As tests execute and results are observed, SeaLights learns which tests actually touch which objects at runtime. Predicted links that are never exercised are dropped; confirmed links are strengthened. Each subsequent cycle produces a tighter, more accurate recommendation.

***

### FAQ

**Q: Some tests in our repository don't appear in either list. Why?** A: Tests outside both lists do not exercise any most-at-risk executable for this cycle — either because the executables they cover were not impacted by these transports, or because they have no established execution link yet. They are not wrong; they are simply not relevant to this cycle's specific risk.

**Q: Can we run more tests than the optimal set and still have it count toward coverage?** A: Yes. Coverage is tracked for any test that executes and reports back to SeaLights, regardless of whether it was in the recommendation list.

**Q: The Potential Test Savings is 0% on our first cycle. Is something wrong?** A: This can occur when no execution history exists yet and the structural model has not yet established test-to-executable links. Savings percentages typically increase as execution history accumulates across cycles.


---

# 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-recommended-tests-to-run.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.