Smoke Test: la prueba que todo dev debería correr antes de subir código a producción (y que la mayoría ignora)

Viernes a las 6 de la tarde. El equipo acaba de mergear tres PRs seguidos porque el cliente quería la feature antes del fin de semana. Alguien le da deploy. El servidor responde. Todo parece tranquilo.

Dos horas después llega el DM: “oye, la app no carga para nadie”.

El culpable no era la feature nueva. Era que nadie corrió ni la prueba más básica antes de subir. Se olvidaron de verificar que el motor siquiera prendiera.

Eso es exactamente para lo que existe el smoke test, y en 2026 sigue siendo la herramienta más ignorada por equipos pequeños que no tienen QA dedicado.

¿Qué rayos es un smoke test?

El nombre viene de hardware: cuando conectabas una tarjeta nueva y encendías el equipo, si salía humo literal, ya sabías que algo estaba mal. En software es lo mismo pero sin el olor a quemado.

Un smoke test es una prueba superficial y rápida que verifica si las funciones críticas de un sistema responden antes de correr cualquier otra prueba más profunda. La pregunta central es brutal en su simplicidad: ¿prende el motor o no?

No busca que todo funcione perfecto. Busca saber si la app está viva, si el login responde, si la página principal carga, si el API devuelve algo coherente. Si alguna de esas falla, no tiene caso seguir probando nada.

BrowserStack lo define como “Build Verification Testing”: una validación de que el build es suficientemente estable para someter a pruebas más serias. En otras palabras, es el portero que decide si entras al antro o no.

Smoke test vs. sanity test vs. regression test: el cuadro de una vez

Este es el punto donde mucha gente se clocha. Los tres son distintos y tienen momentos diferentes:

Tipo	Para qué	Cuándo	Velocidad
Smoke	¿Arranca la app?	Cada build nuevo	Minutos
Sanity	¿Funcionó este fix específico?	Después del smoke, en build estable	Moderado
Regression	¿No rompí nada de lo que ya funcionaba?	Antes de release	Horas

El orden correcto es ese: primero smoke, luego sanity si aplica, luego regression. Si el smoke falla, cancelas todo y ni pierdes tiempo en lo demás.

La diferencia más importante con el sanity testing es el scope. El smoke es amplio y superficial, toca todo el sistema a nivel de “¿existe?”. El sanity es estrecho y específico, verifica si un cambio puntual hizo lo que se supone que debía hacer.

Qué prueba un smoke test en la vida real

Para un e-commerce básico, los smoke tests son algo así:

• ¿La homepage responde con HTTP 200?
• ¿El buscador de productos devuelve resultados?
• ¿El login con credenciales válidas funciona?
• ¿El carrito acepta un ítem?
• ¿El endpoint /api/health responde {"status": "ok"}?

Para una app bancaria:

• ¿Puedo iniciar sesión?
• ¿Se muestra el saldo de la cuenta?
• ¿Puedo iniciar una transferencia (sin completarla en el smoke)?

Eso es todo. Nada de casos edge, nada de validaciones complejas. Si esas cinco o seis cosas pasan, el build sobrevivió el smoke y puedes seguir.

Cómo meterlo a tu GitHub Actions hoy mismo

Aquí está el punto donde la mayoría de equipos pequeños en México y LATAM se quedan en teoría. Así se ve un pipeline real con smoke test integrado:

name: CI Pipeline
on:
  push:
    branches: [main, develop]

jobs:
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test

  api-smoke:
    needs: unit-tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Levantar app
        run: docker-compose up -d
      - name: Esperar a que esté lista
        run: |
          until curl -sf http://localhost:3000/health; do
            sleep 2
          done
      - name: Instalar Newman
        run: npm install -g newman
      - name: Correr smoke tests de API
        run: |
          newman run postman/smoke-tests.json \
            --environment postman/env.staging.json \
            --reporters cli,junit

  ui-smoke:
    needs: api-smoke
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: docker-compose up -d
      - name: Correr Cypress smoke
        uses: cypress-io/github-action@v6
        with:
          command: npx cypress run --env tags=smoke
          browser: chrome

El truco está en la estructura: primero corres las pruebas unitarias rápidas, luego los smoke tests de API con Postman/Newman (más rápidos y estables que UI), y al final los smoke tests de interfaz con Cypress. Si cualquier etapa falla, el pipeline se detiene y el deploy no ocurre.

Lo mismo aplica para GitLab CI, solo cambia la sintaxis del YAML.

Las herramientas que están ganando en 2026

Según los datos de adopción actuales, el ecosistema está bastante claro:

• Playwright: 45% de adopción, corre 42% más rápido que Selenium, 92% de estabilidad en pruebas. La opción más sólida hoy para web.
• Cypress: 14% de adopción pero sigue siendo el favorito de equipos pequeños por su experiencia de desarrollo.
• Postman/Newman: para API smoke tests antes de tocar la UI, es una chimba porque valida contratos de endpoints en segundos.
• Selenium: ya está bajando a 22% de adopción, pero sigue presente en proyectos enterprise legacy.

La regla de oro que los QA senior repiten: “Si no necesitas la UI para probarlo, pruébalo via API”. Postman primero, Cypress después.

La IA ya está automatizando esto (y no es hype)

El 94% de los equipos usa IA en testing en alguna forma (aunque solo 12% ha alcanzado autonomía completa). Alternativamente, 77.7% han adoptado enfoques ‘AI-first’ en quality engineering. No es casualidad que el smoke testing sea uno de los puntos de entrada favoritos para IA porque el alcance está bien definido y la tolerancia al error es baja.

Lo que herramientas como Mabl, Applitools y Playwright AI hacen hoy:

• Generan casos de smoke test a partir de requirements o historias de usuario
• Self-healing tests: cuando cambia un selector CSS o un ID de botón, la IA repara el test automáticamente sin que toques nada. Esto reduce el mantenimiento hasta 70%
• Priorización inteligente: en lugar de correr todo el suite de smoke en cada commit, corre solo los tests relevantes al código que cambió

Si usas herramientas de IA para programar, como las que analizamos en nuestra comparativa de Claude Code vs Cursor vs Copilot vs Windsurf, muchas ya sugieren o generan configuraciones de CI/CD incluyendo smoke tests.

Los errores que arruinan un smoke test bien intencionado

Los más comunes que se ven en proyectos reales:

• sleep(5000) en lugar de esperar condiciones reales: tus tests fallan cuando el servidor tarda más de 5 segundos en levantar. Usa waitForSelector o until curl -sf.
• Selectores CSS como .btn-primary: cualquier cambio de estilos rompe el test. Usa data-testid="submit-btn".
• Correr TODOS los E2E en el smoke stage: eso no es smoke testing, es regression testing disfrazado y tarda horas.
• No etiquetar los smoke tests: si no tienes @smoke o --env tags=smoke, no puedes filtrar qué corre en qué stage.
• Solo smoke antes del deploy, nunca después: los equipos maduros corren smoke tests TAMBIÉN después del deploy como monitoreo sintético. Cada 5 minutos en producción.

LaunchDarkly tiene un buen punto sobre esto: el post-deployment smoke test es básicamente un “¿todavía funciona?” automatizado que te avisa antes de que lo haga un usuario.

Para equipos sin QA dedicado

La mayoría de startups y agencias en México no tienen QA. Son devs full-stack que hacen todo. Para esos casos, la recomendación práctica es:

1. Empieza con 5 pruebas, no con 50. Login, homepage, endpoint principal, crear un recurso, listar recursos.
2. Postman + Newman para el API smoke. Si ya tienes colecciones de Postman para testear tu API manualmente, ya tienes la mitad del camino hecho.
3. Mételo al pipeline como bloqueador del deploy. No como “nice to have” sino como condición para que el merge a main proceda.
4. Revísalo cuando cambies la app. Un smoke test que prueba features eliminadas es ruido.

El mercado de testing automatizado en 2026 es estimado entre $14.83 mil millones y $40.44 mil millones de dólares según diferentes fuentes de investigación de mercado y la razón es simple: el costo de calidad pobre le cuesta a las empresas más de $5 millones al año en promedio. Para una startup pequeña eso se traduce en clientes que no regresan porque la app les falló en el peor momento.

Como siempre con el dev local, si quieres experimentar con estas herramientas sin depender de un servidor en la nube, en nuestra guía de cómo correr tu propia IA local con Ollama hay contexto útil sobre montar ambientes de desarrollo controlados.

El smoke test no va a encontrar todos los bugs. No es su trabajo. Su trabajo es darte la confianza básica de que lo que subiste no está completamente roto antes de que lo note un usuario real un viernes por la noche.

¿Tu equipo ya tiene smoke tests en el pipeline o todavía van de fe? Cuenten en los comentarios qué herramientas usan.

Fuentes

• Smoke Testing Guide 2026 - BrowserStack
• Smoke Testing Best Practices - AltexSoft
• Comprehensive Guide to Smoke Testing - LaunchDarkly
• Smoke Tests in CI/CD Pipelines - CircleCI
• AI in Software Testing 2026 - ContextQA
• Smoke vs Sanity Testing - Katalon
• GitLab Smoke Tests Documentation