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). Tests can be executed and results recorded directly within the tab using the built-in test runner, without switching to an external tool.
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.
Report manual execution directly in SeaLights — Testers can mark tests as Passed or Failed directly inside SeaLights. Results update coverage immediately and appear in the multi-app Executed Tests report.
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.
The Test List
The test list loads automatically below the stats box when the tab is opened — no button press required.
Single-repository cycle — the list loads directly with no repository selector.
Multi-repository cycle — all repositories' tests are merged into a single table. A Test Repository column identifies the source of each test, and a repository dropdown above the table allows filtering to a specific repository.
Toolbar
Three controls sit above the table:
Filter — opens the filter drawer; a badge on the button shows the count of active filter selections
Search — filters the list by test name
Optimal Tests Only toggle — hides all non-optimal tests from the view
Filter drawer categories (in order):
Status — Not Run / Passed / Failed
Ran By — full name per user who has run tests in this session; shows "No tests have been run yet" if empty
App Area — dynamically populated from the cycle's test data
Executable — dynamically populated from the cycle's test data
Filter selections and sort order are saved per user and restored automatically in the next session.
Test Table
Test Repository
Displayed as [Type] Name (e.g., [qTest] Regression Tests)
Optimal
⭐ if the test is part of the optimal sub-set
Test Name
Includes an info icon showing the test ID and full path, both individually copyable
Status
Not Run (gray) / Passed (green chip) / Failed (red chip)
Ran By
Avatar with user initials, already run
▶
Play button — visible on row hover; opens the test runner card
Test Runner Card
Clicking ▶ on any row opens the runner card below the toolbar and hides the test list. The card shows:
Optimal indicator (⭐ if applicable)
Test name, Test ID, and full SAP test path (linkable where applicable)
Bottom action area:
Cancel
Returns to the test list without saving
Timer
Counts up in MM:SS from when the card opens
Passed / Failed
No default, must be explicitly selected
Submit
Enabled only after a result is selected
After submitting, the runner card closes and the test list reappears with the updated Status and Ran By visible in that row. Start and end times are recorded and used to improve the statistical recommendation model over time.
Result Persistence
Reported results appear in the related multi-app coverage report under Executed Tests. Once a direct integration with a test tool is active, results from that tool appear in the same table automatically.
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.
Last updated
Was this helpful?