Que Es el Sanity Testing?
El sanity testing es una actividad de testing estrecha y enfocada, realizada despues de un cambio especifico — tipicamente un bug fix o actualizacion menor — para verificar que el cambio funciona correctamente y no ha roto funcionalidad relacionada de manera obvia. A diferencia del smoke testing, que ampliamente verifica si todo el build es estable, el sanity testing se enfoca en un area especifica.
Piensa en la diferencia asi: Smoke testing es un doctor verificando tus signos vitales (pulso, presion, temperatura) para ver si estas generalmente sano. Sanity testing es el doctor verificando si la medicacion especifica que receto ayer esta funcionando.
Despues de que un desarrollador corrige un bug en el calculo de pagos, el sanity testing verifica:
- El bug especifico esta corregido (el escenario reportado ahora funciona)
- Funcionalidad relacionada sigue funcionando (otros calculos no afectados)
- El area alrededor del fix es estable (el flujo de checkout completa)
El sanity testing NO verifica toda la aplicacion. No revisa login, busqueda ni features no relacionados.
Comparacion Completa: Smoke vs Sanity vs Regresion
| Caracteristica | Smoke | Sanity | Regresion |
|---|---|---|---|
| Proposito | Build estable? | Fix especifico funciona? | Algo mas se rompio? |
| Alcance | Amplio, superficial | Estrecho, profundo | Amplio, profundo |
| Cuando | Despues de cada build | Despues de fix/cambio | Antes del release |
| Duracion | 10-15 minutos | 15-30 minutos | Horas a dias |
| Automatizacion | Usualmente automatizado | Usualmente manual | Mix |
| Quien | QA o CI/CD | Ingeniero QA | Equipo QA |
| Analogia | Chequeo general | Verificar si la medicina funciona | Escaneo corporal completo |
Cuando Usar Sanity Testing
Despues de un Bug Fix
Bug reportado: “El calculo de descuento muestra 12% en vez de 10% para ordenes sobre $100.” El desarrollador lo corrige. Antes de regresion completa:
- Verificar el escenario exacto del bug ahora muestra 10%
- Probar escenarios de descuento relacionados
- Verificar que el calculo total de orden no se rompio
Despues de una Actualizacion Menor
El equipo solicita: “Agregar boton ‘Limpiar Todo’ al centro de notificaciones.”
- Verificar que el boton aparece
- Verificar que al hacer click limpia todas las notificaciones
- Verificar que descartar notificaciones individuales sigue funcionando
- Verificar que el contador se actualiza
Despues de un Cambio de Configuracion
DevOps actualiza el pool de conexiones de BD de 10 a 50:
- Verificar que la app conecta a la BD
- Ejecutar operaciones intensivas en BD
- Verificar que no hay errores de timeout
Cuando NO Usar Sanity Testing
- Como reemplazo de regresion. Es un chequeo rapido, no verificacion comprehensiva.
- Para releases de features mayores. Cambios significativos necesitan testing de sistema y regresion.
- Cuando el alcance del cambio no es claro. Si no sabes que afecta, haz testing mas amplio.
Como Realizar Sanity Testing
- Leer la descripcion del cambio — Que se cambio y por que?
- Reproducir el problema original (si fue bug fix) — Confirmar el fix
- Probar funcionalidad relacionada — 3-5 escenarios cercanos
- Buscar efectos secundarios obvios — UI correcta? Features cercanos funcionan?
- Tomar decision rapida — Proceder con testing mas profundo o devolver al desarrollador?
La Mentalidad del Sanity Testing
Requiere juicio experimentado. A diferencia de scripts de test, el sanity testing depende del conocimiento del tester para:
- Identificar que es “funcionalidad relacionada”
- Reconocer cuando algo “se ve mal” sin caso de prueba formal
- Saber cuando parar versus escalar
Ejercicio: Decide Smoke, Sanity o Regresion
Para cada escenario, determina que tipo de testing es mas apropiado:
- Un nuevo build se desplego al ambiente QA esta manana
- Un desarrollador corrigio un bug donde “Exportar a CSV” descargaba archivo vacio
- El equipo prepara un release a produccion la proxima semana
- DevOps migro la app a un nuevo servidor
- Un desarrollador cambio el algoritmo de ordenamiento de busqueda
- La pagina de login se rediseno con nuevo branding, funcionalidad sin cambios
- Se aplico un parche de seguridad critico al modulo de autenticacion
- El build nocturno se completo a las 3 AM
Pista
Preguntate: Estoy verificando si todo el build funciona (smoke), si un fix especifico funciona (sanity), o si todo sigue funcionando antes de un release (regresion)?Solucion
Smoke Testing — Nuevo build en QA. Verificar que el build es estable antes de que alguien empiece a probar.
Sanity Testing — Bug especifico corregido. Verificar el fix exacto, probar escenarios de exportacion relacionados, verificar otros formatos.
Regression Testing — Testing pre-release requiere verificacion comprehensiva de que funcionalidad existente no esta rota.
Smoke Testing — Migracion de servidor cambia infraestructura, no codigo. Verificar que la app funciona en el nuevo servidor.
Sanity Testing — Algoritmo especifico cambiado. Verificar que resultados siguen siendo precisos, probar varias consultas.
Sanity + Regresion Dirigida — Rediseno UI sin cambio funcional. Sanity de que login funciona con nuevo diseno. Luego regresion dirigida del flujo de login.
Sanity seguido de Regresion — Parches de seguridad son alto riesgo. Primero sanity de que autenticacion funciona. Luego regresion completa del modulo.
Smoke Testing — Builds nocturnos deben activar smoke tests automatizados. Si pasan, el build esta listo para el equipo QA por la manana.
Flujo de Trabajo del Sanity Testing
Paso?} SMOKE -->|No| REJECT[Rechazar Build] SMOKE -->|Si| SANITY[Sanity Testing
Verificar cambio] SANITY -->|Fix funciona| REGRESSION[Proceder a Regresion] SANITY -->|Fix no funciona| RETURN[Devolver al Desarrollador] SANITY -->|Nuevos issues| TRIAGE[Evaluar:
Bloquear o continuar?]
Tips Profesionales
Tip 1: Sanity es sobre confianza, no cobertura. No buscas cada problema posible. Construyes confianza suficiente de que el fix es razonable.
Tip 2: Documenta resultados. Aunque es informal, documenta que verificaste. Cuando el bug reaparezca en produccion, necesitas saber que se verifico.
Tip 3: Limita el tiempo. 15-30 minutos maximo. Si no puedes verificar en ese tiempo, el fix es mas complejo de lo esperado.
Conclusiones Clave
- Sanity testing es verificacion estrecha y enfocada de un cambio especifico
- Difiere del smoke (estabilidad amplia) y regresion (verificacion comprehensiva)
- Realizado manualmente por QA experimentados usando juicio y conocimiento del sistema
- Apropiado despues de bug fixes, actualizaciones menores y cambios de configuracion
- No reemplaza regresion — es un chequeo rapido antes de testing mas profundo
- Limitar a 15-30 minutos y documentar resultados