# Test Plan

| Field           | Value                          |
|-----------------|--------------------------------|
| Project         | [Project name]                 |
| Date            | [YYYY-MM-DD]                   |
| Version         | [1.0]                          |
| Status          | [Draft / Released]             |

---

## 1. Test strategy

[Describe the approach: e.g. test-first, requirement-based, risk-based.]

Each requirement has at least one test (`@reqs` tag in the test). Coverage targets as in the SWE Plan section 8.

## 2. Test levels

| Level         | Scope                | Tool       | Environment | Status        |
|---------------|----------------------|------------|-------------|---------------|
| Unit          | Functions / modules  | [CppUTest] | host x86    | [planned]     |
| Integration   | Module interaction   | [CppUTest] | host / SiL  | [planned]     |
| System        | End-to-end           | [manual]   | SiL / HiL   | [planned]     |
| Acceptance    | Client acceptance    | [manual]   | HiL / vehicle | [planned]   |

## 3. Test management

- Tests live in `tests/unit/`, `tests/integration/`, ...
- Each test file carries `@reqs` tags pointing to the covered requirements
- Tests run automatically in CI on every push
- Coverage report is published as a CI artefact

## 4. Test selection per component

| Component          | ASIL | Test file                        | Method                          |
|--------------------|------|----------------------------------|---------------------------------|
| [Component A]      | [D]  | tests/unit/test_componentA.c    | Equivalence classes + boundary + MC/DC |
| [Component B]      | [B]  | tests/unit/test_componentB.c    | Equivalence classes + boundary  |
| [Component C]      | [QM] | tests/unit/test_componentC.c    | Equivalence classes              |

## 5. Entry and exit criteria

**Entry to test execution:**
- Code compiles
- Doorstop check is green
- Static analysis has no critical findings

**Exit:**
- All tests green
- Coverage target reached
- Test report archived

## 6. Defect handling

- Test failure = blocking issue
- Issue raised via Gitea Issues, referenced in the PR
- Severity classification per QA Plan section 4

## 7. Reporting

Test reports are generated automatically:
- Console output of the test framework (TAP / JUnit XML)
- Coverage HTML from lcov
- Both as CI artefacts under `tests/results/`

---

*Changes to this plan are versioned in the Gitea wiki.*