Respuesta.

La automatización de escenarios negativos es una parte integral de un sistema de pruebas completo. Estas son validaciones que ponen a prueba la resistencia del sistema a acciones erróneas, datos incorrectos, fallos en los servicios y otras situaciones excepcionales.

Historia de la pregunta:

Anteriormente, se prestaba atención principalmente a los escenarios positivos (happy paths), porque son más fáciles de automatizar y mantener. Sin embargo, las exigencias de calidad han aumentado, y cada vez más errores ocurren precisamente en los límites, con condiciones erróneas o poco claras. Las pruebas manuales se vuelven obsoletas rápidamente, mientras que la automatización permite rastrear degradaciones.

Problemas:

Definir y cubrir todos los posibles escenarios negativos
Verificar correctamente los mensajes de error y la validez del estado del sistema después de un fallo en la operación
Mantener las pruebas al cambiar la lógica del negocio

Solución:

Identificar y sistematizar escenarios negativos (Boundary Value Analysis, Equivalence Partitioning)
Utilizar asserts y validadores personalizados para verificar los textos de errores, códigos HTTP, excepciones
"Limpiar" automáticamente el estado del sistema después de una prueba negativa

Características clave:

Establecimiento explícito de pruebas para errores, excepciones, datos de entrada no estándar
Verificación del mensaje de error y el estado interno del sistema
Control de efectos secundarios: después de una prueba negativa, el sistema debe permanecer en un estado consistente

Preguntas capciosas.

¿Es suficiente verificar solo qué errores se devuelven durante las pruebas negativas?

No. Es importante verificar no solo el contenido del error, sino también que después de un error no se haya modificado el estado del sistema (por ejemplo, que no se haya añadido un registro incorrecto en la base de datos).

¿Es necesario automatizar todos los posibles escenarios negativos?

No. Pueden ser infinitos; es necesario identificar los más probables y críticos (Boundary Value, Null/Empty, tipo incorrecto, inyecciones SQL, etc.), y los demás según vayan surgiendo errores.

¿Se puede usar el mismo tratamiento para todos los casos negativos?

No. Diferentes escenarios negativos requieren distintas verificaciones, manejo de excepciones y rollback; los asserts de plantilla no son suficientes.

Errores típicos y anti-patrones

Ignorar escenarios negativos o cubrirlos "por cumplir"
Verificación poco convincente de errores (por ejemplo, solo el código 500, pero no verificar el texto o el efecto secundario)
Entorno de prueba no limpiado después de una caída de prueba

Ejemplo de la vida real

Caso negativo

En el sistema solo se prueban escenarios de registro válidos. El registro con un email vacío no se prueba de forma automatizada. Como resultado, el problema de poder registrar un usuario con un correo vacío solo se nota en producción.

Ventajas:

Mantenimiento sencillo de las pruebas
Pocas pruebas automatizadas y ejecución rápida

Inconvenientes:

Se pasan por alto errores críticos
Aumentan los costos de corrección y retroceso

Caso positivo

Para cada escenario negativo (falta de email, formato incorrecto, inyección SQL) hay una prueba automatizada que verifica claramente la ausencia de una nueva cuenta y el contenido del mensaje de error.