# Test Optimization for Shift Left Testing

Shift-Left testing is the practice of moving quality verification into the earliest stages of the development lifecycle. The goal is to provide developers with immediate feedback, ideally within the Pull Request (PR) or CI pipeline, by running a surgical subset of **advanced tests** (such as Functional and End-to-End suites) that validate the specific changes being introduced.

By using SeaLights **Aggressive Optimization**, you can execute even complex end-to-end tests early in the cycle without delaying the "Merge to Main" process.

{% hint style="info" %}
**Shift-Left** does not refer to unit or component testing (which are already developer-led). Standard unit and component tests can still enjoy the advantages of SeaLights Test Optimization by following the **Automated Testing Optimization** playbook.
{% endhint %}

### The Shift-Left Velocity Matrix

This strategy balances the need for instant feedback with the requirement for total system stability.

| Stage                 | Cadence            | Optimization Profile                                                | Purpose                                                              |
| --------------------- | ------------------ | ------------------------------------------------------------------- | -------------------------------------------------------------------- |
| **Pull Request (PR)** | Every Commit       | **Aggressive**                                                      | Catch functional breakage early using only the relevant E2E subset.  |
| **Main/Development**  | Every Merge        | **Aggressive**                                                      | Ensure the integrated "Delta" is stable before moving to QA/Stage.   |
| **Stability Sync**    | Nightly / Weekends | <p><strong>Full Run</strong> </p><p>("Impacted & Skipped" pool)</p> | Clear all "Risk Debt" and provide a clean baseline for the next day. |

### Strategic Shift-Left Implementation

#### 1. Moving "Heavy" Tests Early

* **The Problem:** Traditionally, E2E and Functional tests are held back for the "QA Stage" because they take hours to run. This delays feedback by days, leading to "developer context switching" or ignored results..
* **The Solution:** Set the the relevant test stage to **Aggressive** mode for PR builds. SeaLights identifies which specific Functional/E2E tests map to the code changes in a commit/PR. By running only those 5 or 10 tests instead of 500, we "Shift-Left" high-level validation into the PR gate.
* **Objective:** Give the developer a "Green/Red" light in minutes, verifying that their specific logic hasn't broken existing flows.

#### 2. Testing Close to the Developer

* **High Frequency:** By reducing the execution time, we can run tests more frequently.
* **Reduced Noise:** Developers only see failures relevant to the code they just touched, reducing the "it's just a flaky test" excuse often associated with large, unrelated suites. Making the test results actionable rather than a distraction.

### Managing the "Day/Night" Cycle

Since Shift-Left prioritizes speed during work hours, we use off-peak hours to ensure 100% coverage.

* **Daytime (Peak Velocity):**
  * Only **Aggressive** runs should be permitted in the CI.
  * No "Full Runs" are allowed to clog the pipeline.
  * Feedback loop is kept under a strict time limit (e.g., < 10 minutes).
* **Nightly/Weekend (The Safety Net):**
  * A scheduled CI job triggers a **Full Run** (Impacted & Skipped).
  * This validates the entire system against the current state of the "Main" branch.
  * Any regressions missed by the Aggressive subset are caught here and addressed first thing in the morning.

### **Managing Test-to-Code Mapping Across Branches and PRs**&#x20;

Test Optimization relies on statistical modeling, a map that links specific code methods to the tests that validate them. While every branch maintains its own model to ensure accuracy, rebuilding this from scratch for every Pull Request is inefficient. To keep PR feedback loops near-instant, you can choose how the model initializes:

* **Building Upon Previous Branch** <mark style="background-color:green;">(Recommended for PRs)</mark>: Instead of a full retrain, the PR "inherits" the intelligence model from its parent branch (e.g., `main` or `develop`). This minimizes overhead and provides immediate optimization for new branches.
* **From Scratch**: The system builds a completely new map for the branch. This is typically reserved for long-lived branches or major architectural shifts where the code has diverged significantly from the parent.

### Success Metrics for Shift-Left

* **Functional PR Coverage:** Percentage of PRs validated by at least one relevant E2E/Functional test.
* **Mean Time to Feedback:** The average time from code push to test results.\
  Reducing E2E feedback from "days" (post-merge) to "minutes" (pre-merge).
* **PR Failure Rate:** How often bugs are caught *before* merging to the main branch.
* **System Stability:** Reduction in "Emergency Hotfixes" or bugs discovered in later stages (Stage/Prod).
* **Escape Rate to QA:** Number of functional bugs caught in the PR stage versus the QA stage.


---

# Agent Instructions: 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:

```
GET https://docs.sealights.io/knowledgebase/guides/test-optimization/test-optimization-playbooks/test-optimization-for-shift-left-testing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.