¿Qué son las pruebas de humo (smoke testing)?

¿Qué son las pruebas de humo?

Las pruebas de humo (smoke testing) son un conjunto rápido y superficial de comprobaciones que se ejecuta sobre una nueva versión para confirmar que sus funciones más críticas funcionan antes de invertir tiempo en pruebas más profundas. Si la aplicación no arranca, falla el inicio de sesión o un endpoint clave devuelve un error, la versión se rechaza en el acto. También se conocen como pruebas de verificación de compilación (BVT).

Esta página ofrece la definición breve. La guía completa, con un ejemplo de flujo de compra y cómo automatizar una batería de pruebas, está en el blog (en inglés): smoke testing in software testing.

Qué comprueba una prueba de humo

Una prueba de humo cubre amplitud, no profundidad. Toca una vez cada ruta crítica para el negocio y sigue adelante.

• La aplicación arranca y su endpoint de salud responde con 200.
• Un usuario puede iniciar sesión.
• Funciona la ruta principal, por ejemplo buscar, añadir al carrito y abrir la página de pago.
• La aplicación llega a la base de datos, la caché y la cola sin agotar el tiempo de espera.
• Los archivos principales de JavaScript y CSS cargan con un 200 y no con un 404.

Las reglas de validación, los casos límite, las comprobaciones de seguridad y el comportamiento bajo carga no son materia de una prueba de humo. Les corresponden las pruebas de regresión, las pruebas funcionales y las pruebas de carga.

Cuándo ejecutarla

1. En cada compilación de CI, como primera etapa. Si falla, el resto del pipeline no se ejecuta.
2. Después de cada despliegue en preproducción o producción, antes de dirigir tráfico a la nueva versión.
3. Tras cambios de infraestructura como un nuevo registro DNS, un certificado TLS o una conmutación de base de datos, aunque el código no haya cambiado.
4. Antes de una prueba de carga. Una prueba de 30 minutos contra una versión cuyo inicio de sesión ya está roto solo produce ruido.

Ejemplo

Una tienda online despliega una nueva versión. La batería de humo pide la página de inicio, hace una búsqueda, añade un producto al carrito, abre la página de pago y consulta el endpoint de salud. Cinco comprobaciones, cada una una sola vez, que terminan en segundos o en un par de minutos. Si la página de pago devuelve un 500, el despliegue se detiene y el equipo analiza ese único fallo, en lugar de leer cientos de resultados en rojo de una regresión completa.

Pruebas de humo, de cordura y de regresión

• Las pruebas de humo son amplias y superficiales: ¿está esta versión lo bastante viva como para seguir probándola?
• Las pruebas de cordura (sanity testing) son acotadas: tras una corrección pequeña, ¿se comporta bien esa zona concreta?
• Las pruebas de regresión son amplias y profundas: ¿ha roto este cambio algo que antes funcionaba? Se ejecutan cuando el humo ha pasado.

Pruebas de humo para APIs y aplicaciones web

Para un servicio HTTP, una prueba de humo puede ser un puñado de peticiones con aserciones sobre el estado y el cuerpo. En k6 significa un usuario virtual, una iteración y un check() por petición. En JMeter es un grupo de hilos con un hilo y un bucle, más una aserción de respuesta en cada sampler. En proyectos Java, etiquetar las pruebas críticas con un grupo de TestNG da un conjunto de humo que se puede ejecutar por separado.

Una prueba de humo lanzada desde un portátil no demuestra que el DNS público, la CDN y la cadena de certificados funcionen. Las mismas comprobaciones desde la nube contra la URL pública sí. La monitorización de APIs programada es, en la práctica, una prueba de humo que nunca se detiene: LoadFocus API Monitoring ejecuta tus peticiones críticas de forma programada desde la nube y te avisa cuando una falla. Para la prueba de carga que viene después del humo, consulta las pruebas de carga con k6.

Errores habituales

• Dejar crecer la batería. Cuando tarda diez minutos ya es una suite de regresión y nadie la ejecuta primero.
• Tolerar comprobaciones inestables. Una prueba de humo que falla al azar enseña al equipo a ignorarla.
• Confundir verde con correcto. Pasar significa que la versión merece más pruebas, no que no tenga errores.
• Ejecutarla solo dentro de tu propia red, lo que oculta problemas de DNS, CDN y certificados.
• No actualizarla nunca. Cuando sale un flujo crítico nuevo, añádelo; cuando se retira uno, quítalo.

Preguntas frecuentes sobre las pruebas de humo

¿Son lo mismo las pruebas de humo y las pruebas de verificación de compilación?

Sí. Build verification testing (BVT) y build acceptance testing son otros nombres de la misma práctica: una comprobación rápida de que una nueva versión es lo bastante estable para pasar a pruebas más profundas.

¿Cuánto debería durar una prueba de humo?

De segundos a un par de minutos. Si tu batería tarda diez minutos, divídela y deja como humo solo las comprobaciones realmente críticas.

¿Deben automatizarse las pruebas de humo?

Sí, siempre que exista un pipeline, porque una puerta que bloquea compilaciones no puede esperar a una persona. Una lista de comprobación vale para un proyecto joven, pero toda comprobación que repites en cada versión debería automatizarse.

¿Qué diferencia hay entre pruebas de humo y pruebas de cordura?

Las pruebas de humo son amplias y superficiales y se ejecutan en cada versión. Las de cordura son acotadas y se ejecutan tras un cambio concreto para confirmar que esa zona funciona ahora.

¿Se pueden ejecutar pruebas de humo en producción?

Sí, con acciones de solo lectura o de prueba claramente marcadas. Ejecutadas tras un despliegue, o de forma continua como monitor programado, confirman que la versión está atendiendo de verdad a los usuarios.

¿Una prueba de humo superada significa que el software no tiene errores?

No. Solo significa que la versión es lo bastante estable para justificar pruebas más profundas. Los casos límite, los errores de lógica y los problemas de rendimiento requieren pruebas de regresión, funcionales y de carga.