> 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/what-is-a-test-cycle.md). # What Is a Test Cycle? A test cycle is the primary unit of work in SeaLights for ABAP. It scopes a change impact analysis to a specific SAP landscape, system, test repository, and set of transports — then produces three outputs that answer the core testing questions for that release: what changed and what's at risk, which tests to run, and which changes have no test coverage at all. Every action in SeaLights for ABAP happens inside a cycle. *** ### Business Value & Key Use Cases * **Release governance** — Every release cycle produces a documented, timestamped record of what changed, what was recommended for testing, and what was actually covered. Release managers have an auditable sign-off artifact without any manual assembly. * **Ongoing regression management** — Teams running frequent transport imports (support packs, custom releases, sprint deliveries) create a cycle per import or per sprint to continuously track test coverage without losing prior context. * **Upgrade and migration programs** — During large SAP upgrade programs (e.g., ECC to S/4HANA), cycles provide a structured, repeatable mechanism to manage testing across multiple transport waves, landscapes, and test repositories in parallel. * **Audit and compliance readiness** — Closed cycles are retained permanently. Auditors can review any past cycle's coverage report without requiring the team to reconstruct what was tested. #### Impact Metrics In documented SAP upgrade programs, teams using SeaLights test cycles identified the optimal test set from repositories of 5,000+ tests, reducing execution scope by up to 96% per cycle while maintaining full coverage of every most-at-risk executable. Cycle history ensures no release goes undocumented, eliminating the gap between what teams think was tested and what was actually verified. *** ### Detailed Functionality #### Cycle Lifecycle A test cycle moves through two states from creation to close:
StateDescription
RunningThe cycle is active. Change analysis is complete, test recommendations are available, and coverage updates automatically approximately every 15 minutes as tests execute and report back. New transports imported after the cycle's defined range are not automatically added — the transport scope is fixed at cycle creation.
ClosedThe cycle is finalized. The coverage report is locked, retained permanently, and reproducible for audit purposes. No further coverage updates occur after close.
> **Note:** Closing a cycle is a permanent action. Once closed, no additional test results can be added to that cycle's coverage record. Ensure all intended tests have been executed before closing. #### What a Cycle Produces Every cycle generates three outputs, accessible as tabs within the cycle's results workspace: **1. Change Analysis** A summary of the transport impact: how many app areas (SAP functional modules) were affected, how many executables were impacted, how many were ranked most-at-risk, and the total count of changed ABAP objects. The full analysis is downloadable as a file for your own records. **2. Tests to Run** The test recommendation output — the full list of covering tests and the optimal test sub-set (the minimum number of tests that leaves no most-at-risk executable unverified), expressed as potential test savings against your full repository. Downloadable and ready to hand to your test runner. **3. Test Gaps** The list of changed ABAP objects for which no covering test exists in the connected test repository, organized by app area and executable. Downloadable for gap-closure tracking and decision-making. #### Cycle History and Traceability Every cycle you have ever run remains visible in the Test Cycles list — it is never deleted or archived out of view. Each entry records the creator, creation date, close date (if applicable), landscape, system, test repository, and transport count. This gives QA leads, release managers, and auditors a complete historical record of every testing decision made. #### Parallel Cycles Multiple cycles can run simultaneously across different landscapes, systems, or test repositories. There is no enforced limit on concurrent active cycles. Teams managing multi-system SAP landscapes (e.g., separate QA environments for finance and logistics) can run independent cycles per system without interference. *** ### FAQ **Q: Can I add more transports to a cycle after it has been created?** A: No. The transport scope of a cycle is fixed at creation. If additional transports need to be analyzed, create a new cycle using the **Carry Over** option, which inherits untested items from the previous cycle and allows you to add the new transports on top. **Q: Can I reopen a closed cycle?** A: No. Closing a cycle is permanent. The cycle's coverage report is locked at the point of close and retained for audit. If testing continues after an accidental close, a new cycle should be created. **Q: How many cycles can be active at the same time?** A: \[Configuration detail pending validation] — there is no documented limit on concurrent running cycles in the current release. **Q: Does a cycle automatically close after a certain period?** A: No. Cycles remain in Running state indefinitely until manually closed. There is no timeout or auto-close behavior. **Q: If a test runs against the SAP system but isn't reported back to SeaLights, does it count toward coverage?** A: No. Only test executions that are reported to SeaLights — either automatically (Tricentis Tosca) or via the connected test repository integration — are reflected in cycle coverage. Tests run outside the reporting flow are invisible to SeaLights. **Q: Is there a limit to how many cycles are retained in history?** A: \[Configuration detail pending validation] — all cycles observed in practice are retained permanently with no documented retention limit. --- # 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/what-is-a-test-cycle.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.