Pruebas de humo vs pruebas de sanidad: cuándo usar cada una

La mitad de los equipos de QA usan «humo» y «sanidad» de forma intercambiable. La otra mitad discute sobre ello en los standups. Ambos grupos pierden horas por sprint en pruebas mal dirigidas, y la mayoría de ellos no tiene idea de que está ocurriendo.

La confusión va más allá de la terminología. Elige el tipo de prueba equivocado y tus ingenieros de QA pasarán una hora depurando una corrección de código de descuento mientras el inicio de sesión ha estado roto desde la compilación de la mañana. Elige al revés y una pasada de humo aprueba silenciosamente un lanzamiento que envía un error directamente a los clientes del lunes por la mañana. El Informe DORA 2025 encontró que los equipos que aceleran la entrega con IA están viendo mayor inestabilidad en la entrega cuando su disciplina de pruebas subyacente es débil. Los equipos que evitan esa trampa suelen combinar estas compuertas con servicios de pruebas de regresión que lo integran todo.

Este artículo te da la versión corta desde el principio: las pruebas de humo verifican si la compilación funciona, las pruebas de sanidad verifican si un cambio específico funciona. Luego explica cómo usar cada una sin agotar la capacidad del sprint y qué cuesta realmente cuando los equipos toman la decisión equivocada.

Qué hacen realmente las pruebas de humo

Una prueba de humo es la puerta de entrada, no el conjunto completo de pruebas. Responde a una pregunta clave: ¿esta compilación funciona correctamente? Si el inicio de sesión falla, la página principal devuelve un error 500 o la conexión a la base de datos se cae, la prueba de humo lo detecta en menos de diez minutos, la compilación se rechaza y nadie más pierde tiempo con ello.

La disciplina importa más que la definición. En cuanto una prueba de humo supera los diez minutos, los ingenieros dejan de confiar en ella y empiezan a buscar alternativas. Por eso, conviene mantenerla sencilla: de cinco a siete rutas críticas, sin casos límite ni validaciones complejas. Para una compilación de comercio electrónico, esto suele significar que la página de inicio se carga, el inicio de sesión funciona, la búsqueda arroja resultados, se muestra la página del producto, se añaden artículos al carrito y se inicia el proceso de pago. Esa es toda la prueba. Si alguna de ellas falla, la compilación fracasa desde el principio.

Aquí es donde la automatización demuestra su valía. Las pruebas de humo se ejecutan en cada fusión con la rama principal, en cada despliegue a un nuevo entorno, en cada compilación nocturna y en cada entrega de una versión candidata. Las pruebas de humo manuales con esa frecuencia son una receta para que se omitan. Las pruebas de humo automatizadas en CI/CD proporcionan al equipo una señal binaria en menos de diez minutos y liberan capacidad de control de calidad para tareas más complejas.

Un detalle importante a tener en cuenta: pasar humo no significa que la compilación sea buena. Significa que la compilación se puede probar.

Qué hacen realmente las pruebas de sanidad

Las pruebas de sanidad tienen la forma opuesta. Donde las pruebas de humo prueban ampliamente en toda la aplicación, las pruebas de sanidad se centran estrechamente en un área específica donde algo acaba de cambiar. ¿Un desarrollador corrigió un error en el código de descuento? La sanidad cubre el flujo de descuento, el recálculo del total del carrito y el paso de pago que depende de él. Nada más.

El desencadenante es siempre un cambio dirigido: una corrección de error, un ajuste de configuración, una mejora pequeña, una actualización de integración de terceros o un hotfix donde no hay tiempo para un ciclo de regresión completo. La sanidad asume que la compilación ya es estable (las pruebas de humo ya pasaron), por lo que omite las verificaciones básicas y va directamente a «¿se comportó este cambio correctamente y rompió algo adyacente?».

Las pruebas de sanidad suelen ser manuales. La razón es práctica: lo que se prueba cambia de compilación en compilación, por lo que las suites de sanidad programadas quedan obsoletas en semanas. Un ingeniero de QA que entiende el cambio que se está verificando superará a una suite programada que fue escrita para la corrección del sprint anterior. La excepción son las áreas recurrentes de alto riesgo como pagos o autenticación, donde los mismos tipos de parches llegan mes tras mes. Esas vale la pena automatizarlas una vez.

Si la sanidad falla, la corrección se rechaza, pero el resto de la compilación generalmente sigue en juego. Esa es la diferencia estructural entre las pruebas de humo y las pruebas de sanidad, y es por eso que el enfoque de sanity testing vs pruebas de humo importa en la práctica: los fallos de humo matan toda la compilación, los fallos de sanidad matan un segmento de ella.

Pruebas de humo vs pruebas de sanidad de un vistazo

Cuando se comparan ambos métodos, la distinción entre pruebas de humo y pruebas de cordura se hace evidente. La tabla a continuación muestra la misma comparación que todo responsable de control de calidad suele dibujar en una pizarra. Úsela como referencia.

El patrón es simple una vez que lo ves: el humo es amplitud, la sanidad es profundidad. Confúndelos y desperdicias horas.

La regla de decisión de 30 segundos

Todo el debate entre pruebas de humo y pruebas de cordura se resume en una regla: usa las pruebas de humo cuando tengas una nueva compilación y no sepas si funciona correctamente. Usa las pruebas de cordura cuando tengas una compilación estable y necesites verificar un cambio específico.

Cuatro ejemplos rápidos de la regla en la práctica:

• Nueva compilación entregada desde el desarrollo → humo
• Corrección de un solo error enviada contra una compilación que ya pasó las pruebas de humo esta mañana → sanidad
• Hotfix del viernes por la tarde en una compilación que ya está en producción → sanidad, con alcance ajustado
• Refactorización importante fusionada que tocó 14 archivos → humo primero, luego sanidad en cada módulo tocado

Ese es el árbol de decisión completo. El desencadenante es lo que cambió, no hace cuánto tiempo cambió ni cuán seguro se siente el desarrollador sobre la corrección.

Dónde encajan las pruebas de regresión

Las pruebas de humo y de cordura son indicadores clave. La prueba de regresión es la revisión completa que confirma que el resto de la aplicación sigue funcionando después de que todas las demás pruebas hayan pasado. Las pruebas de humo se ejecutan en cada compilación, las de cordura se ejecutan después de cada cambio previsto y las de regresión se ejecutan diariamente o antes de un lanzamiento.

La relación es jerárquica. Técnicamente, la prueba de cordura es un subconjunto de la prueba de regresión: reutiliza los casos de prueba de regresión, pero los limita al área modificada. El problema surge cuando los equipos tratan ambas como si fueran la misma suite. Una “prueba de cordura” que se ejecuta durante seis horas en una corrección urgente deja de ser una prueba de cordura y se convierte en un ciclo de regresión disfrazado de prueba de cordura, con lo que el equipo pierde la ventaja de velocidad que justificaba la realización de la prueba de cordura en primer lugar.

Las tres capas funcionan en conjunto: la prueba de humo controla la compilación, la prueba de cordura controla el cambio y la prueba de regresión controla el lanzamiento. Si se omite alguna capa, el costo se refleja en otro lugar.

Cuándo usar cada una, con desencadenantes reales

La teoría es sencilla. Lo difícil es tomar la decisión correcta cuando un desarrollador envía una solicitud de extracción por Slack a las 4:30 p. m. Aquí te mostramos los patrones que vemos con más frecuencia y la decisión adecuada para cada uno.

Un desarrollador fusionó una refactorización que afectó a 14 archivos. La compilación es nueva y el alcance del problema es amplio. Primero, ejecuta una prueba de humo, ya que podría haber algún fallo. Si la prueba es positiva, ejecuta una prueba de cordura en cada módulo afectado por la refactorización. Omite la prueba de regresión completa a menos que el lanzamiento sea inminente.

Se ha corregido un error de inicio de sesión. La versión que pasó la prueba inicial esa mañana ya no es necesaria. No hace falta repetir la prueba, ya que la base sigue igual. Se realiza una comprobación del flujo de inicio de sesión y de los dos flujos que dependen de él (restablecimiento de contraseña y bloqueo de cuenta). Diez minutos, no una hora.

Se necesita implementar una corrección urgente el viernes por la tarde para solucionar un error en el proceso de pago. La compilación es la misma que se ejecuta en producción, con un único cambio específico. La opción más sensata es centrarse en el proceso de pago. Realizar pruebas de detección de humo consumiría un tiempo valioso en flujos que no han cambiado desde la semana pasada.

Se lanzó una compilación nocturna con diez solicitudes de extracción fusionadas. Primero se ejecutaron las pruebas de humo automatizadas, seguidas de una prueba de regresión completa durante la noche. Este es el ritmo en el que la automatización se amortiza.

Se actualizó una API de pago de terceros. Esta es una integración fundamental, por lo que las pruebas básicas la cubren (¿la aplicación se inicia correctamente?, ¿se carga el proceso de pago?), y luego las pruebas de validación analizan en profundidad los flujos de pago.

Un diseñador implementó un cambio en el CSS. Resulta tentador omitir las pruebas por completo. No lo hagas. Realiza pruebas básicas en las pantallas afectadas y verifica que la autenticación siga funcionando, ya que los errores de especificidad del CSS realmente pueden interrumpir los flujos de inicio de sesión.

Qué cuesta cuando te equivocas

La mayoría de los equipos no miden el costo de una llamada de prueba incorrecta porque la pérdida se oculta dentro de la capacidad normal del sprint. Se manifiesta como “QA es lento” o “seguimos incumpliendo las fechas de lanzamiento” cuando el verdadero problema son las horas dedicadas a probar la capa incorrecta. Este patrón se agrava cuando los equipos agregan código generado por IA a una disciplina de pruebas deficiente: la encuesta de desarrolladores de Stack Overflow de 2025 encontró que el 45 % de los desarrolladores dice que depurar código generado por IA lleva más tiempo del esperado, y el 66 % cita soluciones “casi correctas, pero no del todo” como su principal frustración. Confundir las pruebas de humo con las pruebas de cordura produce el mismo tipo de impuesto oculto: horas que parecen trabajo pero que en realidad son retrabajo.

Ejecutar pruebas de sanidad en una compilación inestable

El escenario: un desarrollador sube una solución para un error en un código de descuento a las 9 de la mañana. El equipo de control de calidad la revisa, pasa directamente a realizar pruebas básicas en el flujo de descuentos, dedica una hora a validar casos límite y, alrededor de las 10:15, descubre que el servicio de inicio de sesión está generando errores 500 en la misma compilación y que lo ha estado haciendo desde la fusión de la mañana.

Esa hora se acabó, y con ella, el coste de cambiar de contexto al depurar la capa equivocada. El ingeniero de control de calidad ahora tiene que esperar a una nueva compilación, reiniciar su entorno y volver a empezar. Multiplícalo por el número de veces que este patrón se repite en un sprint y estarás perdiendo casi un día entero por ciclo. La solución es mecánica: bloquear cada nueva compilación antes de que la analicen los expertos. Sin excepciones.

Ejecutar pruebas de humo cuando necesitas sanidad

El escenario inverso es más peligroso porque se implementa. Un desarrollador corrige un error en un código de descuento. El equipo de control de calidad ejecuta la prueba de humo, que verifica que el inicio de sesión funcione, que la página de inicio se cargue y que se inicie el proceso de pago. Todo funciona correctamente. La corrección se implementa.

El error en el código de descuento nunca estuvo en la ruta de la suite de humo, porque esta no profundiza en el flujo de descuentos. Los clientes lo detectaron el lunes por la mañana. Ahora es un incidente de producción, no un ciclo de pruebas, y el costo se disparó de horas de control de calidad a horas de ingeniería, más tickets de soporte, más la pérdida de confianza. Este es precisamente el modo de falla que convierte una tasa de fallas de cambio DORA limpia en una mala. La prueba de cordura existe para detectar este tipo de errores. Ignorarla porque “la prueba de humo pasó” es la versión más común de la confusión entre la prueba de cordura y la prueba de humo, y la más costosa.

La lista de verificación del equipo de QA

La conclusión es práctica, no teórica. Aplica esta lista de verificación a tu proceso de control de calidad actual y la mayor parte del costo derivado de pruebas mal dirigidas desaparecerá.

Antes de cada compilación:

• La suite de humo se ejecuta automáticamente en CI/CD, se mantiene por debajo de diez minutos y cubre cinco a siete rutas críticas
• Si el humo falla, la compilación se rechaza y no se realizan más pruebas en ella
• Las suites de humo se revisan trimestralmente y se actualizan cuando cambian las funcionalidades críticas

Después de cada cambio dirigido:

• Identifica qué cambió y qué flujos son adyacentes a él
• Ejecuta las pruebas de sanidad solo en ese alcance, no en toda la aplicación
• Documenta el alcance de la sanidad en el pull request para que la siguiente persona sepa qué se cubrió y qué no
• Automatiza la sanidad solo cuando la misma área se parchea repetidamente

Antes de cada lanzamiento:

• La regresión completa se ejecuta contra una compilación que ya superó las compuertas de humo y sanidad
• La sanidad nunca sustituye a la regresión en un candidato a lanzamiento
• La confianza en el lanzamiento proviene de las tres capas pasando, no de una de ellas pasando bien

Una vez más, la regla: las pruebas de humo detienen la compilación, las pruebas de cordura detienen el cambio, las pruebas de regresión detienen el lanzamiento. La mayoría de los retrasos en el control de calidad se deben a la aplicación incorrecta de las pruebas. La solución no es una nueva herramienta, sino la disciplina para determinar qué prueba responde a cada pregunta. Si desea una segunda opinión sobre su proceso de control de calidad por parte de un equipo que aplica este método en cientos de proyectos publicados, contáctenos.