La primera vez que escuché el término smoke test fue en la formación. Y reconozco que el nombre me pareció curioso — ¿qué tiene que ver el humo con el testing? En este artículo te explico qué es, de dónde viene el nombre y cuándo tiene sentido ejecutarlo en un proyecto real.
De dónde viene el nombre
El término smoke test viene del mundo de la electrónica y la fontanería. Cuando los ingenieros terminaban de montar un circuito o una tubería, lo encendían o le metían presión y observaban si salía humo o había fugas. Si salía humo, algo estaba mal y no valía la pena seguir probando.
En software el concepto es el mismo: antes de invertir tiempo en pruebas exhaustivas, compruebas rápidamente si lo más básico funciona. Si falla algo fundamental, paras y lo devuelves al desarrollador sin perder más tiempo.
Qué es un smoke test
Un smoke test es un conjunto de pruebas rápidas que verifican que las funcionalidades más críticas de una aplicación funcionan correctamente después de un nuevo build o despliegue.
No es un testing exhaustivo. No busca todos los bugs posibles. Su único objetivo es responder una pregunta: ¿está este build lo suficientemente estable para que valga la pena probarlo en profundidad?
Si el smoke test pasa, el equipo de QA puede continuar con pruebas más detalladas. Si falla, el build se devuelve a desarrollo sin invertir más tiempo en él.
Qué incluye un smoke test
Los casos de un smoke test cubren los flujos más críticos de la aplicación — los que no pueden fallar bajo ningún concepto.
En una aplicación de e-commerce típica, el smoke test incluiría verificaciones como estas: que la página carga correctamente, que el usuario puede registrarse e iniciar sesión, que puede buscar productos, añadirlos al carrito y completar el proceso de pago.
En una aplicación bancaria: que el login funciona, que el saldo se muestra correctamente y que se puede realizar una transferencia básica.
La regla general es: si esta funcionalidad falla, el resto de la aplicación no tiene sentido probarlo. Eso entra en el smoke test.
Diferencia entre smoke test y otros tipos de pruebas
Es fácil confundir el smoke test con otros conceptos relacionados. Aquí van las diferencias clave:
Smoke test vs pruebas de regresión
Las pruebas de regresión verifican que nada de lo que funcionaba antes se ha roto con los últimos cambios. Son exhaustivas y cubren toda la aplicación. El smoke test es mucho más rápido y superficial — solo verifica que lo más crítico funciona.
Smoke test vs sanity test
El sanity test se ejecuta después del smoke test y verifica que una funcionalidad concreta o una corrección específica funciona correctamente. Es más profundo que el smoke test pero menos exhaustivo que la regresión completa.
Smoke test vs pruebas de aceptación
Las pruebas de aceptación verifican que el producto cumple los requisitos del negocio desde el punto de vista del usuario. El smoke test es técnico y rápido — solo verifica que el build es estable.
Cuándo ejecutar un smoke test
El smoke test tiene sentido en estos momentos concretos:
Después de cada nuevo build o despliegue. Cada vez que los desarrolladores entregan una nueva versión, el smoke test es lo primero que se ejecuta antes de entrar en pruebas más profundas.
Al inicio de cada sprint. En equipos ágiles, ejecutar un smoke test al principio del sprint confirma que el entorno está estable y listo para trabajar.
Antes de un release importante. Antes de desplegar a producción, el smoke test da una última confirmación rápida de que lo más crítico funciona.
Al integrar cambios de código en CI/CD. En pipelines de integración continua, el smoke test se ejecuta automáticamente en cada push para detectar problemas críticos antes de que lleguen a ramas principales.
Cómo automatizar un smoke test con Playwright
La mejor forma de gestionar un smoke test es automatizarlo para que se ejecute solo, sin intervención manual. Con Playwright y pytest puedes marcar los tests de smoke con un marker específico y ejecutarlos de forma independiente.
Primero marcas los tests de smoke en tu código:
python
import pytest
from playwright.sync_api import Page
@pytest.mark.smoke
def test_pagina_carga(page: Page):
page.goto("https://miweb.com")
assert page.title() != ""
@pytest.mark.smoke
def test_login_funciona(page: Page):
page.goto("https://miweb.com/login")
page.fill("#email", "usuario@test.com")
page.fill("#password", "password123")
page.click("#btn-login")
assert "dashboard" in page.url
@pytest.mark.smoke
def test_pagina_principal_carga(page: Page):
page.goto("https://miweb.com")
assert page.locator("nav").is_visible()Luego en tu pytest.ini registras el marker:
ini
[pytest]
markers =
smoke: pruebas de smoke test
regression: pruebas de regresiónY para ejecutar solo los smoke tests:
powershell
pytest -m smoke
```Con GitHub Actions puedes configurar que los smoke tests se ejecuten automáticamente en cada push, como explico en el artículo sobre GitHub Actions para QA.
Cuántos casos debe tener un smoke test
No hay un número fijo, pero la regla general es que un smoke test debe ser rápido — idealmente ejecutarse en menos de 10 minutos. Si tarda más, está cubriendo demasiado y pierde su propósito.
En proyectos pequeños, entre 5 y 15 casos es suficiente. En proyectos grandes, puede llegar a 30-40 casos pero siempre enfocados en los flujos más críticos.
Si necesitas más cobertura, eso ya es trabajo para las pruebas de regresión, no para el smoke test.
Por qué el smoke test ahorra tiempo al equipo
Sin smoke test, el equipo de QA puede invertir horas probando un build que tiene un fallo crítico en el login. Todo ese tiempo se pierde.
Con un smoke test de 10 minutos, ese fallo se detecta antes de que nadie empiece a probar en profundidad. El build vuelve a desarrollo, se corrige y se vuelve a entregar. Mucho más eficiente.
Es uno de esos conceptos que parece pequeño pero que en proyectos reales marca una diferencia enorme en la velocidad del equipo.
Si quieres saber más sobre cómo encaja el smoke test en el ciclo de desarrollo, puedes leer qué es el testing shift-left o cómo funciona el QA en Scrum.
Y si necesitas ayuda para implementar una estrategia de testing en tu proyecto, puedes ver mis servicios en fatimaqa.com.