---
title: "QA y datos de prueba"
description: "Un checklist de QA generado desde las specs vivas, pasadas de QA con fecha y datos de prueba de Supabase que no pueden tocar producción."
canonical_url: "https://razcue-agent-kit.vercel.app/es/concepts/qa-and-test-data"
---
# QA y datos de prueba

> Un checklist de QA generado desde las specs vivas, pasadas de QA con fecha y datos de prueba de Supabase que no pueden tocar producción.

Ambas partes son opcionales, se preguntan al instalar (por defecto sí) y se cambian volviendo a ejecutar `init` (`--qa-checklist`, `--test-data`).

## Checklist de QA

`work/qa/checklist.md` se **genera** desde las specs vivas; nunca se edita a mano:

- un ítem por escenario, agrupado por capacidad y requisito;
- la frase EARS, los pasos Given / When / Then, la etiqueta ZOMBIES;
- el fixture de datos de prueba que da los datos del escenario (o "no fixture").

`agent-kit qa sync` lo regenera (y también `checklist.html`); `agent-kit specs merge` lo hace por ti.

## Pasadas de QA

Una pasada de QA es un archivo con fecha en `work/qa/runs/`:

```bash [Terminal]
npx @razcue/agent-kit qa run --env staging
```

Rellena **Result** (`pass` · `fail` · `blocked` · `n/a`) y **Note** para cada escenario. O abre `work/qa/checklist.html` en el navegador, registra ahí los resultados (se guardan en el navegador) y usa **Export run** para guardar el mismo archivo.

`agent-kit qa status` muestra el último resultado por escenario. Cada pasada guarda el hash del texto del escenario, así que uno que cambió después de pasar aparece como **re-check** y uno nunca probado como **never run**.

## Datos de prueba (Supabase)

Los proyectos con Supabase reciben `supabase/test-data/` (ruta y prefijo configurables):

<table>
<thead>
  <tr>
    <th>
      Archivo
    </th>
    
    <th>
      Qué es
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        env.sql
      </code>
    </td>
    
    <td>
      Crea <code>
        public._env
      </code>
      
      : qué entorno es una base de datos. Ejecútalo en <strong>
        todos
      </strong>
      
       los entornos y fija el valor una vez.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        seed.sql
      </code>
    </td>
    
    <td>
      Crea los datos de prueba mediante las RPCs de la app. Una transacción.
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        purge.sql
      </code>
    </td>
    
    <td>
      Borra solo las filas de prueba, primero las hijas. Una transacción.
    </td>
  </tr>
</tbody>
</table>

Reglas que aplican los scripts y la skill del stack:

- **Primero la guarda _env.** Ambos scripts se niegan salvo que `_env` diga `dev`, `test` o `staging`: sin fila o con `production` no cambia nada.
- **Solo filas marcadas.** Cada fila empieza con el prefijo (`TEST_`); purge compara con `starts_with()`, nunca con `LIKE`.
- **Mediante las RPCs**, para que saldos, inventario y auditoría queden coherentes.
- **Fechas relativas** (`current_date - 30`).
- **Fixtures por escenario, elegidos con ZOMBIES**: `-- @fixture invoices.R2.S3 @boundary`. `agent-kit qa gaps` lista los escenarios sin fixture y los fixtures que nombran escenarios desconocidos.

Preflight avisa cuando cambian las migraciones y ni seed ni purge cambian. Mira la [guía de datos de prueba](https://razcue-agent-kit.vercel.app/es/guides/test-data) para aplicarlos.


## Sitemap

See the full [sitemap](https://razcue-agent-kit.vercel.app/sitemap.md) for all pages.