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

Las pruebas smoke, sanity y regression son tres de los términos más confundidos en QA de software, aunque cada uno sirve un propósito fundamentalmente diferente. Según el Syllabus del ISTQB Foundation Level, la confusión entre estos tipos de pruebas es uno de los cinco principales errores conceptuales en equipos de QA globalmente. El smoke testing (Build Verification Testing) toma 15-30 minutos y responde una pregunta: “¿Este build es estable para pruebas adicionales?” El sanity testing toma 30-60 minutos y verifica que una corrección específica funciona. El regression testing es comprensivo—horas o días para verificar que la funcionalidad existente no se rompió. El reporte “State of Testing 2024” de SmartBear encontró que el 73% de equipos automatizan sus suites de regresión, pero solo el 45% tiene gates formalizados de smoke en sus pipelines de CI/CD. Esta guía clarifica cada tipo con ejemplos y criterios de decisión para construir una estrategia de pruebas eficiente.

TL;DR

• Smoke: amplio, superficial — gate de 15-30 min para verificar estabilidad del build
• Sanity: estrecho, profundo — verificación de 30-60 min que una corrección específica funciona
• Regression: comprensivo — horas/días para asegurar que las características existentes aún funcionan

Regla clave: Smoke primero → Sanity para correcciones → Regression para todos los cambios

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 (Pruebas de Regresión). Aunque pueden parecer similares, cada uno sirve un propósito distinto. 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.

“El error más común que veo es equipos ejecutando pruebas de regresión en cada build menor cuando un smoke test capturaría el 90% de los mismos problemas en el 5% del tiempo. La pirámide aplica aquí también: smoke tests rápidos y baratos en la base, sanity checks específicos en el medio, regresión completa solo cuando se necesita. Ordenar esto correctamente puede recortar tu ciclo de feedback de horas a minutos.” — Yuri Kan, Senior QA Lead

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.

FAQ #

¿Cuál es la diferencia entre smoke testing y sanity testing? #

El smoke testing es amplio pero superficial—15-30 minutos para verificar la estabilidad del build. El sanity testing es estrecho pero profundo—verifica que una corrección específica funciona. Según el Glosario ISTQB, el smoke testing también se llama Build Verification Testing (BVT) en contextos empresariales.

¿Cuándo ejecutar regression testing versus smoke testing? #

Ejecuta smoke testing primero en cada nuevo build para decidir si vale la pena probar más. Ejecuta regression testing después de aceptar cambios. El reporte SmartBear 2024 encontró que el 73% de equipos automatizan suites de regresión pero solo el 45% tiene gates formalizados de smoke.

¿Es smoke testing lo mismo que Build Verification Testing? #

Sí. Ambos términos describen la misma práctica: validar rápidamente que un nuevo build es estable para continuar con el testing.

¿Se pueden automatizar los smoke y sanity tests? #

Los smoke tests son altamente automatizables—se ejecutan en cada build. Los sanity tests son frecuentemente manuales porque requieren juicio contextual para correcciones específicas, aunque checks críticos pueden automatizarse una vez que la corrección está estable.

Recursos Oficiales #

• ISTQB Foundation Level Syllabus — definiciones oficiales de tipos de pruebas
• ISTQB Glossary — terminología estándar de testing
• SmartBear State of Testing 2024 — estadísticas de adopción de automatización

See Also #

• Ad-hoc vs Monkey Testing: Entendiendo Enfoques Caóticos de Testing - Aprende las diferencias entre ad-hoc y monkey testing, cuándo usar…
• Criterios de Entrada y Salida en Testing: Cuándo Iniciar y Detener las Pruebas - Domina los criterios de entrada y salida para definir límites…
• Exploratory Testing: Investigación Estructurada para Mejor Calidad - Domina técnicas de exploratory testing para descubrir defectos que…
• Pruebas de Caja Gris: Lo Mejor de Dos Mundos - Lo mejor de dos mundos: cuándo aplicar caja gris, ventajas,…