Cuando un sistema cambia, no solo debemos probar lo nuevo. También debemos comprobar que lo que antes funcionaba siga funcionando. Para eso existen prácticas como las pruebas de regresión, las pruebas de humo y las pruebas de sanidad.
Estos nombres suelen confundirse, pero tienen objetivos diferentes. Las pruebas de humo revisan rápidamente si una versión es mínimamente testeable. Las pruebas de sanidad validan de forma acotada que un cambio específico tenga sentido. Las pruebas de regresión comprueban que cambios nuevos no hayan roto funcionalidades existentes.
En este tema veremos cuándo usar cada una, con ejemplos prácticos.
Una regresión ocurre cuando una funcionalidad que antes funcionaba deja de funcionar después de un cambio.
Ejemplos:
Las regresiones son comunes porque los sistemas tienen dependencias. Un cambio en una parte puede afectar otra zona aparentemente no relacionada.
Las pruebas de regresión son pruebas que se ejecutan para confirmar que funcionalidades existentes siguen funcionando después de cambios.
Se ejecutan después de:
Su objetivo no es probar todo desde cero, sino verificar que lo importante no se rompió.
Supongamos que se corrige un defecto en el cálculo de descuentos para clientes premium. Luego de la corrección, conviene ejecutar pruebas de regresión relacionadas:
No basta con verificar que el defecto original fue corregido. También debemos revisar que no se rompieron reglas cercanas.
La regresión puede tener distinto alcance:
| Tipo de regresión | Alcance | Ejemplo |
|---|---|---|
| Regresión puntual | Casos directamente relacionados con un cambio. | Revisar reglas de descuento luego de modificar descuentos. |
| Regresión por módulo | Casos de un área completa del sistema. | Probar todo el módulo de compras. |
| Regresión crítica | Flujos principales del producto. | Login, búsqueda, compra y pago. |
| Regresión completa | Gran parte o toda la suite de pruebas existente. | Validación amplia antes de una versión mayor. |
El alcance se define según riesgo, tiempo disponible e impacto del cambio.
Las pruebas de humo, también llamadas smoke testing, son un conjunto breve de pruebas básicas que se ejecutan para comprobar si una versión es suficientemente estable para continuar probando.
Responden una pregunta simple:
Si una prueba de humo falla en una funcionalidad básica, quizá no tenga sentido ejecutar una suite larga. Primero debe corregirse el bloqueo principal.
En una aplicación web, una suite de humo podría incluir:
No se busca cubrir todos los detalles. Se busca confirmar que las funciones mínimas están disponibles.
Las pruebas de humo suelen ejecutarse:
Funcionan como una verificación rápida de salud básica del sistema.
Las pruebas de sanidad, también llamadas sanity testing, son pruebas acotadas que verifican si un cambio específico parece funcionar correctamente antes de avanzar con pruebas más amplias.
Responden una pregunta como:
Son más enfocadas que las pruebas de humo. Mientras humo revisa estabilidad general, sanidad revisa un cambio concreto.
Supongamos que se corrigió un defecto donde el sistema permitía reutilizar un enlace de recuperación de contraseña.
Una prueba de sanidad podría verificar:
Si esta validación básica falla, no tiene sentido ejecutar una regresión amplia de recuperación de contraseña hasta corregir el problema.
| Tipo | Objetivo | Alcance | Momento típico |
|---|---|---|---|
| Humo | Confirmar estabilidad básica de una versión. | Breve y general. | Después de un despliegue. |
| Sanidad | Confirmar que un cambio específico funciona de forma básica. | Breve y enfocado. | Después de una corrección o cambio puntual. |
| Regresión | Confirmar que lo existente no se rompió. | Variable: puntual, módulo, crítica o completa. | Después de cambios, correcciones o antes de publicar. |
Un flujo posible después de desplegar una versión en QA sería:
El orden puede variar, pero la idea es evitar invertir mucho tiempo en pruebas profundas si la versión falla en puntos básicos.
Como no siempre se puede ejecutar toda la suite, conviene seleccionar casos de regresión según:
La regresión debe ser proporcional al riesgo del cambio.
La regresión puede ejecutarse manualmente o de forma automatizada.
La automatización es muy útil para regresiones repetitivas, estables y críticas. Por ejemplo:
La regresión manual sigue siendo útil para cambios recientes, usabilidad, exploración, validaciones visuales o funcionalidades que todavía cambian con frecuencia.
Cuando se corrige un defecto, se debe ejecutar retest del defecto original. Pero además puede requerirse regresión.
Ejemplo: se corrige un defecto en permisos administrativos. Además de verificar el caso original, conviene probar:
La corrección puede haber modificado lógica compartida, por eso conviene revisar zonas relacionadas.
Supongamos que se despliega una nueva versión de una tienda en línea con cambios en promociones y correcciones en pagos.
| Tipo de prueba | Casos posibles |
|---|---|
| Humo | Cargar aplicación, iniciar sesión, buscar producto, acceder al carrito. |
| Sanidad | Verificar que la nueva promoción se aplique en un caso básico y que el pago corregido no falle. |
| Regresión | Probar descuentos anteriores, compra sin promoción, pago aprobado, pago rechazado, stock y confirmación de pedido. |
La combinación ayuda a decidir si la versión puede seguir avanzando.
Al trabajar con regresión, humo y sanidad, algunos errores frecuentes son:
Para aplicar bien estas pruebas conviene:
Las pruebas de humo, sanidad y regresión ayudan a controlar el riesgo cuando el software cambia. Humo permite saber si una versión merece pruebas más profundas. Sanidad permite validar rápidamente un cambio puntual. Regresión permite comprobar que lo existente no se rompió.
Usarlas correctamente evita pérdidas de tiempo y mejora la confianza en cada entrega. La clave está en elegir el alcance adecuado según riesgo, impacto y estabilidad del producto.
En el próximo tema estudiaremos pruebas exploratorias y pensamiento crítico, una práctica esencial para descubrir problemas que los casos documentados pueden no cubrir.