Smoke, sanity y regression testing son tres verificaciones distintas que responden preguntas distintas en momentos distintos. El smoke test es amplio y superficial: corre apenas hay un build o un despliegue nuevo, para decidir si vale la pena seguir probando. El sanity test es angosto y profundo: se ejecuta tras un arreglo puntual, para confirmar que esa zona quedó bien. El regression test repite pruebas ya ejecutadas para verificar que el resto del sistema sigue funcionando después de un cambio. Ninguno es lo mismo que el retesting (o confirmation testing), que consiste en re-ejecutar el caso puntual que había fallado para confirmar que el defecto se corrigió.
Ver índice de contenidos
Tres preguntas distintas, tres momentos distintos
«Smoke test», «sanity test» y «regression test» responden preguntas distintas en momentos distintos del ciclo de un cambio. Confundirlas es fácil: durante años los glosarios trataron smoke y sanity como sinónimos. La práctica actual los separa por dos ejes: cuánto alcance cubren —cuántas funcionalidades tocan— y con qué profundidad las verifican —cuántos casos por funcionalidad, incluidos los bordes.
El smoke test (también confidence test o build verification test) recorre la funcionalidad principal de un sistema para decidir si funciona lo suficiente como para empezar el testing planificado. El sanity test es una comprobación acotada pero más profunda, normalmente tras un cambio o una corrección puntual, para decidir si vale la pena seguir con pruebas más extensas. El regression test repite pruebas ya ejecutadas para confirmar que el software modificado sigue cumpliendo lo que ya cumplía y que no se coló ningún defecto nuevo.
La comparativa: alcance, profundidad, momento y decisión
La tabla resume las diferencias que más importan para decidir cuál corresponde ejecutar. Ninguna reemplaza a las otras: en un pipeline maduro las tres conviven.
| Aspecto | Smoke test | Sanity test | Regression test |
|---|---|---|---|
| Alcance | Ancho: la funcionalidad principal de todo el sistema | Angosto: solo la zona que tocó el cambio | Amplio: lo que puede haberse visto afectado, seleccionado por riesgo |
| Profundidad | Superficial: el camino principal, sin casos límite | Profunda en esa zona puntual, con casos límite incluidos | Variable, según qué tan crítica sea cada área seleccionada |
| Momento de ejecución | Apenas hay un build o un despliegue nuevo | Después de un arreglo o un cambio puntual | Antes de un release, o tras acumular varios cambios |
| Duración típica relativa | La más corta de las tres | Corta, acotada al área revisada | La más larga, salvo que se seleccione con criterio de riesgo |
| Qué decisión habilita | Si vale la pena seguir con el testing planificado | Si conviene invertir en pruebas más extensas | Si el sistema sigue cumpliendo lo que ya cumplía |
La fila de duración es relativa a propósito: no existe un tiempo fijo que valga para cualquier proyecto, porque depende del tamaño del sistema. Lo que sí se mantiene es el orden relativo: el smoke suele ser la suite más corta, porque su objetivo es descartar rápido un build roto, no cubrir un caso a fondo.
Smoke testing: ancho y superficial
Un smoke test se ejecuta apenas hay un build nuevo o un despliegue reciente. Cubre ancho: toca las funcionalidades principales —que la aplicación inicie, que el login funcione, que la pantalla principal cargue, que un checkout no explote— pero con poca profundidad: solo el camino principal de cada una, sin casos límite.
En el foro de Underc0de, Mr. Bones lo describió en agosto de 2023 como una prueba rápida tras un despliegue para validar el flujo principal, con tres claves que siguen vigentes: foco en lo esencial, automatización —porque se ejecuta con mucha frecuencia— e integración continua, porque tiene más valor cuando corre solo en cada build.
// Ejemplo ilustrativo de una suite de smoke, no un comando probado
describe('smoke: build recién desplegado', () => {
test('la aplicación inicia y responde', () => {});
test('el login acepta credenciales válidas', () => {});
test('la pantalla principal carga sin errores', () => {});
test('el checkout llega hasta la confirmación', () => {});
});
// Cuatro casos, uno por funcionalidad crítica: ancho, no profundoSi un smoke test falla, la conclusión práctica es simple: el build tiene un problema grave y no vale la pena seguir probando hasta que se corrija. Por eso a veces se lo llama «prueba de aceptación del build»: no busca defectos finos, busca razones para no seguir probando todavía.
Sanity testing: angosto y profundo
El sanity test aparece después de un arreglo puntual, un cambio menor o un parche, no después de un build completo. Se enfoca en una porción angosta del sistema —la que el cambio pudo haber afectado— pero la revisa con más profundidad que un smoke: incluye casos límite y variantes de esa zona puntual, no solo el camino feliz.
Un ejemplo: si se corrigió un error en el cálculo de un descuento por volumen, un sanity test no vuelve a probar todo el carrito; prueba distintas cantidades alrededor del descuento —antes del umbral, en el umbral, muy por encima— para confirmar que el arreglo funciona y no rompió los casos vecinos. Por eso a menudo se lo trata como un subconjunto acotado del regression testing, ejecutado antes de decidir si conviene correr la suite completa.
No hay ningún hilo del foro de Underc0de dedicado específicamente a sanity testing. Esta sección se armó con el glosario de ISTQB como fuente, no con un aporte previo de la comunidad.
Regression testing: repetir para confirmar que nada se rompió
El regression test repite pruebas ya ejecutadas antes, para confirmar que un cambio —cualquiera, no solo la corrección de un bug— no introdujo defectos nuevos en partes del sistema que no deberían haberse visto afectadas. A diferencia del smoke (tras cada build) y del sanity (tras un cambio puntual), el regression suele ejecutarse antes de un release o tras acumular varios cambios, y es habitualmente la suite más amplia de las tres.
Amplia no significa «toda la suite, siempre». Correrla completa cada vez es costoso y crece junto con el proyecto. La práctica recomendada es la selección basada en riesgo: priorizar los casos que cubren las áreas más afectadas, las más usadas y las de mayor impacto si fallan. Por su naturaleza repetitiva, el regression testing es de los candidatos más claros para automatizar.
Tampoco hay, en el foro de Underc0de, un hilo dedicado a regression testing. Como con sanity, esta sección se apoya en documentación oficial de ISTQB.
Por qué regression no es lo mismo que confirmation testing (retesting)
Este es el error que más vale la pena corregir: regression testing y confirmation testing —también llamado retesting— no son la misma actividad, aunque casi siempre se ejecutan juntos y sobre el mismo cambio.
El retesting (o confirmation testing) consiste en volver a ejecutar específicamente el caso de prueba que había fallado, para confirmar que el defecto quedó corregido: se repite exactamente lo que falló, con los mismos datos y los mismos pasos.
El regression testing, en cambio, no se limita al caso que falló: repite otras pruebas que ya venían pasando, para confirmar que el arreglo no rompió algo distinto en otra parte del sistema. No verifica que el defecto se corrigió —eso ya lo confirmó el retesting— sino que corregirlo no generó un problema nuevo en otro lado.
| Aspecto | Retesting (confirmation testing) | Regression testing |
|---|---|---|
| Qué repite | El caso exacto que había fallado | Casos que ya pasaban, distintos del que falló |
| Qué confirma | Que el defecto reportado quedó corregido | Que el arreglo no rompió otra cosa |
| Alcance | Un caso puntual | Un conjunto más amplio, seleccionado por riesgo |
| Cuándo se hace | Inmediatamente después de la corrección | Antes de dar por cerrado el cambio, o antes de un release |
Ejemplo: se reporta que un cupón de descuento no se aplica en el checkout. Se corrige el cálculo. El retesting es volver a probar exactamente ese cupón para confirmar que ahora se aplica. El regression testing es, además, correr las pruebas de envío, impuestos y total del carrito —que no tenían nada que ver con el cupón— para asegurarse de que el arreglo no rompió esas cuentas. En un flujo real, primero se hace el retesting y recién después el regression.
Errores frecuentes
- Confundir regression con confirmation testing (retesting). El retesting confirma un defecto puntual; el regression confirma que el resto sigue andando. No son intercambiables.
- Creer que smoke y sanity son sinónimos. Lo eran en glosarios antiguos; la práctica actual los separa por alcance y profundidad.
- Pensar que regression es «correr toda la suite siempre». Sin selección basada en riesgo, la suite crece hasta volverse imposible de ejecutar a tiempo.
- Saltarse el smoke por apuro. Ahorra minutos y puede costar horas si el build tenía un problema serio que nadie notó a tiempo.
- No automatizar lo repetitivo. Smoke y regression se repiten con la misma lógica: son los candidatos naturales para automatizar primero.
- Dar por buena una suite de sanity sin documentarla. Si nadie registra qué se revisó, la próxima persona repite el trabajo o asume una cobertura que no existe.
Preguntas frecuentes
¿En qué se diferencian smoke, sanity y regression testing?
Se diferencian en alcance, profundidad y momento de ejecución. El smoke test es ancho y superficial: recorre la funcionalidad principal de todo el sistema con poca profundidad, apenas hay un build o un despliegue nuevo. El sanity test es angosto y profundo: se acota a la zona de un cambio puntual, mirando también sus casos límite, y se ejecuta después de una corrección menor. El regression test es amplio: repite pruebas ya ejecutadas en distintas partes del sistema para confirmar que un cambio no rompió algo, y suele ejecutarse antes de un release. Ninguno reemplaza a los otros dos: conviven, cada uno respondiendo una pregunta distinta en un momento distinto.
¿Cuándo se ejecuta cada uno en el pipeline?
El smoke test es el primero: corre apenas termina un build o un despliegue, muchas veces de forma automática. El sanity test entra después, atado no a un build sino a un cambio puntual: se ejecuta luego de una corrección menor, para decidir si ese arreglo anda lo suficientemente bien como para seguir. El regression test se ubica más adelante, típicamente antes de un release o tras acumular varios cambios, y da la confianza final de que el conjunto sigue funcionando.
¿Sanity testing es lo mismo que retesting?
No, aunque los dos ocurren después de un cambio y por eso se confunden. El retesting, o confirmation testing, consiste en volver a ejecutar exactamente el caso de prueba que había fallado, con los mismos pasos y datos, para confirmar que el defecto quedó corregido. El sanity test es más amplio: no se limita al caso puntual que falló, sino que revisa con profundidad toda la zona que el cambio pudo haber afectado, incluidos casos límite que ni formaban parte del reporte original. Ante una corrección, primero se hace el retesting del caso exacto y, si el equipo quiere más confianza, se agrega un sanity alrededor de esa zona. Son actividades complementarias, no sinónimos.
¿Se pueden automatizar los tres?
Sí, los tres se pueden automatizar, pero no rinden igual. El smoke test es de los candidatos más claros: es corto, se repite en cada build y verifica siempre lo mismo, así que engancharlo a la integración continua suele ser buena inversión. El regression test también lo es, por el mismo motivo: repite pruebas estables una y otra vez. El sanity test es el más particular: al estar acotado a un cambio puntual y muchas veces improvisado —qué revisar depende de qué se tocó—, una parte suele hacerse a mano, aunque si un tipo de cambio se repite seguido conviene automatizar esa porción. La regla general: cuanto más se repite una prueba sin cambiar su lógica, más conviene automatizarla.
¿Cuántos casos debería tener una suite de smoke?
No hay un número fijo que sirva para cualquier proyecto: depende de cuántos flujos críticos tenga el sistema, y cualquier cifra concreta sería una afirmación sin sustento. Lo útil es el criterio, no la cantidad: una suite de smoke debería cubrir los caminos que, si estuvieran rotos, invalidarían cualquier prueba posterior —que la aplicación inicie, el login funcione, las pantallas centrales carguen, un flujo clave llegue a su fin sin errores— y nada más. Si empieza a incluir casos límite o funcionalidades secundarias, dejó de ser un smoke test. La señal de que está bien dimensionada: corre rápido y casi nunca falla salvo que el build tenga un problema real.
¿Qué pasa si un smoke test falla?
Es una señal de que el build tiene un problema serio en algo esencial, y la respuesta esperada es frenar ahí, no seguir con testing más detallado. Por eso a veces se lo llama prueba de aceptación del build: no busca defectos finos, decide si ese build merece más tiempo de prueba. En un pipeline con integración continua, un smoke fallido suele bloquear el avance y notificar al equipo responsable, en lugar de dejar que el resto de las pruebas corra sobre una base rota. Ejecutar sanity o regression sobre un build que no pasó el smoke suele ser trabajo perdido: cualquier fallo posterior puede deberse al mismo problema de base.
Fuentes
Documentación oficial y aportes de la comunidad consultados para esta guía. Fecha de consulta: 29 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, foro. ¿Qué es el Smoke Test y por qué es tan relevante?, por Mr. Bones, sección QA (Quality Assurance). Aporte que dio origen a la sección de smoke testing de esta guía. No se encontró hilo previo sobre sanity ni sobre regression testing.
Documentación oficial
- ISTQB. Glosario: regression testing. Definición de referencia, parafraseada, usada para diferenciar regression de confirmation testing.
- ISTQB. Glosario: confirmation testing. Definición de retesting, parafraseada, base de la distinción central de esta guía.
- ISTQB. Certified Tester Foundation Level. Programa de certificación de referencia en fundamentos de testing.