Respuesta.

Historia de la cuestión:

Las pruebas de smoke (smoke tests, pruebas "de humo") surgieron inicialmente como una forma rápida de asegurarse de que la funcionalidad más básica del sistema funcionara después de la implementación o cambios en el código. Su ideología es "si algo crítico está roto, no tiene sentido ejecutar pruebas detalladas". En la automatización, las primeras pruebas de smoke se implementaron como pequeños scripts manuales para verificar el inicio de la aplicación, el acceso a la pantalla de inicio de sesión y acciones básicas.

Problema:

Las principales dificultades de la automatización de las pruebas de smoke son la correcta aislamiento del conjunto mínimo de escenarios, la alta velocidad de ejecución, la dependencia mínima de componentes inestables (por ejemplo, servicios externos), así como el soporte visual y técnico para su "ligereza y transparencia". Si no se hace esto, la automatización de smoke se vuelve demasiado pesada o con frecuencia produce falsos positivos y requiere un gran mantenimiento.

Solución:

Minimice la cantidad de pruebas de smoke: solo deben incluirse las comprobaciones de los "puntos de entrada" más críticos (por ejemplo, autorización, inicio del módulo principal, disponibilidad de la base de datos).
Saque los pasos inestables y las dependencias externas fuera de los escenarios de smoke o estabilice los entornos con "stub".
Utilice etiquetado (@smoke, Suite('smoke'), etc.) y secciones separadas en la tubería de CI/CD para ejecutar las pruebas de smoke siempre primero.

Características clave:

Los escenarios de smoke deben ejecutarse rápidamente y usar solo la parte más estable de la infraestructura.
Las pruebas automatizadas de clase smoke no deben cubrir detalles de UX o flujos de trabajo complejos.
La automatización de smoke requiere un estricto control de las dependencias y mínimo código de soporte.

Preguntas capciosas.

¿Se pueden agregar escenarios de verificación de lógica edge-case al conjunto de smoke?

No, el conjunto de smoke está destinado solo a verificar la viabilidad y disponibilidad del sistema principal; los casos edge son innecesarios y ralentizarán la ejecución y complicarán el mantenimiento.

¿Es necesario implementar un manejo de errores en múltiples niveles y recuperación en las pruebas de smoke?

A menudo se piensa erróneamente que las pruebas de smoke necesitan mecanismos de recuperación complejos. De hecho, si una prueba de smoke falla, esto indica un problema crítico que debe ser solucionado, no "evitado" en la prueba automatizada.

¿Deben las pruebas de smoke depender de los datos dejados por otras pruebas?

No, las pruebas de smoke no deben depender de ningún dato de prueba externo, y mucho menos de los artefactos de otras pruebas. Este es uno de los principios clave de su fiabilidad.

Errores típicos y anti-patrones.

Sobrecarga de pruebas de smoke: demasiados escenarios, convirtiéndolos en pruebas de regresión.
Duplicación de código entre pruebas de smoke y pruebas automatizadas normales.
Dependencias implícitas: la prueba utiliza datos/artefactos "sucios" de otros escenarios.

Ejemplo de la vida real.

Caso negativo.

Se incluyeron en el conjunto de pruebas de smoke 30 verificaciones diferentes, algunas de las cuales no solo prueban el inicio del sistema, sino también algoritmos complejos y condiciones edge-case. La ejecución del inicio de smoke comenzó a tomar 30 minutos, y periódicamente algunas verificaciones fallaban debido a la inestabilidad del backend.

Ventajas:

Fácil de ver los cuellos de botella del sistema.
Alta cobertura de pruebas inmediatamente después del despliegue.

Desventajas:

Se perdió la esencia de smoke: una compilación "verde" solo se puede obtener después de una larga espera y resolución de problemas que no son esenciales para llevar el sistema a producción.
Difícil de mantener pruebas y distinguir fallos críticos reales.

Caso positivo.

En el grupo de smoke se mantuvo un mínimo estricto: inicio de sesión, apertura de la página principal, consulta a la base de datos, apretón de manos básico de API. El marco de pruebas de smoke opera independientemente de la matriz de pruebas principal y siempre primero en la tubería de CI/CD. Resultados — en un chat separado y siempre disponibles para un diagnóstico rápido.