Catálogo de fallos: qué probar antes que la IA

El catálogo de fallos es la pieza que separa a un tester experto de uno que solo mira la superficie y dice que todo se ve bien. Si le pides tests a la IA de entrada, obtienes happy paths decorados. La clave está en definir primero qué probar, y eso te toca a ti, porque entiendes el negocio.

Esto es para quienes escriben pruebas asistidas por IA y quieren que cubran los puntos que de verdad importan, no los fáciles.

Por qué escribir el test dejó de ser lo caro

El trabajo cambió de lugar. Antes lo costoso era escribir el código del test. Hoy escribirlo toma segundos y lo escaso es saber qué probar.

Por eso en esta etapa no escribimos ni una línea de test. En su lugar llenamos el failures mode, ese archivo que dejamos casi vacío y que va a convertirse en el corazón del proceso [00:15].

El catálogo de fallos es una lista de verificación con doble función:

• Como semilla de prompts: cada modo de falla se convierte en una instrucción concreta que la IA usa para generar el test que lo cubre.
• Como rúbrica de calificación: cuando la IA devuelve una suite, el catálogo es la regla contra la que mides si cumplió o si se quedó con lo fácil [00:52].

Y aquí viene lo interesante: el catálogo lo lideras tú, la IA solo te ayuda a explorar.

¿Qué es un catálogo de fallos? Es una lista de verificación con los modos en que un módulo puede fallar. Sirve para generar tests dirigidos y para calificar si esos tests cubrieron lo importante.

Cuáles son las familias clásicas de modos de falla

Existen familias que se repiten en el diseño de pruebas y que funcionan como referencia para estructurar todo. No son sobre la IA, son sobre el dominio [02:20].

1. Valores de frontera: qué pasa justo en el límite. Cuando amount es cero, en un céntimo mínimo, en el máximo permitido [01:32].
2. Particiones de equivalencia: qué clase de entrada se comporta distinto. Un valor positivo, uno cero, uno negativo, uno no numérico [01:47].
3. Null o vacío: qué pasa si falta el dato. Si user ID es none, si hay una divisa ausente, un cuerpo vacío [02:00].
4. Condiciones de carrera: qué pasa si ocurre dos veces a la vez. Por ejemplo, un doble reintento del SDK sin idempotencia [02:08].
5. Bypass de autorización: puede actuar quien no debería. Por ejemplo, reembolsar a una cuenta que no es la tuya [02:15].

Estas cinco categorías son sobre el negocio, no sobre la herramienta. Por eso quien entiende el negocio de pagos manda, y la IA explora.

Cómo pedirle a la IA que explore en vez de generar tests

En lugar de pedir tests directamente, le damos a la IA un trabajo de exploración más profundo. Se hizo para amounts.py, pero aplica a todos los módulos importantes que quieras testear [03:00].

El prompt pide algo distinto:

text No escribas test. Recorre amounts.py y enumera todos los modos de falla agrupados por frontera, equivalencia, null/vacío y contrato de negocio. Para cada modo de falla entrega: un ID, categoría, riesgo, entrada que lo dispara, comportamiento actual observado, contrato esperado recomendado, estado del contrato (confirmado / pendiente de decisión) y por qué importa para pagos.

La instrucción incluye una regla decisiva: no asumas que la implementación actual es correcta. Si no puedes inferir el contrato de negocio, márcalo como pendiente en vez de convertir el comportamiento actual en especificación [03:50].

Esto importa porque luego será tu tarea confirmar cuál debe ser el comportamiento real, y ahí es donde encuentras y resuelves bugs [04:15].

¿Por qué no dejar que la IA asuma el contrato de negocio? Porque convertiría el comportamiento actual en especificación, incluso si ese comportamiento es un bug. Marcarlo como pendiente obliga a una decisión humana.

Qué distingue un fallo confirmado de uno pendiente de decisión

La IA devolvió un catálogo curado con alrededor de 12 modos de falla, divididos por las categorías pedidas. Algunos quedaron confirmados y otros pendientes [04:30].

El caso confirmado fue el N2 de null o vacío. En normalize_currency, cuando llega un entero o una lista en lugar de un string, el código lanza un attribute error sin capturar en vez de un currency error. Es una inconsistencia observable, no necesita decisión de negocio [05:00].

El caso pendiente fue el B2, de frontera: el del cero. Cuando el monto es cero, el código retorna fee cero e ignora el mínimo de 30 centavos. La IA no sabe si eso es intencional ni cuál es la política real del negocio, así que decidir sola sería peligroso [05:30].

Esa es exactamente la línea:

• Confirmado: comportamiento claro en el código, sin ambigüedad de negocio.
• Pendiente de decisión: requiere que un humano defina cuál debe ser el contrato real.

Los pendientes son esos bugs inyectados a propósito que necesitan tu firma para resolverse.

Por qué el catálogo se vuelve un activo versionado del repo

Con el resultado ya curado, la IA reemplaza las dos entradas iniciales del failures mode por un catálogo estructurado por categoría y por módulo [06:10].

Ahora ese archivo es un activo del repo, versionado y con tu firma encima de las decisiones de negocio que lo requieran [06:40]. Eso significa que:

• Alimenta el prompt que generará tests que cubran los puntos álgidos.
• Sirve como rúbrica para calificar lo que la IA produzca.
• Se mantiene como fuente de verdad para futuras iteraciones.

En la siguiente etapa este catálogo se convierte en el motor de un prompt que sí genera tests útiles, usando una estructura de tres capas que no le deja a la IA decidir qué merece probarse [07:05].

¿Ya identificaste los modos de falla críticos de tu propio dominio? Cuéntame en los comentarios cuáles crees que la IA marcaría como pendientes.