Respuesta.

Historia de la pregunta:

La prueba de humo ("prueba de humo") surgió como una forma rápida de verificar la funcionalidad del sistema después de la construcción. Su objetivo es asegurarse de que las funciones críticas funcionan y que la aplicación, en principio, es adecuada para pruebas más profundas posteriores. En las pruebas manuales, los tests de humo generalmente se llevan a cabo inmediatamente después del despliegue de una nueva versión del producto.

Problema:

La principal dificultad es el tiempo limitado y la necesidad de seleccionar pruebas que realmente sean importantes. A menudo, los evaluadores revisan demasiadas cosas (desperdiciando recursos) o pasan por alto aspectos críticos, lo que puede llevar a que "huecos" se cuelen en el lanzamiento.

Solución:

La correcta organización de la prueba de humo consiste en seleccionar un conjunto mínimo estricto de escenarios que cubran los flujos de usuario más importantes. Estas comprobaciones deben ser claras, rápidas y reproducibles. Por ejemplo:

- Inicio de sesión exitoso del usuario en el sistema
- Capacidad para ejecutar la función principal (por ejemplo, realizar una compra)
- Realización de un pago y recepción de confirmación

Características clave:

Las pruebas de humo cubren solo las funciones vitales
Ejecución rápida, lo que es crítico en lanzamientos frecuentes
Todos los escenarios se realizan manualmente según una lista de verificación aprobada previamente

Preguntas engañosas.

¿Se puede considerar que la prueba de humo es un reemplazo completo de la prueba de regresión?

No, la prueba de humo se centra solo en "funciona - no funciona" para funciones clave. Para encontrar errores graves, pero no obvios, siempre se requiere una prueba de regresión completa.

¿Qué hacer si al menos una prueba de humo no pasa? ¿Debe continuar la prueba?

No, continuar con la prueba no tiene sentido; el equipo informa sobre el problema, el lanzamiento se bloquea hasta que se corrija el error.

¿Deben incluir los tests de humo comprobaciones de escenarios edge-case?

No, los tests de humo no están destinados a comprobar casos extremos. Son solo para confirmar la posibilidad de que las funciones principales del producto funcionen.

Errores típicos y anti-patrones

Realizar pruebas excesivas que no son críticas para la funcionalidad
Falta de documentación sobre las pruebas de humo (el evaluador "mantiene todo en su cabeza")
Ignorar problemas obvios en aras de la "información"

Ejemplo de la vida

Caso Negativo

Se realizó una prueba de humo utilizando una lista de verificación extensa que incluía funciones de poca importancia. Esto tomó mucho tiempo, lo que retrasó el lanzamiento medio día.

Ventajas:

Se identificaron varios errores no evidentes

Desventajas:

Retraso en el lanzamiento
Se gastaron recursos y tiempo en verificaciones poco significativas

Caso Positivo

La prueba de humo se centró solo en los escenarios más críticos. Se identificó rápidamente un error bloqueante y se informó al equipo: el lanzamiento se suspendió hasta que se corrigió.