¿Qué es smoke testing?

Que es el smoke testing?

El smoke testing es un conjunto rapido y superficial de checks que corre contra un build fresco para confirmar que el sistema es lo bastante estable como para merecer testing mas profundo. Ejercita solo las rutas mas criticas, como si la aplicacion arranca, si el login funciona y si un endpoint central responde, y contesta una unica pregunta de si o no: ha roto este build algo tan fundamental que ningun test posterior dara senal util? Si la respuesta es si, el build se rechaza de inmediato y el resto del pipeline se salta, sacando la regresion en segundos en lugar de tras un full run largo.

Origen y significado del termino

El nombre viene de la ingenieria de hardware. Cuando un ingeniero encendia por primera vez una placa recien montada, la preocupacion era simple: si salia humo, la placa estaba defectuosa y no tenia sentido seguir con ningun otro test. El software tomo la metafora casi sin cambios. Un smoke test es el primer encendido de un build. No mide calidad, correccion ni completitud. Solo confirma que el build esta lo bastante intacto como para justificar el tiempo y el coste de las etapas de test mas profundas que siguen. Por eso el smoke testing tambien se llama build verification testing (BVT) o build acceptance testing.

Que cubre el smoke testing y que no

Un smoke test toca a proposito amplitud, no profundidad. Recorre las rutas mas amplias y criticas para el negocio y confirma que cada una esta viva, sin sondear los edge cases dentro de ninguna.

• Arranque de la aplicacion. El proceso bootea sin crashear y el health endpoint devuelve 200.
• User flows criticos. Sign-in, la ruta de feature principal y el checkout de una app de commerce alcanzan un estado exitoso.
• Handshake de integracion. La app conecta con su base de datos, cache y message queue sin timeout en el boot.
• Disponibilidad de assets estaticos. El bundle principal de JavaScript y el CSS cargan desde el CDN con un 200, no un 404 por un hash viejo.
• Sanidad de configuracion. Las variables de entorno requeridas resuelven y no hay undefined en la salida renderizada.

Lo que un smoke test no cubre: errores de validacion, cada rama de un workflow, valores limite, aserciones de seguridad o comportamiento bajo carga. Eso pertenece al regression testing, al testing funcional o a un load test dedicado. Sobrecargar una suite de smoke con estas preocupaciones es la forma mas comun de convertir sin querer un gate de 30 segundos en una mini regression suite lenta.

Cuando corre el smoke testing

1. En cada build de CI. Es la primera etapa del pipeline. Si falla, el pipeline para y ninguna etapa posterior corre.
2. Post-deploy a staging o produccion. Confirma que el deploy realmente arranco antes de enrutar trafico hacia el. Los rollouts blue-green y canary gatean el cut-over en un smoke test que pasa.
3. Tras cambios de infraestructura. Un nuevo registro DNS, un certificado TLS o un target de failover pueden romper la integracion aunque el codigo no cambie. Smoke verifica la ruta end-to-end.
4. Antes de un load test. No tiene valor correr un load test de 30 minutos contra un build cuyo login ya esta roto. Smoke primero, load despues.

Smoke testing vs sanity testing

El smoke y el sanity testing se confunden a menudo porque ambos son rapidos y ambos gatean trabajo mas profundo. La diferencia es el scope y la intencion. El smoke testing es amplio y superficial: toca muchas features criticas una vez cada una para confirmar que todo el build es estable. El sanity testing es estrecho y algo mas profundo: tras un cambio pequeno o un bugfix, comprueba que un area concreta ahora se comporta bien, sin reverificar todo el sistema. El smoke suele estar scriptado y corre en cada build; el sanity es a menudo una comprobacion dirigida, a veces manual, sobre un release candidate concreto.

Smoke testing vs regression testing

El regression testing contesta una pregunta distinta que el smoke: no "es el build ejecutable siquiera?", sino "ha roto este cambio algo que antes funcionaba?" Las suites de regression son amplias y profundas, cubren muchas features y edge cases y tardan minutos a horas. Smoke es el gate rapido que corre primero; regression es el pase minucioso que sigue. La tabla pone las tres practicas lado a lado.

Dimension	Smoke testing	Sanity testing	Regression testing
Pregunta que responde	Es el build ejecutable?	Funciona este fix?	Ha roto el cambio algo previo?
Scope	Amplio, todas las rutas criticas	Estrecho, un area cambiada	Amplio y profundo, muchas features
Profundidad	Superficial, un pase cada una	Enfocado, profundidad media	Profundo, incluye edge cases
Duracion tipica	Segundos a un par de minutos	Minutos	Minutos a horas
Automatizacion	Casi siempre scriptado	A menudo manual o dirigido	Normalmente automatizado
Cuando corre	Primero, en cada build	Tras un cambio concreto	Tras pasar smoke

Smoke tests manuales vs automatizados

Al principio de un proyecto, un smoke test manual puede ser una checklist escrita corta que un desarrollador recorre a mano: abrir la app, loguearse, cargar la pantalla principal, hacer un pedido. Es barato de empezar y no necesita tooling, pero no escala y no puede gatear un pipeline automatizado. En cuanto el build corre en CI, la suite de smoke deberia estar automatizada para poder bloquear un deploy sin un humano en el bucle. Los smoke tests automatizados son codigo: un punado de requests HTTP con aserciones de status y body para servicios, o un script de navegador corto para los flows de cara al usuario. La regla es: lo que comprobarias a mano en cada release es candidato a smoke test automatizado.

Como disenar una suite de smoke test

• Cubre amplitud, no profundidad. Elige las cinco a quince rutas cuyo fallo dejaria el release entero sin valor y comprueba cada una exactamente una vez.
• Se rapido. Apunta a segundos, no minutos. Si la suite pasa de unos minutos, se ha vuelto una regression suite.
• Se deterministico. Los smoke tests flaky destruyen la confianza en el pipeline. Elimina dependencias de timing y haz retry solo en errores de red realmente transitorios.
• Bloquea el build. Un smoke test fallido debe parar el pipeline. No hay estado smoke amarillo.
• Que sea barato de escribir. Unos checks HTTP mas una asercion de navegador corta bastan.

Smoke testing para APIs y web apps

Para servicios HTTP, un script corto con 5 a 15 requests de critical-path es un harness de smoke solido. En una herramienta como k6 fijas un virtual user y una iteracion y anades aserciones check() sobre status y body; en JMeter usas un Thread Group con un usuario y un loop y una Response Assertion por sampler. Clave: un smoke test que corre en el portatil de un desarrollador no prueba que la cadena CDN, DNS y TLS de produccion funcione. Correr los mismos checks desde una region cloud real contra el endpoint publico si lo hace. Aqui es donde el smoke testing continuo y el monitoring se solapan: un monitor de API que golpea tus endpoints criticos de forma programada desde la cloud, como los que puedes construir en LoadFocus API monitoring, es en la practica un smoke test que nunca deja de correr, y detecta un deploy roto o un certificado caducado en minutos. Los equipos que quieren el gate cableado directo al pipeline pueden correr los mismos checks de critical-path desde LoadFocus antes de promover un build a un load test completo.

Beneficios y limitaciones

El beneficio del smoke testing es el rechazo temprano, barato y de alta confianza de builds rotos. Falla rapido, protege las etapas de test mas caras del esfuerzo desperdiciado y da a cada deploy una senal clara de go o no-go. Su limitacion es exactamente su diseno: es superficial a proposito, asi que nunca cazara un bug de logica sutil, un error de limite o un memory leak lento. Un smoke test que pasa significa "el build merece mas testing", no "el build es correcto".

Mejores practicas

• Corre primero y en todas partes. Haz del smoke el gate de apertura de CI y repitelo tras cada deploy a un entorno nuevo.
• Mantenlo implacablemente pequeno. Resiste anadir "solo un check mas"; una suite de smoke inflada acaba saltandose.
• Testea desde donde estan los usuarios. Prefiere correr el smoke post-deploy desde la cloud contra endpoints publicos, no desde un build agent en tu propia red.
• Alerta fuerte ante el fallo. Un smoke test fallido debe bloquear, nunca pasar en silencio un aviso rio abajo.
• Revisa la suite segun cambia el producto. Cuando llega un nuevo flow critico, anadelo a smoke; cuando se retira una ruta, quitala.

FAQ sobre smoke testing

Es el smoke testing lo mismo que el build verification testing?

Si. Build verification testing (BVT) y build acceptance testing son los nombres formales de la misma practica: un conjunto rapido de checks que confirma que un build nuevo es lo bastante estable para seguir a testing mas profundo. El termino smoke testing es mas comun en el dia a dia.

Cuanto deberia durar un smoke test?

Segundos a un par de minutos como mucho. Toda la idea es fallar rapido y gatear el pipeline. Si tu suite de smoke tarda diez minutos, se ha ido a territorio de regression y deberia dividirse.

Los smoke tests deben ser automatizados o manuales?

Automatizados donde exista un pipeline, porque un gate que bloquea el build no puede depender de que haya un humano disponible. Una checklist manual es buen punto de partida para un proyecto joven, pero cualquier check que repitas en cada release deberia volverse un smoke test automatizado.

Cual es la diferencia entre smoke testing y sanity testing?

El smoke testing es amplio y superficial y corre en cada build para confirmar la estabilidad general. El sanity testing es estrecho y algo mas profundo y corre tras un cambio concreto para confirmar que un area ahora funciona.

Pueden correr los smoke tests contra produccion?

Si, y deberian. Los smoke tests post-deploy contra staging o produccion confirman que el release realmente arranco antes de enrutar trafico. Correrlos de forma continua desde la cloud convierte el smoke testing en verificacion de produccion siempre activa.

Un smoke test que pasa significa que el software no tiene bugs?

No. Un smoke test que pasa solo significa que el build es lo bastante estable para justificar mas testing. Es superficial por diseno y no puede cazar errores de logica de edge case, bugs de limite o problemas de rendimiento.