---
# Filename: Feature-{NNN}-TestChecklist.md | Location: Same directory as Feature document
# Version history: see § 6 Change Log (single source of truth)
# NOTE: owner=PE from tas.yaml (never change); author=git user per verification-layers.md § 5.1 (fallback=owner)
template_version: "3.3"
artifact_type: test_checklist
artifact_id: "{FEAT}-test_checklist"
feature_id: "{FEAT}"
feature_file: "{relative path to Feature.md}"
owner: {pe_name}
author:
created_by:
created_date:
updated_date:
reviewers: ["{PE name}", "{SE name}"]
artifact-status: draft   # draft | approved
version: "1.0"
release_id: ""

upstream_versions:
  feature_version: ""
  prd_version: ""
  versions_checked_date: YYYY-MM-DD
  nfr_sources: ["Feature", "PRD"]
  nfr_sync_date: YYYY-MM-DD

approval:                      # SSoT for approval state
  status: "draft"              # draft | pending-review | approved | revise-needed
  approved_by: ""
  approved_version: ""
  approved_date: ""
  approver_comments: ""

extensions:
  test_checklist:
    coverage_percentage: 0
    flows_total: 0
    flows_in_scope: 0
    flows_main: 0
    flows_alternative: 0
    flows_edge: 0
    flows_with_security_tag: 0
    flows_with_data_critical_tag: 0
    flows_with_user_blocking_tag: 0
    flows_with_integration_tag: 0
    test_points_total: 0
    test_points_cross_cutting: 0
    test_points_per_ac: 0
    test_points_p0: 0
    test_points_p1: 0
    test_points_p2: 0
    duplicate_pairs: []
    nfrs_listed: 0
    nfrs_qa_scope: 0
    risks_critical: 0
    risks_high: 0
    risks_all_addressed: false
    eta_total_hours: 0        # §6 Total ETA (h) — per verification-layers.md §9
    eta_total_pd: 0           # §6 Total ETA (person-days, 8h/day)
    gate_result: ""
    last_check_date: YYYY-MM-DD
    check_count: 0
    last_content_change: YYYY-MM-DD
    gates_auto_passed: []
    gates_pending_human: []
---

# Test Checklist - Feature-{NNN}: {Feature Name}

> **Metadata:** See frontmatter for version, created date, tester, and approval status.  
> **Standards:** [test-design.md](../../rules/qa/test-design.md) | [verification-layers.md](../../rules/qa/verification-layers.md) | [test-id-convention.md](../../rules/qa/test-id-convention.md)

---

# SECTION A: QUICK FILL (Auto-populated from Phase 1.3)

**Gate:** See §4 (≥90% coverage).

> **Note:** Conditional sections appear only when detected/confirmed — §1.5 Shared Components ⟺ `shared_components[] ≠ ∅` (Step 0.6); §2.4 Traceability / §3 Test Data ⟺ Phase 1.3.4 ASK = Y. Rule enforced by command Output Validation #1.

---

## 1. Feature Overview

**Platform:** [ ] Web [ ] App [ ] All

**Feature Description:** _{Brief description}_

---

### 1.1 In-Scope Business Flows (with Test Strategy)

> **See also:** [test-design.md § QA vs. DevOps Scope](../../rules/qa/test-design.md#qa-vs-devops-scope)  
> **Flow ID format:** `{FEAT}-F{NNN}-AC{N}` per [test-id-convention.md](../../rules/qa/test-id-convention.md)

| Flow ID | Name | Type | BR Mapping | Risk Tag | Prio | Given/When/Then (Summary) | Test Approach | Depends On |
|---------|------|------|------------|----------|------|--------------------------|----------------|-----------|
| F001-F001-AC1 | _{Flow name}_ | Main | BR-1, BR-2 | — | P0 | _{Given/When/Then summary}_ | UI Manual | — |
| F001-F002-AC1 | _{Flow name}_ | Alt | BR-1 | — | P1 | _{Given/When/Then summary}_ | Data Verification | F001-F001-AC1 |
| F001-F003-AC1 | _{Flow name}_ | Edge | BR-3 | [Sec] | P0 | _{Given/When/Then summary}_ | Security Probe | F001-F001-AC1, F001-F002-AC1 |

**Legend:** Auto-assigned by `/tas-TestChecklist` per [test-design.md § Test Approach Values](../../rules/qa/test-design.md#test-approach-values-functional-flows).

---

### 1.2 Out-of-Scope Items & NFR Routing (Routed to Other Test Types)

> **Purpose:** Single source of truth for non-PE test coverage — both non-NFR technical items and out-of-scope NFRs. Each row has clear Owner + Route To command. Populated by `/tas-TestChecklist` Phase 1.3.4 from `feature_digest.nfrs_raw` + `prd_nfrs_raw` (NFR rows) and Feature-Technical API Spec (non-NFR rows). NFR routing criteria (PE-testable vs tooling-required): [test-design.md § QA vs. DevOps Scope](../../rules/qa/test-design.md#qa-vs-devops-scope).

#### 1.2.1 API Test Scope (SE Owner)

**Non-NFR items:**
| Item | Source | Route To | Rationale |
|------|--------|----------|-----------|
| API Contract Tests | Feature-Technical API Spec | `/tas-apitest-plan` | Schema, status codes, error handling |
| API Integration | Feature-Technical Integration Points | `/tas-apitest-plan` | Cross-service calls, webhooks |

**NFRs (tooling-required):**
| NFR ID | Category | Baseline | Source | Route To | Rationale |
|--------|----------|----------|--------|----------|-----------|
| NFR-001 | Performance | API response <200ms | PRD | `/tas-apitest-plan` | API SLA (Postman-measurable) |
| NFR-002 | Security | OWASP API Top 10 | PRD | `/tas-apitest-plan` | SQLi, XSS, BOLA, BFLA (Postman-scriptable) |

#### 1.2.2 Pen Test Scope (DSE Owner)

**Non-NFR items:**
| Item | Source | Route To | Rationale |
|------|--------|----------|-----------|
| Pentest Engagement | PRD NFR | Security Team | Manual penetration testing |

**NFRs (tooling-required):**
| NFR ID | Category | Baseline | Source | Route To | Rationale |
|--------|----------|----------|--------|----------|-----------|
| NFR-003 | Security | DAST scanning (OWASP ZAP) | PRD | `/tas-security` | Tool-required, automated scan |

#### 1.2.3 Infra Test Scope (DevOps — Out of TAS Scope)

**NFRs (tooling-required):**
| NFR ID | Category | Baseline | Source | Route To | Rationale |
|--------|----------|----------|--------|----------|-----------|
| NFR-004 | Scalability | 1000 concurrent users (load test) | PRD | DevOps / k6 | Infra-level capacity planning |

**NFR ID note:** Use the source's ID when it has one (PRD uses `NFR-NNN`). Feature.md NFRs are free-text (no ID) — if the same requirement also exists in PRD, cite the PRD ID; otherwise cite the Feature-text excerpt directly in the "NFR ID" cell. Never invent an ID.

---

### 1.3 In-Scope NFRs (PE-Testable via Dev Tooling)

> **Scope Definition:** PE-testable NFRs = observable on app/web with dev toolbar, API logger, or manual inspection. Exclude: DAST, load test, infra, pen test (→ §1.2).  
> **Populated by:** `/tas-TestChecklist` Phase 1.3.4 (NFR routing) from `feature_digest.nfrs_raw` + `prd_nfrs_raw`. Criteria: [test-design.md § QA vs. DevOps Scope](../../rules/qa/test-design.md#qa-vs-devops-scope)
> 
> **Purpose:** Scope catalog. Detailed test approach & baseline → Phase 2 output (§2.2).

| NFR ID | Category | Source | Baseline | Platform |
|--------|----------|--------|----------|----------|
| NFR-001 | Performance | PRD | Page load < 2s (Lighthouse) | Web |
| NFR-002 | Compatibility | PRD | Responsive 320–1440px | Web |
| Feature-NFR (i18n) | Usability | Feature | All strings NL/EN via i18n keys | All |

**NFR ID note:** Use PRD `NFR-NNN` if present. Feature.md NFRs (free-text) → cite the excerpt if same requirement not in PRD; never invent an ID. **Tooling-required NFRs** routed to §1.2 instead.

---

### 1.4 UI/UX Test Basis (Per-AC Flow Details)

> **Purpose:** Detailed screen/page interaction basis for each AC's Given/When/Then. Links to §2.1 via Flow ID.  
> **See also:** [test-design.md § Test Techniques](../../rules/qa/test-design.md#test-techniques-categories--examples)

| Screen/Page | Flow ID | AC# | Precondition | Fields[^ref] | Actions | Expected State | Risk Constraints |
|-------------|---------|-----|--------------|--------------|---------|----------------|-----------------|
| Login Form | F001-F001-AC1 | AC-1 | User on login page | Email[^f1], Password[^f2] | Enter valid email + password, click Submit | Session created, redirect to dashboard | [Security], [Data-Crit] |
| Login Form | F001-F002-AC1 | AC-2 | User on login page | Email[^f1], Password[^f2] | Enter invalid email format | Error message displayed, focus returns to Email field | — |

[^f1]: Email → §2.3
[^f2]: Password → §2.3

---

### 1.5 Shared Component Impact (Conditional)

> **Conditional:** Present ⟺ shared components detected (`/tas-TestChecklist` Step 0.6 via [test-design.md § SC-DETECT](../../rules/qa/test-design.md#shared-component-detection-from-prd)). Populated from that result — inclusion rule enforced by command Output Validation #1 (single SSoT). Downstream (`/tas-functest`, `/tas-apitest-plan`, `/tas-e2e`) read this section; they do not re-detect.

| Component | Type | Used By (Features) | Risk Level | Regression Scope |
|-----------|------|-------------------|------------|------------------|
| Email Validator | Service | TAS-001, TAS-003, TAS-005 | HIGH | Auth flows, Signup, Password-Reset |

---

## 2. Test Checklist Matrix

### 2.1 Functional Test Points

> ⚠️ **AI-GENERATED:** Sections 2.1.1 & 2.1.2 auto-populated by `/tas-TestChecklist` using multi-pass dedup logic (cmd Phase 5). Do NOT manually edit TP IDs.
> **Manual role:** (1) Verify TP descriptions are clear and testable; (2) Confirm BR links are correct; (3) Add risk tags in §5 if needed.

#### 2.1.1 Cross-Cutting (Feature-Wide) Tests

| TP ID | Test Point | Prio | Covers ACs | Source |
|-------|-----------|------|------------|--------|
| F001-SEC-001 | PII encryption at rest verified | P0 | All | BR-007 |
| F001-PERF-001 | Page load within LCP target | P2 | AC-1, AC-3 | NFR-001 |

#### 2.1.2 Per-AC Tests

| TP ID | AC# | Category | Test Point | Prio | Source | Depends On |
|-------|-----|----------|-----------|------|--------|-----------|
| F001-GUI-001 | AC-1 | GUI & UX | Login form renders correctly | P0 | AC-1/Given | — |
| F001-VAL-001 | AC-1 | Validation | Email format (RFC 5322) | P0 | BR-003 | — |
| F001-VAL-001 | AC-2 | Validation | Email format (RFC 5322) | P0 | BR-003 | F001-GUI-001 |

---

#### 2.1.3 API Response Handling TPs — FE Scope

> **Scope:** FE-observable UI behavior per API response outcome. NOT API contract tests (→ `/tas-apitest-plan`).  
> **Scope boundary:** [verification-layers.md §4 Scope-Conflict Matrix](../../rules/qa/verification-layers.md#4-scope-conflict-matrix-functest--apitest-plan)

| TP ID | FE Behavior When API Responds | UI Observable State | Priority | Source |
|-------|-------------------------------|---------------------|----------|--------|
| F001-EXC-010 | Error toast when order API returns server error | Toast: "Something went wrong, please retry" | P0 | API Spec § POST /orders — 5xx |
| F001-BL-005 | Success redirect after payment confirmed | Redirect to /confirmation + order summary shown | P0 | API Spec § POST /payments — 200 |

---

### 2.2 NFR Test Design (PE-Testable Detail)

> **Source:** §1.3 routing summary. Phase 2 derives 1 row per PE-testable NFR.  
> **See also:** [test-design.md § Platform NFR Baselines](../../rules/qa/test-design.md#platform-nfr-baselines)  
> **Coverage:** Each NFR → ≥1 linked TP in §2.1.1 (Source column).

| NFR ID | Category | Baseline / Requirement | Test Approach | Tool | Priority | Linked TP |
|--------|----------|------------------------|----------------|------|----------|-----------|
| NFR-001 | Performance | Page load LCP < 2.5s, FCP < 1.8s, CLS < 0.1 | Lighthouse audit (3-run avg) | Lighthouse | P0 | F001-PERF-001 |
| NFR-002 | Accessibility | WCAG 2.1 Level AA compliance | Axe scan + manual keyboard test | Axe + Screen Reader | P0 | F001-A11Y-001 |
| Feature-NFR (i18n) | Usability | All labels/options/messages in NL + EN | Manual content review (toggle NL/EN) | Manual | P1 | F001-NFR-002 |

---

### 2.3 Input Field Constraints

> **See also:** [test-design.md § Test Data Patterns](../../rules/qa/test-design.md#test-data-patterns)

| Field | Test Constraints | Business Rule |
|-------|-----------------|---------------|
| Email | Format (RFC 5322), empty field, max-length (255), XSS injection | BR-003 |
| Password | Complexity (8+ chars, 1 uppercase, 1 digit), empty field, XSS injection | BR-004 |

---

### 2.4 Requirements Traceability Matrix

> Conditional section (Phase 1.3.4D = Y). Every Requirement → ≥1 Test Point; every Test Point → Requirement.

| Requirement | Feature Flow | Test Points | Coverage | Notes |
|-------------|--------------|-------------|----------|-------|
| User login with valid credentials | F001-F001-AC1 | F001-GUI-001, F001-VAL-001, F001-BL-001 | ✅ | Core flow |
| Invalid email rejected | F001-F002-AC1 | F001-VAL-001, F001-GUI-002 | ✅ | Alternative flow |
| Cross-Cutting TPs | Multiple ACs | {TP_ID, TP_ID, ...} | ✅ | <!-- Add cross-cutting TP rows here: one row per TP, referencing all covered ACs --> |

---

## 3. Test Data Catalog

> **Purpose:** Stable test data IDs for reuse across TPs.  
> **See also:** [test-design.md § Test Data Patterns](../../rules/qa/test-design.md#test-data-patterns)

| TD ID | Field | Type | Values | Used By TPs | BR |
|-------|-------|------|--------|-------------|-----|
| TD-001 | Email | Valid | test@example.com, user.name+tag@domain.co.uk | F001-VAL-001 | BR-003 |
| TD-002 | Email | Invalid | notanemail, test@, @domain.com | F001-VAL-002 | BR-003 |

---

## 4. Coverage Summary - Stage 1 Approval Gate

> **Gate definitions & thresholds (SSoT):** [test-design.md § TestChecklist: Approval Gate Requirements](../../rules/qa/test-design.md#testchecklist-approval-gate-requirements)

### 4.1 Primary Coverage Metric

| Coverage Area | Required | Actual | Status |
|---------------|----------|--------|--------|
| **Flow Coverage** | ≥90% | **{coverage_percentage}%** | PASS if ≥90, else FAIL |

**Breakdown:** {flows_in_scope}/{flows_total} flows covered ({flows_main} Main + {flows_alternative} Alt + {flows_edge} Edge).

### 4.2 Gate Results

| Gate | Gate ID | Type | Status |
|------|---------|------|--------|
| **Gate 1: Flow Coverage ≥90%** | `gate1_coverage` | Auto | {from `gates_auto_passed`} |
| **Gate 2: Category Completeness ≥75%** | `gate2_category` | Auto | {from `gates_auto_passed`} |
| **Gate 3: CRITICAL/HIGH risks mitigated + owned** | `gate3_risk` | **Human** | ⏳ PENDING until approved |
| **Gate 4: TP dependencies mapped, no circular deps** | `gate4_dependencies` | **Human** | ⏳ PENDING until approved |

**Overall `gate_result`:** {from frontmatter}

---

## 5. Risk Registry

> **See also:** [test-design.md § Risk Scoring Formula](../../rules/qa/test-design.md#risk-scoring-formula) | [Detection Tag → RC Code](../../rules/qa/test-design.md#detection-tag--rc-code-single-source-of-truth)

| # | Risk | Level | RC | Likelihood | Root Cause | Mitigation (≤15 words) | Action | Owner | Linked TPs | Status |
|---|------|-------|----|-----------|------------|------------------------|--------|-------|------------|--------|
| 1 | _{risk description}_ | 🔴 CRITICAL | RC-XXX | H/M/L | _{root cause}_ | _{strategy}_ | _{action verb + object}_ | PE/SE/DSE | F001-XXX-NNN | ⏳ Active |
| 2 | Backward-compat regression — existing consumers of PUT /orders/{id}, GET /orders may break | 🟠 HIGH | RC-INT | M | **PUT /orders/{id}** (field "status" retyped string→enum); **GET /orders** (v1→v2 pagination) | Design backward-compat TCs for listed APIs; add to E2E regression watch | SE: /tas-apitest-plan §3 for listed APIs; PE: /tas-e2e §2.3.1 lists them as regression | PE / SE | F001-EXC-010, F001-BL-005 | ⏳ Active |

> **Backward-compat (RC-INT) row — SSoT for the affected-API list.** Present ⟺ `bc_applicable=true` (per [test-design.md § Backward-Compat Applicability Detection](../../rules/qa/test-design.md#backward-compat-applicability-detection)). **Root Cause MUST name the concrete API(s)/endpoint(s) + change type** — downstream reads this list, never re-derives it: `/tas-apitest-plan §3` designs the TCs; `/tas-functest` inherits it (no TC design); `/tas-e2e §2.3.1` lists the APIs for release regression. Level = HIGH if breaking, MEDIUM if additive-only. Delete row 2 above if net-new (`bc_applicable=false`).

---

## 6. Effort Estimation (ROM — Agile priority-weight × ISTQB test-level, ±30-50%)

> **Formula & Constants — SSoT:** [verification-layers.md § 9](../../rules/qa/verification-layers.md#9-effort-estimation-rom--agile-priority-weighted--istqb-test-level). This section reports the computed table only.

| Test Type | Design (h) | DEV (h) | STAG (h) | PROD (h) | **Total ETA (h)** | **ETA (man-day)** | Depends On |
|-----------|------------|---------|----------|----------|-------------------|-------------------|------------|
| TestChecklist Design | {B} | — | — | — | {E} | {E/8} | — |
| Functional Test | {0.4B} | {0.6B} | — | — | {E} | {E/8} | Design |
| Test Data (one-time) | {0.4B} | {0.6B} | — | — | {E} | {E/8} | ∥ Functional |
| API Test | {0.4B} | {0.6B} | {0.24B} | {0.24B} | {E} | {E/8} | Functional DEV |
| E2E Test | {0.4B} | — | {0.6B} | {0.24B} | {E} | {E/8} | API DEV |
| Security/Pentest | {0.4B} | — | {0.6B} | — | {E} | {E/8} | API+E2E STAG |
| Regression (20%) | — | {0.6B} | — | — | {E} | {E/8} | All pass |
| **TOTAL** | **{Σ Design}** | **{Σ DEV}** | **{Σ STAG}** | **{Σ PROD}** | **{sum E}** | **{sum MD}** | |

<!-- Formula/constants: verification-layers.md §9 (SSoT). Compute in-head; render the table ONLY.
     Do NOT reproduce the computation (no sub-heading, no bullet-list "show work") in the output.
     Skip a row whose §9.3 Condition is false. ROM ±30–50% = planning input, not committed. -->

---

## 7. Change Log

| Date | Ver | Changes | Author |
|------|-----|---------|--------|
| {YYYY-MM-DD} | 1.0 | Initial checklist for login flow | {Git Username} |

---

## 8. AI Usage Log

| # | Date | Command | Input (est.) | Output (est.) | Read Strategy |
|---|------|---------|-------------|---------------|---------------|
| 1 | {YYYY-MM-DD} | /tas-TestChecklist | ~{N}k | ~{N}k | Full / Partial / Version-only |
| **Total** | | | **~{N}k** | **~{N}k** | |

---

## END OF TEMPLATE

Questions? Contact the PE owner (per `tas.yaml` → `roles`).
