Que Es el Smoke Testing?

El smoke testing, tambien conocido como Build Verification Testing (BVT), es un test rapido y amplio de la funcionalidad mas critica para determinar si un nuevo build es lo suficientemente estable para testing mas profundo. El nombre viene del testing de hardware — al encender una placa de circuito nueva, primero verificas si sale humo. Si sale, no tiene sentido probar nada mas.

En software, el smoke testing responde una pregunta: “Este build esta fundamentalmente roto, o podemos proceder con testing mas profundo?”

Un smoke test no busca cada bug ni ejercita cada feature. Verifica que las funciones esenciales funcionan — la aplicacion inicia, los usuarios pueden loguearse, la pagina principal carga, los flujos centrales son accesibles. Si el smoke test falla, el build se rechaza. Si pasa, QA procede con testing de sistema y regresion.

Smoke Testing vs Otros Tests Rapidos

TipoPropositoAlcanceCuando
SmokeEl build es estable?Amplio pero superficialDespues de cada build
SanityEl fix funciono?Estrecho y enfocadoDespues de cambios especificos
RegresionAlgo se rompio?CompletoAntes del release

Que Incluir en una Suite de Smoke Tests

Una suite de smoke tests debe ser:

  • Pequena: 5-20 casos de prueba
  • Rapida: Completar en menos de 10 minutos
  • Critica: Cubrir solo funcionalidad mas importante
  • Automatizada: Ejecutar sin intervencion humana en CI/CD

Smoke Tests para Aplicaciones Web

  1. Aplicacion carga — Homepage retorna HTTP 200 y renderiza correctamente
  2. Login funciona — Usuario puede autenticarse con credenciales validas
  3. Navegacion principal — Items de menu primarios son accesibles
  4. Feature core 1 — Funcion primaria funciona (ej: busqueda retorna resultados)
  5. Feature core 2 — Funcion secundaria funciona (ej: agregar al carrito)
  6. Conectividad BD — Aplicacion lee y escribe en base de datos
  7. Assets estaticos — CSS, JavaScript e imagenes cargan
  8. Manejo de errores — Pagina de error apropiada (no stack trace) para 404

Smoke Tests para Apps Mobile

  1. App inicia — Aplicacion abre sin crashear
  2. Login — Usuario puede iniciar sesion
  3. Pantalla principal — Contenido core se muestra
  4. Navegacion — Tab bar / drawer funciona
  5. Requests de red — Llamadas API exitosas
  6. Notificaciones push — Registro de notificaciones exitoso
  7. Accion core — Accion principal del usuario completa

Smoke Tests para APIs

  1. Endpoint de salud — GET /health retorna 200
  2. Autenticacion — Token valido retorna 200; invalido retorna 401
  3. GET core — Operacion de lectura principal retorna estructura esperada
  4. POST core — Operacion de escritura principal crea recurso
  5. Operaciones BD — CRUD completa sin errores
  6. Integraciones externas — Conexiones a servicios de terceros activas
  7. Formato de respuesta — API retorna JSON/XML correctamente formateado

Smoke Testing en CI/CD

Los smoke tests automatizados son la primera puerta de calidad en un pipeline:

graph LR CODE[Commit de Codigo] --> BUILD[Build] BUILD --> SMOKE[Smoke Tests] SMOKE -->|Pasa| UNIT[Unit Tests] UNIT --> INT[Tests Integracion] INT --> DEPLOY[Deploy a Staging] DEPLOY --> E2E[Tests E2E] SMOKE -->|Falla| REJECT[Rechazar Build
Notificar Desarrollador] style SMOKE fill:#eab308,color:#000 style REJECT fill:#ef4444,color:#000

Beneficios en CI/CD:

  • Feedback rapido: Desarrolladores saben en minutos si su cambio rompio el build
  • Ahorra tiempo: Previene que QA gaste horas probando un build roto
  • Funcion de puerta: Bloquea despliegue de builds inestables
  • Confianza: El equipo sabe que cada build desplegado tiene funcionalidad basica confirmada

Mejores Practicas

Ejecutar en cada build. No solo nocturnos — en cada commit o al menos cada merge de PR.

Mantenerlos rapidos. Si toman 30 minutos, pierden su valor. Menos de 10 minutos es ideal.

Nunca saltarlos. Cuando la presion de lanzamiento aumenta, los smoke tests parecen un retraso. No lo son — son la red de seguridad.

Mantener agresivamente. Un smoke test que falla siempre debe indicar un problema real. Arreglar tests inestables inmediatamente.

Ejercicio: Crea un Checklist de Smoke Tests para una Web App

Eres QA Lead para una aplicacion web de gestion de proyectos (similar a Jira/Asana) con:

  • Autenticacion (email/contrasena y SSO)
  • Creacion y gestion de proyectos
  • Creacion de tareas con asignados, fechas y prioridades
  • Tablero Kanban con drag-and-drop
  • Archivos adjuntos en tareas
  • Notificaciones (in-app y email)
  • Dashboard de reportes con graficos
  • Busqueda en proyectos y tareas

Crea un checklist de 10-15 smoke tests. Para cada uno: nombre, pasos y resultado esperado.

PistaEnfocate en el happy path de flujos criticos. Preguntate: "Si esta funcion estuviera rota, la aplicacion seria inutilizable?" Si si, pertenece al smoke test.
Solucion

Prioridad 1: Aplicacion Viva

  1. Homepage carga — Navegar a URL → Pagina de login renderiza, HTTP 200
  2. Login con email — Credenciales validas → Dashboard carga
  3. Login SSO — Click “Iniciar con Google” → Dashboard carga

Prioridad 2: Features Core 4. Crear proyecto — “Nuevo Proyecto” → Nombre → Guardar → Aparece en lista 5. Crear tarea — Abrir proyecto → “Nueva Tarea” → Titulo, asignar, fecha → Aparece en Kanban 6. Kanban carga — Abrir tablero con tareas existentes → Columnas y tarjetas correctas 7. Busqueda funciona — Buscar “Smoke Test” → Resultados incluyen proyecto/tarea creados

Prioridad 3: Features de Soporte 8. Subir archivo — Abrir tarea → Adjuntar archivo → Aparece en lista de adjuntos 9. Notificaciones — Asignar tarea a otro usuario → Notificacion aparece 10. Dashboard carga — Navegar a Reportes → Graficos renderizan con datos

Prioridad 4: Manejo de Errores 11. Logout funciona — Menu perfil → “Cerrar Sesion” → Redireccion a login 12. 404 personalizado — URL invalida → Pagina 404 personalizada (no error de servidor) 13. Error de API apropiado — Acceder proyecto inexistente → “No encontrado”

Total: 13 smoke tests, tiempo estimado: 8-10 min (automatizado), 15-20 min (manual)

Anti-Patrones del Smoke Testing

Anti-patron 1: Demasiados tests. Si tu suite tiene 100 tests y toma una hora, es una suite de regresion disfrazada. Mantener bajo 20.

Anti-patron 2: Tests que nunca fallan. Si no han detectado un build roto en un ano, pueden estar probando cosas incorrectas.

Anti-patron 3: Solo manual. Manual es mejor que nada, pero es lento e inconsistente. Automatizar para CI/CD.

Anti-patron 4: Ignorar fallas. “Ese test siempre falla los lunes” indica un problema profundo. Cada falla debe investigarse.

Tips Profesionales

Tip 1: Tu smoke test es tu confianza de despliegue. Si no desplegarias a produccion despues de que el smoke test pasa, esta incompleto.

Tip 2: No son solo para QA. Desarrolladores deben ejecutarlos localmente antes de push. Esto detecta builds rotos antes del CI.

Tip 3: Incluir chequeos de infraestructura. BD caida, CDN mal configurado, certificado SSL expirado — incluir health checks basicos.

Conclusiones Clave

  • Smoke testing es un chequeo rapido y amplio para determinar estabilidad del build
  • Incluir solo funcionalidad critica (5-20 tests, menos de 10 minutos)
  • Automatizar e integrar en CI/CD como primera puerta de calidad
  • Ejecutar en cada build — son la red de seguridad contra despliegues rotos
  • Diferentes aplicaciones necesitan composiciones de smoke tests diferentes
  • Mantener agresivamente — tests inestables o ignorados son peores que ninguno