Smoke vs Sanity vs Regression Testing: ¿Cuál es la Diferencia?

En las pruebas de software, tres términos a menudo se confunden: Smoke Testing (Pruebas de Humo), Sanity Testing (Pruebas de Cordura) y Regression Testing (como se discute en Black Box Testing: Techniques and Approaches) (Pruebas de Regresión). Aunque pueden parecer similares, cada uno sirve un propósito distinto en el ciclo de vida del desarrollo de software. Entender cuándo y cómo usar cada tipo es crucial para pruebas eficientes.

Esta guía aclarará las diferencias, proporcionará ejemplos prácticos y te ayudará a decidir qué tipo de prueba usar en diferentes escenarios.

Comparación Rápida

Smoke Testing: “¿Podemos Siquiera Empezar a Probar?”

¿Qué es Smoke Testing?

Smoke Testing (también llamado Build Verification Testing o Confidence Testing) es una verificación preliminar para determinar si un nuevo build es lo suficientemente estable para pruebas adicionales. Es como encender una máquina para ver si se enciende antes de ejecutar diagnósticos.

El término proviene de pruebas de hardware: si enciendes un dispositivo y empieza a humear, algo está seriamente mal.

Características Clave

• Rápido: 15-30 minutos máximo
• Superficial: Prueba solo funcionalidad crítica de alto nivel
• Decisión Go/No-Go: Pasa = continuar pruebas, Falla = rechazar build
• Cobertura Amplia: Toca muchas funciones pero no profundiza
• Punto de Entrada: Primera prueba realizada en un nuevo build

Qué Cubre Smoke Testing

• ✅ La aplicación se inicia exitosamente

• ✅ Funcionalidad de login funciona

• ✅ Páginas/pantallas críticas cargan

• ✅ Navegación entre módulos principales funciona

• ✅ Sin crashes críticos o bloqueadores

• ❌ Funcionalidad detallada

• ❌ Casos límite

• ❌ Validación de datos

• ❌ Flujos de trabajo complejos

Ejemplo de Smoke Testing

Prueba Smoke de Aplicación E-commerce (20 minutos)

1. Inicio de Aplicación
   ✓ La aplicación carga sin errores
   ✓ Página de inicio se muestra correctamente

2. Autenticación de Usuario
   ✓ Página de login accesible
   ✓ Puede iniciar sesión con credenciales válidas
   ✓ Logout funciona

3. Funciones Principales (Solo Flujo Feliz)
   ✓ Barra de búsqueda acepta entrada
   ✓ Página de producto carga
   ✓ Agregar al carrito funciona
   ✓ Ver página del carrito se muestra
   ✓ Página de checkout accesible

4. APIs Críticas
   ✓ Servicio de usuario responde (200 OK)
   ✓ Servicio de producto responde (200 OK)
   ✓ Pasarela de pago responde (200 OK)

Decisión: Si CUALQUIERA de estos falla → Rechazar build, devolver a dev

Plantilla de Checklist de Smoke Test

# Smoke Test - Build #v2.5.3
Fecha: 2025-10-02 | Tester: QA Lead

## Entorno
- URL: https://staging.app.com
- Navegador: Chrome 120

## Resultados

| Módulo | Prueba | Estado | Notas |
|--------|--------|--------|-------|
| Inicio | App carga | ✅ Pasa | |
| Auth | Login funciona | ✅ Pasa | |
| Auth | Logout funciona | ✅ Pasa | |
| Productos | Búsqueda funciona | ✅ Pasa | |
| Productos | Página de producto carga | ✅ Pasa | |
| Carrito | Agregar al carrito | ✅ Pasa | |
| Checkout | Página de checkout carga | ✅ Pasa | |

**Decisión**: ✅ BUILD ACEPTADO - Proceder con pruebas completas

---

Si cualquier prueba crítica falla:
**Decisión**: ❌ BUILD RECHAZADO - Retornar a desarrollo

Cuándo Usar Smoke Testing

• ✅ Después de cada despliegue de nuevo build
• ✅ Antes de comenzar un ciclo de prueba completo
• ✅ Después de fusionar ramas de características principales
• ✅ En pipelines CI/CD (pruebas smoke automatizadas)
• ✅ Al decidir si el build es testeable

Sanity Testing: “¿Arreglamos lo que Dijimos?”

¿Qué es Sanity Testing?

Sanity Testing (también llamado Narrow Regression Testing) (como se discute en Risk-Based Testing: Prioritizing Test Efforts for Maximum Impact) es una prueba rápida y enfocada para verificar que una corrección de bug específica o cambio menor funciona como se esperaba. Es como verificar si la reparación que hiciste a un auto realmente arregló el problema.

Características Clave

• Alcance Estrecho: Prueba solo el área cambiada
• Sin Script: Usualmente no documentado formalmente
• Rápido: 30-60 minutos
• Profundo en Área Cambiada: Va más profundo que smoke testing
• Verificación Post-Corrección: Realizado después de correcciones de bugs o cambios pequeños

Qué Cubre Sanity Testing

• ✅ El bug específico que fue corregido

• ✅ Funcionalidad relacionada con la corrección

• ✅ Dependencias inmediatas

• ❌ Aplicación entera

• ❌ Funciones no relacionadas

• ❌ Regresión completa

Ejemplo de Sanity Testing

Escenario: Corrección de Bug - “Email de restablecimiento de contraseña no se envía”

Reporte de Bug:

ID de Bug: BUG-1234
Problema: Usuarios no reciben emails de restablecimiento de contraseña
Corrección: Actualizada configuración de servicio de email
Build: v2.5.4

Sanity Test (45 minutos):

Área de Enfoque: Flujo de Restablecimiento de Contraseña

1. Activar Restablecimiento de Contraseña
   ✓ Hacer clic en enlace "¿Olvidó su Contraseña?"
   ✓ Ingresar dirección de email válida
   ✓ Enviar formulario
   ✓ Verificar que mensaje de éxito se muestra

2. Verificar Email Enviado
   ✓ Verificar bandeja de entrada de email (cuenta de prueba)
   ✓ Email recibido dentro de 2 minutos
   ✓ Email contiene enlace de restablecimiento
   ✓ Formato de email es correcto

3. Completar Restablecimiento de Contraseña
   ✓ Hacer clic en enlace de restablecimiento en email
   ✓ Enlace abre página de restablecimiento
   ✓ Ingresar nueva contraseña
   ✓ Confirmar restablecimiento de contraseña
   ✓ Verificar mensaje de éxito

4. Verificar que Nueva Contraseña Funciona
   ✓ Iniciar sesión con nueva contraseña
   ✓ Login exitoso
   ✓ Contraseña antigua rechazada

5. Funcionalidad Relacionada (Sanity Check)
   ✓ Login regular todavía funciona
   ✓ Notificaciones de email para otras acciones funcionan
   ✓ Perfil de usuario muestra email correctamente

Decisión: Si corrección funciona → Aceptar cambio, continuar pruebas
         Si corrección falla → Rechazar, enviar de vuelta para re-trabajo

Cuándo Usar Sanity Testing

• ✅ Después de una corrección de bug para verificar que está resuelto
• ✅ Después de cambios menores de código
• ✅ Después de actualizaciones pequeñas de configuración
• ✅ Antes de ejecutar regresión completa
• ✅ Cuando el tiempo es limitado (validación rápida)

Sanity vs Smoke: Diferencia Clave

Smoke Testing:
"¿Funciona la aplicación en absoluto?"
Alcance: Toda la app (superficial)
Ejemplo: ¿Puedo iniciar sesión, buscar, agregar al carrito?

Sanity Testing:
"¿Funciona esta corrección/cambio específico?"
Alcance: Una función/área (profunda)
Ejemplo: ¿El email de restablecimiento de contraseña ahora se envía?

Regression Testing: “¿Rompimos Algo Más?”

¿Qué es Regression Testing (como se discute en Shift-Left Testing: Early Quality Integration for Cost Savings)?

Regression Testing verifica que cambios recientes de código no hayan roto funcionalidad existente. Es como asegurarse de que arreglar los frenos del auto no rompió de alguna manera los faros.

Características Clave

• Comprensivo: Prueba toda la aplicación
• Documentado: Casos de prueba formales
• Consume Tiempo: Horas a días
• Automatizado: Debería estar altamente automatizado
• Repetido: Se ejecuta frecuentemente (cada sprint, cada release)
• Acumulativo: Suite de pruebas crece con el tiempo

Qué Cubre Regression Testing

• ✅ Toda la funcionalidad existente
• ✅ Bugs corregidos previamente (para asegurar que no vuelvan a ocurrir)
• ✅ Puntos de integración
• ✅ Flujos de trabajo de negocio críticos
• ✅ Casos límite y condiciones de frontera

Flujo de Trabajo de Pruebas del Mundo Real

Escenario: Nueva función agregada - “Funcionalidad de Lista de Deseos”

Fase 1: Smoke Testing (30 min)

✓ App todavía carga
✓ Login todavía funciona
✓ Funciones principales accesibles
✓ Sin crashes críticos

Resultado: ✅ Build es estable, proceder

Fase 2: Feature Testing (2 días)

Probar nueva función de Lista de Deseos:
✓ Agregar artículos a lista de deseos
✓ Eliminar artículos
✓ Ver página de lista de deseos
✓ Mover artículo de lista de deseos al carrito
✓ Compartir lista de deseos
✓ Persistencia de lista de deseos

Resultado: ✅ Función funciona, encontrados 3 bugs menores

Fase 3: Sanity Testing (1 hora)

Después de bugs corregidos:
✓ Verificar que 3 bugs están resueltos
✓ Re-probar áreas afectadas
✓ Verificación rápida de funciones relacionadas

Resultado: ✅ Bugs corregidos, no hay problemas obvios

Fase 4: Regression Testing (1 día automatizado)

Ejecutar suite de regresión completa (450 pruebas):
✓ Todas las pruebas de autenticación pasan
✓ Todas las pruebas de carrito pasan
✓ Todas las pruebas de checkout pasan
✗ 2 pruebas de búsqueda de productos fallan (investigación necesaria)

Resultado: ⚠️ Encontradas 2 regresiones en búsqueda, necesitan correcciones

Guía de Decisión Rápida

¿Cuándo Debería Ejecutar…

Smoke Testing?

• ✅ Nuevo build desplegado
• ✅ Comenzando el día (verificar entorno)
• ✅ Pipeline CI/CD (automatizado)
• ✅ Antes de asignar recursos de QA

Sanity Testing?

• ✅ Corrección de bug desplegada
• ✅ Cambio de configuración menor
• ✅ Hot fix aplicado
• ✅ Necesita verificación rápida

Regression Testing?

• ✅ Antes de release (obligatorio)
• ✅ Fin de sprint
• ✅ Después de cambios de código mayores
• ✅ Después de refactorización
• ✅ Integración de nuevas bibliotecas

Conclusión

Los tres tipos de pruebas sirven propósitos críticos pero diferentes:

El Flujo de Prueba Completo:

Nuevo Build → Smoke Test → Feature Test → Sanity Test (si hay correcciones) → Regression Test → Release

Entender cuándo y cómo usar cada tipo hará tus pruebas más eficientes, detectará bugs más temprano y asegurará releases de mayor calidad.