# Test Evidence Review

> Revisión de calidad de archivos de test y evidencia manual: evalúa cobertura de aserciones, casos límite, nombres y completitud, dando un veredicto ADEQUATE/INCOMPLETE/MISSING por historia.

Fuente: https://skillsagentes.com/skills/donchitos/claude-code-game-studios/test-evidence-review
Markdown: https://skillsagentes.com/skills/donchitos/claude-code-game-studios/test-evidence-review.md

Repositorio: https://github.com/Donchitos/Claude-Code-Game-Studios
Autor: Donchitos
Licencia: MIT
Actualizado: hace 3 meses
Coste de contexto: 71 tok instalada, 2.2k tok al activarse, 2.2k tok con todos los archivos del bundle
Bundle: 1 archivo, 9 KB
Permisos que pide: read, glob, grep, write

## Instalación

Un skill son archivos markdown: los mismos archivos valen para cualquier agente y lo único que cambia es el directorio de destino, es decir la bandera `--agent`. Añade `-g` para instalarlo en todos los proyectos de la máquina.

```bash
# Claude Code
npx -y skills add Donchitos/Claude-Code-Game-Studios --skill test-evidence-review --agent claude-code
# Cursor
npx -y skills add Donchitos/Claude-Code-Game-Studios --skill test-evidence-review --agent cursor
# Codex
npx -y skills add Donchitos/Claude-Code-Game-Studios --skill test-evidence-review --agent codex
# Gemini CLI
npx -y skills add Donchitos/Claude-Code-Game-Studios --skill test-evidence-review --agent gemini
# Windsurf
npx -y skills add Donchitos/Claude-Code-Game-Studios --skill test-evidence-review --agent windsurf
# Cline
npx -y skills add Donchitos/Claude-Code-Game-Studios --skill test-evidence-review --agent cline
```

## Qué hace

- Revisa la calidad de archivos de test y documentos de evidencia manual, no solo su existencia
- Evalúa cobertura de aserciones, casos límite, convenciones de nombres y trazabilidad de fórmulas
- Revisa linaje de criterios, sign-offs y frescura en evidencia manual (Visual/Feel/UI)
- Asigna un veredicto ADEQUATE/INCOMPLETE/MISSING por historia y genera un reporte
- Ofrece escribir opcionalmente el reporte en production/qa/evidence-review-[date].md

## Cuándo usarla

- Antes del sign-off de QA (/team-qa Fase 5)
- En cualquier historia donde la calidad del test esté en duda
- Como parte de la revisión de milestone para auditar calidad de historias Logic e Integration

## Qué la activa

- "Ejecuta /test-evidence-review sobre la historia del sistema de inventario"
- "Revisa la calidad de las evidencias del sprint actual"
- "Haz un test-evidence-review del sistema de combate"

## Antes de instalar

- Requiere que existan historias con secciones Test Evidence y, opcionalmente, sprint plans o epics en production/.
- writes to your files

## Archivos

- SKILL.md — 9 KB

## SKILL.md

Reproducido tal cual desde Donchitos/Claude-Code-Game-Studios bajo MIT. Esta sección es el documento original y está en inglés.

# Test Evidence Review

`/smoke-check` verifies that test files **exist** and **pass**. This skill
goes further — it reviews the **quality** of those tests and evidence documents.
A test file that exists and passes may still leave critical behaviour uncovered.
A manual evidence doc that exists may lack the sign-offs required for closure.

**Output:** Summary report (in conversation) + optional `production/qa/evidence-review-[date].md`

**When to run:**
- Before QA hand-off sign-off (`/team-qa` Phase 5)
- On any story where test quality is in question
- As part of milestone review for Logic and Integration story quality audit

---

## 1. Parse Arguments

**Modes:**
- `/test-evidence-review [story-path]` — review a single story's evidence
- `/test-evidence-review sprint` — review all stories in the current sprint
- `/test-evidence-review [system-name]` — review all stories in an epic/system
- No argument — ask which scope: "Single story", "Current sprint", "A system"

---

## 2. Load Stories in Scope

Based on the argument:

**Single story**: Read the story file directly. Extract: Story Type, Test
Evidence section, story slug, system name.

**Sprint**: Read the most recently modified file in `production/sprints/`.
Extract the list of story file paths from the sprint plan. Read each story file.

**System**: Glob `production/epics/[system-name]/story-*.md`. Read each.

For each story, collect:
- `Type:` field (Logic / Integration / Visual/Feel / UI / Config/Data)
- `## Test Evidence` section — the stated expected test file path or evidence doc
- Story slug (from file name)
- System name (from directory path)
- Acceptance Criteria list (all checkbox items)

---

## 3. Locate Evidence Files

For each story, find the evidence:

**Logic stories**: Glob `tests/unit/[system]/[story-slug]_test.*`
  - If not found, also try: Grep in `tests/unit/[system]/` for files
    containing the story slug

**Integration stories**: Glob `tests/integration/[system]/[story-slug]_test.*`
  - Also check `production/session-logs/` for playtest records mentioning the story

**Visual/Feel and UI stories**: Glob `production/qa/evidence/[story-slug]-evidence.*`

**Config/Data stories**: Glob `production/qa/smoke-*.md` (any smoke check report)

Note what was found (path) or not found (gap) for each story.

---

## 4. Review Automated Test Quality (Logic / Integration)

For each test file found, read it and evaluate:

### Assertion coverage

Count the number of distinct assertions (lines containing assert, expect,
check, verify, or engine-specific assertion patterns). Low assertion count is
a quality signal — a test that makes only 1 assertion per test function may
not cover the range of expected behaviour.

Thresholds:
- **3+ assertions per test function** → normal
- **1-2 assertions per test function** → note as potentially thin
- **0 assertions** (test exists but no asserts) → flag as BLOCKING — the
  test passes vacuously and proves nothing

### Edge case coverage

For each acceptance criterion in the story that contains a number, threshold,
or "when X happens" conditional: check whether a test function name or
test body references that specific case.

Heuristics:
- Grep test file for "zero", "max", "null", "empty", "min", "invalid",
  "boundary", "edge" — presence of any is a positive signal
- If the story has a Formulas section with specific bounds: check whether
  tests exercise at minimum/maximum values

### Naming quality

Test function names should describe: the scenario + the expected result.
Pattern: `test_[scenario]_[expected_outcome]`

Flag functions named generically (`test_1`, `test_run`, `testBasic`) as
**naming issues** — they make failures harder to diagnose.

### Formula traceability

For Logic stories where the GDD has a Formulas section: check that the test
file contains at least one test whose name or comment references the formula
name or a formula value. A test that exercises a formula without mentioning
it by name is harder to maintain when the formula changes.

---

## 5. Review Manual Evidence Quality (Visual/Feel / UI)

For each evidence document found, read it and evaluate:

### Criterion linkage

The evidence doc should reference each acceptance criterion from the story.
Check: does the evidence doc contain each criterion (or a clear rephrasing)?
Missing criteria mean a criterion was never verified.

### Sign-off completeness

Check for three sign-off lines (or equivalent fields):
- Developer sign-off
- Designer / art-lead sign-off (for Visual/Feel)
- QA lead sign-off

If any are missing or blank: flag as INCOMPLETE — the story cannot be fully
closed without all required sign-offs.

### Screenshot / artefact completeness

For Visual/Feel stories: check whether screenshot file paths are referenced
in the evidence doc. If referenced, Glob for them to confirm they exist.

For UI stories: check whether a walkthrough sequence (step-by-step interaction
log) is present.

### Date coverage

Evidence doc should have a date. If the date is earlier than the story's
last major change (heuristic: compare against sprint start date from the sprint
plan), flag as POTENTIALLY STALE — the evidence may not cover the final
implementation.

---

## 6. Build the Review Report

For each story, assign a verdict:

| Verdict | Meaning |
|---------|---------|
| **ADEQUATE** | Test/evidence exists, passes quality checks, all criteria covered |
| **INCOMPLETE** | Test/evidence exists but has quality gaps (thin assertions, missing sign-offs) |
| **MISSING** | No test or evidence found for a story type that requires it |

The overall sprint/system verdict is the worst story verdict present.

```markdown
## Test Evidence Review

> **Date**: [date]
> **Scope**: [single story path | Sprint [N] | [system name]]
> **Stories reviewed**: [N]
> **Overall verdict**: ADEQUATE / INCOMPLETE / MISSING

---

### Story-by-Story Results

#### [Story Title] — [Type] — [ADEQUATE/INCOMPLETE/MISSING]

**Test/evidence path**: `[path]` (found) / (not found)

**Automated test quality** *(Logic/Integration only)*:
- Assertion coverage: [N per function on average] — [adequate / thin / none]
- Edge cases: [covered / partial / not found]
- Naming: [consistent / [N] generic names flagged]
- Formula traceability: [yes / no — formula names not referenced in tests]

**Manual evidence quality** *(Visual/Feel/UI only)*:
- Criterion linkage: [N/M criteria referenced]
- Sign-offs: [Developer ✓ | Designer ✗ | QA Lead ✗]
- Artefacts: [screenshots present / missing / N/A]
- Freshness: [dated [date] — current / potentially stale]

**Issues**:
- BLOCKING: [description] *(prevents story-done)*
- ADVISORY: [description] *(should fix before release)*

---

### Summary

| Story | Type | Verdict | Issues |
|-------|------|---------|--------|
| [title] | Logic | ADEQUATE | None |
| [title] | Integration | INCOMPLETE | Thin assertions (avg 1.2/function) |
| [title] | Visual/Feel | INCOMPLETE | QA lead sign-off missing |
| [title] | Logic | MISSING | No test file found |

**BLOCKING items** (must resolve before story can be closed): [N]
**ADVISORY items** (should address before release): [N]
```

---

## 7. Write Output (Optional)

Present the report in conversation.

Ask: "May I write this test evidence review to
`production/qa/evidence-review-[date].md`?"

This is optional — the report is useful standalone. Write only if the user
wants a persistent record.

After the report:

- For BLOCKING items: "These must be resolved before `/story-done` can mark the
  story Complete. Would you like to address any of them now?"
- For thin assertions: "Consider running `/test-helpers [system]` to see
  scaffolded assertion patterns for common cases."
- For missing sign-offs: "Manual sign-off is required from [role]. Share
  `[evidence-path]` with them to complete sign-off."

Verdict: **COMPLETE** — evidence review finished. Use CONCERNS if BLOCKING items were found.

---

## Collaborative Protocol

- **Report quality issues, do not fix them** — this skill reads and evaluates;
  it does not modify test files or evidence documents
- **ADEQUATE means adequate for shipping, not perfect** — avoid nitpicking
  tests that are functioning and comprehensive enough to give confidence
- **BLOCKING vs. ADVISORY distinction is important** — only flag BLOCKING when
  the gap leaves a story criterion genuinely unverified
- **Ask before writing** — the report file is optional; always confirm before writing

## Dónde encaja

- Categoría: [Testing y QA](https://skillsagentes.com/categorias/testing-qa.md) — Flujos de testing unitario, de integración y end-to-end.
- Creador: [Donchitos](https://skillsagentes.com/creators/donchitos.md) — 73 skills en el directorio
- [Todas las skills](https://skillsagentes.com/skills.md)
- [Ranking de instalaciones](https://skillsagentes.com/ranking.md)

## Otras skills del mismo repositorio

- [Team Qa](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/team-qa.md): Orquesta al equipo de QA (qa-lead y qa-tester) para producir un paquete completo de QA: plan de pruebas, smoke check, casos de prueba, ejecución manual y reporte de sign-off.
- [Consistency Check](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/consistency-check.md): Compara todos los GDDs contra el registro de entidades para detectar inconsistencias entre documentos: mismo stat, ítem o fórmula con valores distintos, usando un enfoque grep-first.
- [Create Architecture](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/create-architecture.md): Redacción guiada, sección por sección, del documento de arquitectura maestro del juego, consciente de la versión del motor y de sus posibles brechas de conocimiento.
- [Day One Patch](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/day-one-patch.md): Prepara un patch day-one para el lanzamiento de un juego: define alcance, prioriza, implementa y valida con un QA gate ligero, como un mini-sprint con plan de rollback.
- [Hotfix](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/hotfix.md): Flujo de arreglo urgente que se salta el proceso normal de sprint pero deja rastro de auditoría completo: crea rama hotfix, registra aprobaciones y asegura el backport correcto.

---

Skills Agentes · [Índice de páginas en markdown](https://skillsagentes.com/sitemap.md) · [Inicio](https://skillsagentes.com/index.md)