Respuesta.

Historia de la pregunta:

Las pruebas manuales se basaban originalmente en la costumbre de probar solo aquellos escenarios que cumplían con los requisitos y el comportamiento esperado del sistema (los llamados "escenarios positivos"). Con el tiempo, se hizo evidente que el software a menudo fallaba precisamente en condiciones inesperadas o erróneas para las cuales no se había planificado.

Problema:

Solo los escenarios positivos no garantizan la estabilidad y fiabilidad de la aplicación. Si no se prueban escenarios negativos (por ejemplo, entradas incorrectas, acciones no válidas), se pueden pasar por alto defectos graves que se manifestarán en los usuarios reales.

Solución:

Realizar ambos tipos de pruebas:

Pruebas positivas — verifican si el sistema funciona de acuerdo con los requisitos en datos y acciones del usuario correctos.
Pruebas negativas — prueban la estabilidad y resistencia del sistema ante acciones y datos erróneos, inusuales o incorrectos.

Características clave:

No se puede garantizar la calidad solo con un tipo de prueba.
Las pruebas negativas ayudan a encontrar errores que son menos comunes durante el uso habitual.
Los casos positivos se basan en los requisitos, los negativos — en su violación.

Preguntas trampa.

¿Se puede ignorar la prueba negativa si el producto supera un conjunto completo de escenarios positivos?

No. Los errores que surgen en escenarios negativos a menudo tienen un impacto crítico en la seguridad y fiabilidad del producto.

¿Es obligatorio que las pruebas negativas conduzcan a errores del programa?

No, un programa bien diseñado en escenarios negativos debería manejar correctamente los datos erróneos, sin "caerse" y sin producir resultados incorrectos.

¿Es igualmente importante escribir pruebas positivas y negativas para todas las partes del sistema?

No, a veces para partes no críticas o consolidadas del sistema se puede reducir el número de escenarios negativos, pero para lugares vulnerables y críticos, esto es una necesidad.

Errores comunes y anti-patrones

Ignorar completamente los escenarios negativos.
Pruebas negativas demasiado superficiales (por ejemplo, solo se verificó una entrada incorrecta).
No entender la diferencia entre pruebas positivas y negativas.

Ejemplo de la vida real

Caso negativo

En la empresa, al probar el formulario de registro en el sitio, solo se verificaron valores correctos (correo electrónico válido, contraseñas, etc.), sin tener en cuenta variantes erróneas.

Ventajas:

Desarrollo y pruebas rápidas.

Desventajas:

Después del lanzamiento, los usuarios pudieron enviar el formulario con correos electrónicos no válidos, lo que llevó a fallos en el envío y comentarios negativos.

Caso positivo

El probador agregó pruebas para la entrada de correos electrónicos no válidos, contraseñas demasiado cortas y largas, y caracteres especiales en todos los campos.