Las pruebas de humo sirven como primera línea de defensa en el aseguramiento de calidad, determinando rápidamente si un build es lo suficientemente estable para pruebas adicionales. Una Documentación de Checklist de Pruebas de Humo efectiva asegura validación consistente y rápida de funcionalidad crítica. Esta guía explora enfoques integrales para crear y mantener documentación de pruebas de humo.

Entendiendo la Documentación de Pruebas de Humo

Las pruebas de humo, también conocidas como pruebas de verificación de build (BVT), son pruebas superficiales pero amplias que verifican las funciones más críticas de una aplicación. El objetivo no es pruebas exhaustivas, sino identificación rápida de defectos críticos que hacen impráctica la realización de más pruebas.

Propósito y Características

La documentación de pruebas de humo debe encarnar estos principios:

  • Velocidad: Ejecutable en máximo 15-30 minutos
  • Criticidad: Enfoque solo en características críticas de misión
  • Indicador de Estabilidad: Determinar estabilidad del build, no validación profunda
  • Decisión Go/No-Go: Criterios claros para aceptar o rechazar builds
  • Amigable con Automatización: Diseñado para ejecución automatizada
  • Siempre Actualizado: Actualizado con cada adición significativa de características

Identificación de Rutas Críticas

Mapeo de Flujos Críticos del Negocio

Identifica los escenarios absolutamente imprescindibles para tu aplicación:

rutas_criticas:
  plataforma_ecommerce:
    autenticacion_usuario:
      prioridad: P0
      flujos:
        - "Login de usuario con credenciales válidas"
        - "Verificación de persistencia de sesión"
        - "Funcionalidad de logout"
      criterios_aceptacion: "Todos los flujos de auth completan sin errores"

    catalogo_productos:
      prioridad: P0
      flujos:
        - "Página principal carga con productos"
        - "Búsqueda de productos devuelve resultados"
        - "Página de detalle de producto se muestra"
      criterios_aceptacion: "Catálogo accesible y buscable"

    proceso_checkout:
      prioridad: P0
      flujos:
        - "Agregar artículo al carrito"
        - "Ver carrito con artículos correctos"
        - "Proceder al checkout"
        - "Completar pago (modo prueba)"
      criterios_aceptacion: "Flujo de compra end-to-end completa"

    gestion_pedidos:
      prioridad: P1
      flujos:
        - "Ver confirmación de pedido"
        - "Acceder historial de pedidos"
      criterios_aceptacion: "Seguimiento de pedidos funcional"

Matriz de Prioridad para Pruebas de Humo

Categoría de CaracterísticaImpacto NegocioRiesgo TécnicoPrioridad Smoke TestProfundidad
Autenticación UsuarioCríticoMedioP0Solo happy path
Procesamiento de PagosCríticoAltoP0Transacción de prueba
Visualización ProductosAltoBajoP0Verificación muestra
Funcionalidad BúsquedaAltoMedioP0Consulta básica
Perfil UsuarioMedioBajoP1Solo visualización
RecomendacionesBajoMedioP2Excluido
Dashboard AnalyticsBajoBajoP2Excluido

P0: Debe pasar para aceptación de build P1: Debería pasar pero no bloqueante P2: No incluido en suite de humo

Estrategias de Verificación de Build

Enfoque de Pruebas de Humo en Capas

## Estrategia de Pruebas de Humo de Tres Capas

### Capa 1: Humo de Infraestructura (5 minutos)
**Propósito**: Verificar despliegue básico y conectividad

- [ ] URL de aplicación accesible (HTTP 200)
- [ ] Endpoint de health check responde
- [ ] Conexión a base de datos establecida
- [ ] Servicio de caché respondiendo
- [ ] Cola de mensajes accesible
- [ ] CDN sirviendo assets estáticos
- [ ] API gateway enrutando correctamente

### Capa 2: Humo de Componentes (10 minutos)
**Propósito**: Verificar componentes clave se inicializan

- [ ] Página de login carga
- [ ] Página principal renderiza con datos
- [ ] Endpoints API devuelven respuestas esperadas
- [ ] JavaScript frontend carga sin errores
- [ ] Estilizado CSS aplica correctamente
- [ ] Jobs en segundo plano procesando
- [ ] Servicio de email enviando mensajes de prueba

### Capa 3: Humo de Integración (15 minutos)
**Propósito**: Verificar flujos end-to-end críticos

- [ ] Usuario puede hacer login
- [ ] Usuario puede realizar acción primaria (compra, transferencia, post)
- [ ] Datos persisten correctamente
- [ ] Notificaciones por email enviadas
- [ ] Integraciones con terceros respondiendo
- [ ] Logging y monitoreo activos

Estructura de Pruebas de Humo Automatizadas

# smoke_test_suite.py
import pytest
from selenium import webdriver
from api_client import APIClient
import logging

class SmokeTestSuite:
    """
    Suite completa de pruebas de humo para verificación de build
    """

    @pytest.fixture(scope="class")
    def setup(self):
        """Configurar entorno de prueba"""
        self.driver = webdriver.Chrome()
        self.api = APIClient(base_url="https://api.example.com")
        self.logger = logging.getLogger(__name__)
        yield
        self.driver.quit()

    @pytest.mark.smoke
    @pytest.mark.priority_p0
    def test_infrastructure_health(self):
        """Capa 1: Verificar infraestructura"""
        # Health check
        response = self.api.get("/health")
        assert response.status_code == 200
        assert response.json()["status"] == "healthy"

        # Conectividad de base de datos
        db_check = self.api.get("/health/database")
        assert db_check.json()["database"] == "connected"

        self.logger.info("✓ Humo de infraestructura pasado")

    @pytest.mark.smoke
    @pytest.mark.priority_p0
    def test_authentication_flow(self):
        """Capa 2: Verificar autenticación"""
        self.driver.get("https://app.example.com/login")

        # Elementos de login presentes
        assert self.driver.find_element("id", "username")
        assert self.driver.find_element("id", "password")
        assert self.driver.find_element("id", "login-button")

        # Realizar login
        self.driver.find_element("id", "username").send_keys("smoke_test_user")
        self.driver.find_element("id", "password").send_keys("test_password")
        self.driver.find_element("id", "login-button").click()

        # Verificar login exitoso
        assert "dashboard" in self.driver.current_url
        assert self.driver.find_element("class", "user-greeting")

        self.logger.info("✓ Humo de autenticación pasado")

    @pytest.mark.smoke
    @pytest.mark.priority_p0
    def test_critical_business_flow(self):
        """Capa 3: Verificar flujo crítico end-to-end"""
        # Asume ya logueado de prueba anterior

        # Navegar a producto
        self.driver.get("https://app.example.com/products")
        product = self.driver.find_element("class", "product-card")
        product.click()

        # Agregar al carrito
        add_to_cart_btn = self.driver.find_element("id", "add-to-cart")
        add_to_cart_btn.click()

        # Verificar carrito
        cart_count = self.driver.find_element("id", "cart-count").text
        assert int(cart_count) > 0

        # Proceder a checkout
        self.driver.get("https://app.example.com/checkout")
        assert "checkout" in self.driver.current_url

        # Verificar elementos de página checkout
        assert self.driver.find_element("id", "shipping-form")
        assert self.driver.find_element("id", "payment-form")

        self.logger.info("✓ Humo de flujo crítico de negocio pasado")

Criterios Go/No-Go

Matriz de Decisión

Criterios claros y objetivos para aceptación de build:

criterios_go_no_go:
  rechazo_inmediato:
    - "Aplicación falla al desplegar"
    - "Endpoint de health check devuelve errores 5xx"
    - "Conexión a base de datos falla"
    - "Autenticación completamente rota"
    - "Endpoints API críticos devuelven errores 500"
    - "Frontend falla al cargar (pantalla blanca)"
    - "Cualquier prueba de humo P0 falla"

  aceptacion_condicional:
    - condicion: "1-2 pruebas de humo P1 fallan"
      accion: "Aceptar con tickets de bugs, proceder con cautela"
    - condicion: "Degradación de rendimiento <20%"
      accion: "Aceptar, monitorear de cerca"
    - condicion: "Problemas menores de renderizado UI"
      accion: "Aceptar, registrar defectos"

  aceptacion_completa:
    - "Todas las pruebas de humo P0 pasan"
    - "No hay errores críticos en logs"
    - "Tiempos de respuesta dentro de baseline ±10%"
    - "No se introducen vulnerabilidades de seguridad"
    - "Todos los servicios saludables"

Mejores Prácticas

Estándares de Documentación

  1. Mantenerlo Mínimo: Documentar solo lo esencial para validación rápida
  2. Hacerlo Ejecutable: Cada ítem del checklist debe ser testeable
  3. Control de Versiones: Rastrear cambios en pruebas de humo junto con código
  4. Paso/Fallo Claro: Sin ambigüedad en criterios de aceptación
  5. Tiempo Limitado: Establecer límites máximos de tiempo de ejecución
  6. Priorizado: Designación clara P0/P1/P2
  7. Automatizado Donde Sea Posible: Manual solo cuando automatización es impráctica

Conclusión

La Documentación efectiva de Checklist de Pruebas de Humo es crucial para validación rápida de builds y puertas de calidad. Al enfocarse en rutas críticas, mantener criterios go/no-go claros y automatizar donde sea posible, los equipos pueden identificar rápidamente problemas de build y prevenir esfuerzo de pruebas desperdiciado en builds inestables.

Recuerda: las pruebas de humo no son sustituto de pruebas exhaustivas—son un guardián que asegura que solo builds estables procedan a validación más profunda. Mantenlas rápidas, enfocadas y siempre actualizadas con la funcionalidad crítica de tu aplicación.