¿Construimos el producto correctamente, o construimos el producto correcto?

/docs/testing ya documenta 15 niveles de prueba con sus métricas reales. Esta página no repite ese inventario: lo reclasifica bajo un marco distinto —verificación y validación (IEEE 1012)— que responde una pregunta que el inventario técnico no hace explícita: de esos 15 niveles, ¿cuáles comprueban que el código cumple su propia especificación, y cuáles comprueban que el sistema le sirve a alguien de verdad?

«Testing» suele tratarse como una sola actividad. IEEE 1012 la separa en dos porque tienen oráculos distintos —la fuente de verdad contra la que se compara un resultado— y confundirlos hace que un pipeline en verde se sienta como garantía de algo que nunca prometió.

Verificación y validación responden qué se comprueba. IEEE 1012 responde una segunda pregunta, independiente de esa: cuánto rigor exige cada parte del sistema. La clasifica en 4 niveles según la consecuencia de que ese subsistema falle — no la probabilidad. A mayor nivel, más tareas de V&V son obligatorias. Aplicar el mismo esfuerzo de prueba a una página de contenido y al motor de cobros no sería más riguroso: sería mal presupuestado.

La mayoría de los niveles de este repositorio son verificación, y tiene sentido que lo sean: son baratos, automatizables y no dependen de conseguir a una persona real. El oráculo en todos estos casos lo escribió alguien del equipo antes que el código.

Aquí el oráculo deja de ser un archivo del repositorio. En e2e es una persona simulada completando un objetivo; en accesibilidad, alguien con lector de pantalla; en usabilidad, una persona real y nadie más. Por eso son los niveles más caros de esta lista, y también los que más se parecen a lo que de verdad importa: que el sistema le sirva a alguien.

Tres casos de este repositorio muestran por qué la clasificación de arriba es una decisión, no un hecho objetivo — y por qué conviene decirlo en vez de esconderlo.

Esta página no es el único lugar donde vive V&V — es el mapa que conecta documentos que ya existían por separado. La validación empieza antes que cualquier test: en el caso de uso o la historia que dijo qué necesidad real se estaba resolviendo.

IEEE 1012 no ata las tareas de V&V a «niveles de prueba» — las ata a fases del ciclo de vida del software, desde la gestión del propio plan hasta el mantenimiento. Este repositorio cubre casi todas sin haberlas llamado así nunca; esta tabla es esa traducción, en el orden en que ocurren.

Cuatro comandos, cada uno respondiendo una pregunta distinta. Ninguno necesita nada externo: la suite de Vitest usa libSQL en archivo temporal y la de Playwright siembra su propia base desechable al levantar el servidor.