¿Qué es smoke testing?

¿Qué es smoke testing?

Smoke testing es un conjunto rápido y superficial de checks que corre contra un build fresco para confirmar que el sistema es estable lo suficiente para merecer testing más profundo. El nombre viene de la QA de hardware: enciende la placa; si sale humo, para. En software, responde una sola pregunta: ¿ha roto el build algo tan fundamental que ningún test posterior dará señal útil?

Un smoke test ejercita solo las rutas más críticas. La home renderiza. Login funciona. Un endpoint core de API devuelve 200. La conexión a base de datos abre. Si cualquiera falla, el build se rechaza y el resto de la test suite se salta, ahorrando minutos de CI y sacando la regresión en segundos en lugar de tras un full run de 40 minutos.

Smoke testing vs regression testing vs QA completo

Tres círculos concéntricos de cobertura, cada uno responde una pregunta distinta:

• Smoke testing: ¿es el build ejecutable siquiera? Segundos a un par de minutos. Corre primero.
• Regression testing: ¿ha roto este cambio algo que antes funcionaba? Minutos a una hora. Corre tras pasar smoke.
• QA completo / acceptance testing: ¿cumple cada feature aún la spec? Horas, a menudo manual. Corre menos a menudo.

Smoke es el gate. Saltárselo significa que una regresión de deploy roto se cuela en la regression suite y quema el presupuesto entero de CI antes de que el fallo siquiera se reporte.

Qué cubre un smoke test

• Arranque de aplicación. El proceso bootea sin crashear. El health endpoint devuelve 200.
• User flows críticos. Sign-in, la ruta de feature principal, checkout (si hay commerce), una llamada API contra el endpoint más usado.
• Handshake de integración. La app conecta con su base de datos, caché, message queue. Sin timeouts en boot.
• Disponibilidad de assets estáticos. El bundle principal de JS y CSS cargan desde CDN con un 200, no un 404 por mismatch de hash viejo.
• Sanidad de configuración. Las env vars requeridas resuelven. Sin undefined en el HTML renderizado.

Lo que un smoke test no cubre: edge cases, errores de validación, cada rama de un workflow, rendimiento bajo carga. Eso pertenece a regression o a un load test.

Cuándo ejecutar un smoke test

1. En cada build de CI. Primera etapa del pipeline. Si falla, el pipeline para y nada más corre.
2. Post-deploy a staging o producción. Confirma que el deploy realmente arrancó antes de enrutar tráfico hacia él. Los deploys blue-green gatean el cut-over en pase de smoke.
3. Tras cambios de infraestructura. DNS nuevo, cert TLS nuevo, nuevo target de failover de base de datos. Smoke verifica que la integración funciona end-to-end.
4. Antes de un load test de release-day. No tiene sentido ejecutar un load test de 30 minutos contra un build cuyo login está roto. Smoke primero, load después.

Características clave de smoke test

• Rápido. Segundos, no minutos. Si smoke tarda 10 minutos, deja de ser smoke y se convierte en una mini regression suite.
• Determinístico. Smoke tests flaky destruyen la confianza en el pipeline. Elimina dependencias de timing, retry solo en red transitoria.
• Bloquea el build. Un smoke test fallido para el pipeline. Sin estado smoke "amarillo".
• Barato de autorizar. Cinco a quince checks HTTP más unas pocas aserciones JS. No sobreingeneerar.

Cómo ejecutar un smoke test

Para servicios basados en HTTP, un script corto de JMeter o k6 con 5-15 requests de critical-path es un harness de smoke sólido. En k6, fija vus: 1, iterations: 1 y añade aserciones check() sobre status y body. En JMeter, usa un Thread Group con 1 usuario, 1 loop y Response Assertions en cada sampler.

Para smoke browser-side, un script de Playwright o Cypress de 60 segundos que se loguee, aterrice en el feature principal y assertee sobre un elemento DOM conocido es suficiente. Cualquier cosa más larga pertenece a regression.

Para smoke de deploy-time contra un entorno cloud real, ejecuta desde LoadFocus. Los smoke tests que corrieron en el portátil de un desarrollador no te dicen si la cadena CDN, DNS y TLS de producción funciona; smoke desde una región cloud contra el endpoint público sí.

Si tu equipo no tiene tiempo de diseñar y mantener harnesses de smoke a través de múltiples servicios, LoadFocus ofrece load testing services donde los ingenieros construyen los scripts de smoke, los cablean en tu CI/CD y los mantienen al día mientras la API surface evoluciona.