---
# NOTE: owner=PE from tas.yaml (never change); author=git user per verification-layers.md § 5.1 (fallback=owner)
template_version: "1.3"
artifact_type: e2e_test_spec
feature_id: "{FEATURE_ID}"
feature_title: "{Feature Title}"
owner: {pe_name}
author:
created_by:
created_date:
updated_date:
status: Draft
platform: # web | app | both
ver: 1.0
release_id: ""

sources:
  functest: "{path} # v{ver}"
  testchecklist: "{path} # v{ver}"

metrics:
  total_tcs: 0                    # §2.1 only (P0+P1, Autoable=YES, criteria-matched)
  p0_count: 0                     # §2.1: ALL applicable criteria met (C1 journey + C2 SIT + C3 Backward-Compat if applicable)
  p1_count: 0                     # §2.1: 1–2 criteria met at Risk≥MEDIUM
  regression_watch_count: 0       # §2.2: MANUAL-BLOCKER + RISK-ONLY
  excluded_count: 0               # Tier-3 routed + 0-criteria & Risk<MEDIUM (ISTQB: low-risk deferred)
  autoable_yes: 0                 # across §2.1 + §2.2
  autoable_no: 0

gate_result: "PENDING"           # PASS | FAIL | WARN — set by Phase 4 Gate
coverage_percentage: null        # Numeric % — set in Phase 5 Output
---

# E2E Test Spec: {FEATURE_ID} — {Feature Title}

> **What this is:** Detailed, executable E2E **test cases** covering the Feature's complete user business flow — HP+NEG TCs selected from Func-Test §4, scored by release-cycle relevance (E2E journey / SIT / Backward-Compatibility) + risk, ordered along the journey. NOT a checklist and NOT a high-level plan; each §2.1 row is a runnable test case with concrete steps, data, and expected result.

**Platform:** {web | app | both} | **Status:** Draft
**Sources:** Func-Test v{N} (test-case detail) · TestChecklist v{N} (§5 risk gate + §1.1 journey)
**Release test types:** E2E · SIT · UAT · Backward-Compatibility (§2.1 = mandatory automatable pass sized for all 3 cycles; §2.2 = regression-watch surplus)
**Traceability:** Selection/priority → [e2e-selection-strategy.md](../../rules/qa/e2e-selection-strategy.md) · Risk gate → [test-design.md § Risk Scoring](../../rules/qa/test-design.md#risk-scoring-formula) · Generated by `/tas-e2e`

---

## 1. Business Journey (PE summary)

| Field | Detail |
|---|---|
| **Feature ID** | {FEATURE_ID} |
| **Business Value** | {From PRD} |
| **User Journey** | {Flow: step 1 → step 2 → ... verify outcome} |
| **Key Business Rules** | {BR-1, BR-2, ...} |

---

## 2. E2E Test Execution List

> **SSoT — test-type gate, criteria+risk scoring & priority values:** [`.tas/rules/qa/e2e-selection-strategy.md` § Selection & Priority](../../rules/qa/e2e-selection-strategy.md#selection--priority-canonical-algorithm). Rows below are HP+NEG TCs from Func-Test §4, scored against 3 release-cycle-relevance criteria (E2E journey / SIT / Backward-Compat) + risk (P0 = all applicable criteria met / P1 = partial-criteria or risk-only / rest excluded).
>
> **Note:** E2E Priority differs from FuncTest Priority — assign per the rule, never copy FuncTest values.

### 2.1 TC Execution Table (Sorted by Platform → Role → Journey Step)

> **Execution order rule:** Rows are grouped by **Platform** (web before app), then by **Role** within each platform, then **sorted by Journey Step** (1→N) within each Platform+Role group. This keeps each group runnable as one continuous pass along the user flow — no re-sorting needed at execution time.
>
> **Column format = Func-Test §4** (carried verbatim — chain contract) **+ 3 journey columns prepended** (`Platform`, `Role`, `Journey Step`). `Priority` here = **E2E** priority (P0/P1 defined above in §2), NOT Func-Test priority. `Test Result` column dropped (execution tracked elsewhere). `Execution Locators` stays `_Phase 3 — SE_` until `/tas-e2e-web`/`-mobile` overwrite it. **Scope: all rows are Autoable=YES** (Autoable=NO or 0-criteria-risk-only rows → §2.2 Regression Watch).
>
> **Column-count note:** this table has 13 columns (see header). Cells below may contain `\|` (escaped pipe, e.g. `Depends: X \| Page: Y \| Role: Z`) — that is literal text INSIDE a cell, not a column separator. When counting columns, count only unescaped `|`. The separator row (`|---|...`) must have exactly 13 `---` cells, matching the header.

| Platform | Role | Journey Step | TC ID | Test Type | Description | Pre-Condition | Logical Steps | Test Data | Execution Locators | Expected Result | Priority | Traceability |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| {web/app} | {role} | {N} | {TC_ID} | {HP\|NEG} | {what this TC verifies} | Depends: {TC_ID} \| Page: {path} \| Role: {role} \| State: {state} | 1. {action} — Verify: {outcome}<br>2. ... | {field: "value" [tag]} | _Phase 3 — SE_ | • {observable outcome} | P0 / P1 | AC-{N} |

**Summary:** Total {N} | P0 {M} | P1 {K} | Coverage vs Func-Test: {M+K}/{Func-Test §4 count}

---

### 2.2 Regression Watch (Sorted by Risk Level, desc)

TCs that scored P0/P1 by criteria+risk but did **not** land in §2.1 — either release-blocking-but-manual (`MANUAL-BLOCKER`: all applicable criteria met, Autoable=NO) or risk-only with no journey/SIT/Backward-Compat relevance (`RISK-ONLY`: 0 criteria met, Risk≥MEDIUM, any Autoable). Format mirrors §2.1 (same Func-Test-derived columns) plus `Watch Reason` and `Autoable` columns; `Execution Locators` dropped.

> **Column-count note:** this table has 14 columns (see header). Cells below may contain `\|` (escaped pipe, e.g. `{HP\|NEG}`, `Depends: X \| Page: Y`) — that is literal text INSIDE a cell, not a column separator. When counting columns, count only unescaped `|`. The separator row (`|---|...`) must have exactly 14 `---` cells, matching the header.

| Platform | Role | Risk Level | TC ID | Test Type | Watch Reason | Autoable | Description | Pre-Condition | Logical Steps | Test Data | Expected Result | Priority | Traceability |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| {web/app} | {role} | {CRITICAL\|HIGH\|MEDIUM} | {TC_ID} | {HP\|NEG} | {MANUAL-BLOCKER\|RISK-ONLY} | {YES\|NO} | {what this TC verifies} | Depends: {TC_ID} \| Page: {path} \| Role: {role} \| State: {state} | 1. {action} — Verify: {outcome}<br>2. ... | {field: "value" [tag]} | • {observable outcome} | P0 / P1 | AC-{N} |

**Priority:** `MANUAL-BLOCKER` rows keep the P0/P1 they scored in the same criteria+risk pass used to populate §2.1 (they simply failed the Autoable=YES gate for §2.1 placement); `RISK-ONLY` rows are always P1 (0 criteria never qualifies for P0).

**Guideline:** `MANUAL-BLOCKER` rows need a human tester because Autoable=NO (device responsiveness, accessibility, session state, visual perception) but are release-blocking — execute before release sign-off, same as §2.1 P0. `RISK-ONLY` rows are regression-watch items — schedule per Risk Level, not release-blocking.

**When to test:** `MANUAL-BLOCKER` — same pass as §2.1 P0 (before release sign-off). `RISK-ONLY` — after §2.1 P0/P1 pass, scheduled by Risk Level (CRITICAL/HIGH first).

---

### 2.3 Cross-Feature Impact Checklist

> **Source:** TestChecklist §1.5 Shared Component Impact — `Used By (Features)` column. This Feature changes a component other Features also depend on; QC in those Features finds/re-runs their own relevant TCs — this checklist only flags **where** to look, it does not carry TC detail across Features.

| Shared Component | Risk Level | Impacted Feature | Regression Scope | Reviewed? |
|---|---|---|---|---|
| {component} | {CRITICAL\|HIGH\|MEDIUM} | {FEATURE_ID — title} | {flow/area from §1.5 Regression Scope} | ☐ |

**When to test:** Before release sign-off, alongside §2.2 CRITICAL/HIGH rows — hand this row to the impacted Feature's QC owner to confirm their regression pass covers it, then check it off.

*(Table above omitted if TestChecklist §1.5 is absent or empty — no shared components in scope.)*

#### 2.3.1 Backward-Compat Regression Note

> **Source:** TestChecklist §5 Risk Registry backward-compat `RC-INT` row (`bc_applicable=true`). This Feature changes an existing API contract that current consumers depend on — backward-compat regression **must** run at release. The backward-compat TCs themselves are designed by `/tas-apitest-plan §3` (not here); this note lists **which APIs** to include in the release regression pass and links the E2E TCs that exercise them.

**Backward-compat required:** ☐ Yes (see APIs below) — *omit this whole 2.3.1 block if `bc_applicable=false` / net-new Feature.*

| API / Endpoint | Change Type | Related E2E TC(s) | Owner | Reviewed? |
|---|---|---|---|---|
| {API name from §5 Root Cause — e.g. PUT /orders/{id}} | {breaking: field retyped \| additive: new optional field} | {E2E TC IDs with C3=true, or "— (API-only, /tas-apitest-plan §3)"} | SE (API TC) / PE (regression sign-off) | ☐ |

**When to test:** Run `/tas-apitest-plan §3` backward-compat TCs for the listed APIs before release sign-off; PE confirms the E2E regression pass covers the consumer-facing behavior.

---

## 3. AI Usage Log

> Format per [`.tas/rules/common/token-logging.md`](../../rules/common/token-logging.md).

| # | Date | Command |
|---|------|---------|
| 1 | YYYY-MM-DD | /tas-e2e |

---

## 4. Change Log

| Date | Version | Changes | Author |
|---|---|---|---|
| {YYYY-MM-DD} | 1.0 | Initial E2E test spec | {Git Username} |
