Pruebas de sanidad: qué verifican y cuándo ejecutarlas

Las pruebas de sanidad (sanity testing) son una verificación rápida y enfocada de que la corrección de un error o un cambio pequeño funciona como se esperaba y no ha roto ninguna función cercana. Normalmente, un tester prueba a mano la función afectada junto con algunas pantallas conectadas, sin preparar antes documentación formal de pruebas. El objetivo es obtener un sí o un no rápido antes de que la actualización llegue a los usuarios.

Cada pequeña corrección obliga a un equipo de software a tomar la misma decisión: publicar el arreglo ahora o esperar días a una ronda completa de pruebas. Saltarse las verificaciones supone el riesgo de que la reparación falle delante de los clientes, mientras que volver a probar todo el producto tras cualquier cambio menor ralentiza cada versión. Una revisión breve y dirigida ofrece a los equipos un camino intermedio.

Las pruebas de sanidad se confunden a menudo con las pruebas de humo (smoke testing), y un glosario del sector muy utilizado llegó a presentar ambos términos como sinónimos. A continuación, verá qué incluye cada revisión, cómo se relaciona este método con técnicas similares y cuándo basta con una verificación rápida. Conocer bien el producto acelera el proceso, por eso muchas empresas confían este trabajo a un equipo de QA dedicado.

¿Qué verifican realmente las pruebas de sanidad?

Una prueba de sanidad comienza cuando un desarrollador ha corregido un error. El código corregido pasa a una build, una nueva versión del software lista para probar. A partir de ahí, el tester revisa tres áreas:

• La corrección en sí: repetir exactamente los pasos que antes provocaban el error muestra si el resultado ahora es correcto.
• Las funciones que dependen de los mismos datos: cualquier pantalla que lea, muestre o envíe esa información recibe un vistazo rápido.
• El siguiente paso del usuario: si los clientes suelen ir a una página concreta después, el tester sigue también ese recorrido.

Todo lo que queda fuera de esas tres áreas se deja de lado a propósito. Un alcance reducido permite al equipo hacer una verificación rápida tras cada corrección menor sin retrasar las versiones.

Además, las pruebas de sanidad no suelen seguir un guion, es decir, el tester trabaja sin una lista de pasos preparada. La mayor parte del trabajo de QA planificado se basa en casos de prueba escritos, instrucciones que enumeran cada acción y el resultado esperado. En cambio, un tester experimentado que conoce la actualización decide sobre la marcha qué probar, lo que mantiene la revisión breve.

Un ejemplo de prueba de sanidad: una corrección, cinco verificaciones rápidas

Imagine una aplicación de reservas para una cadena de clínicas. Pacientes en otras zonas horarias informaron de que las citas confirmadas aparecían con una hora de diferencia. Un desarrollador corrige el código que convierte las horas locales y la nueva build llega para probarse.

Una prueba de sanidad sobre esa corrección horaria podría incluir cinco verificaciones:

1. Cambiar de zona horaria. Configure un teléfono en otra región, reserve una cita y compruebe que la pantalla de reserva muestra la hora correcta.
2. Abrir el correo de confirmación. Verifique que el correo indica la misma hora de la cita.
3. Añadir la visita a un calendario. Compruebe que el evento queda en la hora correcta.
4. Activar el recordatorio. Asegúrese de que la notificación que envía la aplicación indica la misma franja.
5. Reprogramar una vez. Mover la cita vuelve a ejecutar la conversión corregida, así que un solo cambio revela si la corrección también se mantiene ahí.

Si las cinco verificaciones se superan, la actualización puede publicarse con una confianza razonable. Cualquier fallo devuelve la corrección al desarrollador, junto con el paso exacto que falló. Fíjese en lo que el tester omitió: pagos, perfiles de pacientes, búsqueda y cualquier otra función que el cambio no tocó. Esas funciones reciben una revisión completa en la ronda habitual de pruebas antes de una versión más grande.

Pruebas de sanidad vs pruebas de humo: dos preguntas distintas

Las pruebas de humo suelen ejecutarse primero sobre una nueva build y responden a si el software es lo bastante estable como para examinarlo. Un tester, o un script que repite automáticamente los mismos pasos, abre la aplicación, inicia sesión y recorre las funciones principales. Si algo se bloquea o una pantalla clave no carga, la build se rechaza antes de empezar cualquier prueba más profunda. La prueba de sanidad llega después y plantea una pregunta más acotada: ¿funciona esta corrección concreta?

El International Software Testing Qualifications Board (ISTQB), que gestiona una certificación para testers muy extendida, incluía «sanity test» como sinónimo de «smoke test» en su glosario de 2023. La edición actual define las pruebas de humo como una verificación de que el software está listo para las pruebas planificadas. Las pruebas de sanidad ya ni siquiera aparecen ahí. Sin embargo, en el trabajo diario, muchos equipos de QA distinguen claramente entre ambos términos.

Para saber quién suele ejecutar las pruebas de humo y de sanidad, cuánto ayuda la automatización y qué suele desencadenar cada ejecución, lea nuestro artículo dedicado a las pruebas de humo vs pruebas de sanidad.

¿Qué lugar ocupan las pruebas de sanidad dentro de las pruebas de regresión?

Las pruebas de sanidad son la forma más acotada de las pruebas de regresión. Una regresión es una función que antes funcionaba y que se rompió tras una actualización posterior. Las pruebas de regresión completas vuelven a revisar el producto existente para detectar esos fallos, una tarea que puede llevar días en una plataforma grande. En cambio, una prueba de sanidad busca el mismo problema en un área mucho más pequeña, alrededor de una sola corrección.

Dividir el esfuerzo por tamaño se parece a la pirámide de pruebas, un modelo de planificación habitual con muchas verificaciones rápidas y baratas en la base y unas pocas amplias y lentas en la cima. La misma lógica se aplica aquí: las pruebas de sanidad se ejecutan tras casi cada corrección, mientras que una ronda completa de regresión espera a una versión.

Un término relacionado, el retesting (repetición de pruebas), consiste en confirmar que un error notificado ha desaparecido de verdad. Toda prueba de sanidad empieza ahí y luego mira un paso más allá, a las funciones vecinas de la corrección.

La siguiente tabla compara las tres verificaciones tratadas en esta sección, más las pruebas de humo como referencia:

¿Cuándo conviene ejecutar pruebas de sanidad?

Una prueba de sanidad encaja en situaciones en las que el cambio es pequeño, el riesgo está acotado y una ronda completa de regresión retrasaría la actualización sin apenas beneficio. Algunos ejemplos habituales:

• Un hotfix: esta corrección urgente se publica fuera del calendario habitual, a menudo mientras los clientes están afectados, así que la verificación tiene que ser rápida.
• Una corrección pequeña entre versiones: una etiqueta de precio errónea o un botón roto se pueden confirmar en el momento, sin necesidad de volver a probarlo todo.
• Un cambio de configuración: ajustar un parámetro, como un tipo impositivo o un interruptor que activa una opción, altera el comportamiento del producto sin código nuevo. Las pantallas afectadas siguen mereciendo un vistazo.
• Una actualización de terceros: cuando un proveedor de pagos o un servicio de mapas actualiza las herramientas de las que depende su aplicación, cada función conectada recibe una prueba de sanidad.

Algunas áreas de un producto se corrigen una y otra vez, como el proceso de pago o el inicio de sesión. Para esos puntos, las pruebas automatizadas pueden convertir las verificaciones de sanidad más habituales en scripts que se ejecutan a los pocos minutos de cada actualización. Así, los testers disponen de más tiempo para la exploración manual.

Cuándo no basta con una prueba de sanidad

Las pruebas de sanidad se quedan cortas cuando una actualización es grande o arriesgada, porque los efectos de un cambio amplio pueden extenderse mucho más allá del código editado. Por ejemplo, una función nueva, un rediseño o nuevas reglas de pagos o de acceso a cuentas pueden romper pantallas que una verificación acotada nunca visitaría.

Incluso un cambio pequeño puede ser arriesgado cuando afecta a un sistema central, como demuestra la caída de Google Cloud de junio de 2025. Una actualización rutinaria de datos con algunos campos vacíos activó un fallo en un código que se había publicado dos semanas antes sin salvaguardas. Según el informe de incidencia de Google, más de 60 productos de Google Cloud y Workspace dejaron de funcionar durante unas 3 horas como consecuencia. Los cambios que afectan a sistemas centrales necesitan una ronda completa de regresión y un despliegue gradual, en el que la actualización llega a un pequeño grupo de usuarios antes que al resto.

¿Cómo realiza QAwerk las pruebas de sanidad entre versiones?

En los proyectos de clientes, una prueba de sanidad en QAwerk tiene cuatro partes:

1. Leer el cambio. Revisamos el informe de error y las notas del desarrollador para entender el problema y la solución.
2. Enumerar lo que toca la corrección. A continuación, anotamos cada función y página que comparte datos con el código corregido y confirmamos esa lista con el desarrollador.
3. Revisar la nueva build a mano. El tester repite los pasos del error original y luego recorre cada pantalla conectada como lo haría un cliente.
4. Emitir un veredicto claro. Su equipo recibe una respuesta sencilla: publicar la actualización, devolver el código para más trabajo o programar pruebas de regresión completas porque el cambio llegó más lejos de lo previsto.

Por supuesto, no hay dos proyectos iguales. Estos son dos ejemplos de cómo se aplica esa rutina con clientes reales:

• Simuladores de formación quirúrgica: VirtaMed fabrica simuladores de realidad virtual en los que los cirujanos practican cirugía laparoscópica con retroalimentación háptica, es decir, el sentido del tacto recreado en los instrumentos. Programar un contacto realista entre las herramientas simuladas y los órganos es difícil. Uno de nuestros informes de error, por ejemplo, describía una vesícula biliar que atravesaba el tejido circundante. Cuando llega una corrección menor, nuestros testers confirman la reparación y después repasan las funciones principales del simulador. Esa combinación de pruebas de sanidad y de humo encaja con un producto en el que un solo cambio en la física puede afectar a todo un procedimiento.
• Verificación de identidad en móvil: Thirdfort estaba sustituyendo sus aplicaciones independientes de iOS y Android por una única versión multiplataforma, y las nuevas builds llegaban con frecuencia. Entre los errores críticos había fallos al enviar los datos de Source of Funds, un paso que muestra de dónde procede el dinero de un comprador. La aplicación también se bloqueaba al cargar la pantalla de verificación de identidad reforzada. Cada corrección se volvía a probar antes de publicar la siguiente actualización. Además, los ciclos de regresión cubrían los flujos de edición y de navegación hacia atrás en torno a ese paso.

Elegir qué pantallas revisar tras una corrección exige saber cómo encajan las piezas de un producto. Nuestros ingenieros de QA dedicados trabajan con un mismo cliente durante muchas versiones, así que los testers ya conocen las conexiones entre funciones. Cuando un cambio resulta más grande de lo esperado, el mismo equipo pasa directamente a las pruebas de regresión completas, sin traspasos ni nueva incorporación.

Revisemos su próxima corrección antes de publicarla.

Preguntas frecuentes

¿Qué son las pruebas de sanidad?

Las pruebas de sanidad son una revisión breve del software después de que un desarrollador corrija un error o publique una actualización pequeña, para confirmar que la corrección funciona y no ha dañado nada cercano. El nombre viene de la expresión inglesa «sanity check», que designa un vistazo rápido en busca de errores evidentes. Un ingeniero de QA suele trabajar a mano, cubriendo el área modificada y las funciones cercanas, para que la actualización pueda publicarse sin un ciclo completo de pruebas.

¿Las pruebas de sanidad son manuales o automatizadas?

La mayoría de las pruebas de sanidad se hacen a mano, porque cada corrección exige decidir de nuevo qué examinar, y un tester experimentado puede hacerlo rápido. La automatización compensa cuando los errores aparecen una y otra vez en el mismo lugar, como un proceso de pago que necesita reparaciones varias veces al mes. En ese caso, un pequeño conjunto de scripts guardados repite las mismas verificaciones tras cada actualización.

¿Cuál es la diferencia entre las pruebas de sanidad y el retesting?

La diferencia entre las pruebas de sanidad y el retesting es el alcance. El retesting responde a una sola pregunta: ¿ha desaparecido el problema notificado? Si un botón de exportación generaba un archivo vacío, el retesting consiste en pulsarlo otra vez y abrir el resultado. Una prueba de sanidad va más allá y prueba también funciones relacionadas, como otros formatos de exportación o el historial de descargas, para asegurarse de que la reparación no ha causado problemas nuevos.

¿Quién realiza las pruebas de sanidad?

Las pruebas de sanidad suelen realizarlas ingenieros de QA, idealmente especialistas que ya conocen el producto y entienden el cambio. A veces los desarrolladores hacen una verificación rápida antes de entregar una corrección, pero un tester independiente tiene más probabilidades de detectar efectos secundarios que el autor no esperaba. Las empresas sin QA interno suelen encargar las pruebas de sanidad a un socio externo que trabaja junto al equipo de desarrollo.

¿Pueden las pruebas de sanidad sustituir a las pruebas de regresión?

Las pruebas de sanidad no pueden sustituir a las pruebas de regresión, porque una prueba de sanidad solo examina un cambio y las funciones inmediatamente cercanas a la modificación. Las pruebas de regresión revisan todo el producto y detectan problemas en áreas que nadie ha tocado recientemente, como una pantalla de reembolsos que falla después de que alguien rehiciera el carrito de compra. Los equipos suelen ejecutar pruebas de sanidad sobre correcciones pequeñas durante el desarrollo y un ciclo completo de regresión antes de cada versión.