Una prueba de humo responde una sola pregunta antes que ninguna otra: ¿la build enciende? Si arranca, si abres la app y las funciones principales responden sin caerse, la build merece pruebas de verdad. Si no, la rechazas ahí mismo y le ahorras al equipo horas de probar algo que estaba muerto desde el principio.
El nombre viene de la electrónica, no del software. Cuando armabas un circuito nuevo, lo conectabas y mirabas si salía humo. Si salía humo, no hacía falta seguir midiendo con el multímetro: el aparato estaba frito. Esa misma idea (una comprobación tosca y rapidísima para decidir si vale la pena continuar) es lo que hoy llamamos smoke testing.
01 · la puertaQué es una prueba de humo y qué no es
Una prueba de humo es un conjunto pequeño de comprobaciones que verifican que las funciones más críticas de una build funcionan a un nivel básico. No busca profundidad: busca amplitud superficial. Toca lo esencial (¿arranca la aplicación?, ¿carga la pantalla principal?, ¿se puede iniciar sesión?, ¿responde el flujo central?) y se detiene ahí.
El ISTQB la define como un subconjunto de todos los casos de prueba definidos, que cubre la funcionalidad principal de un componente o sistema, para comprobar que las funciones cruciales trabajan pero sin molestarse en detalles finos [1]. Esa es la clave: es una puerta de entrada, no una inspección completa.
La prueba de humo no dice "esto funciona bien". Dice "esto merece que lo probemos en serio".
Lo que una prueba de humo no es: no es una suite de regresión, no valida reglas de negocio a fondo, no cubre casos límite ni rutas raras. Si intentas meterle todo eso, deja de ser una prueba de humo y pierde su única virtud, que es ser rápida. Un smoke test que tarda cuarenta minutos ya fracasó como smoke test.
02 · la confusiónSmoke y sanity no son lo mismo
Casi todo el mundo mezcla smoke testing con sanity testing, y se entiende por qué: las dos son comprobaciones rápidas y superficiales. Pero responden preguntas distintas y llegan en momentos distintos.
La prueba de humo mira amplitud: toca las funciones principales de toda la build, recién llegada, para decidir si es estable como para probarla. La prueba de sanidad (sanity) mira profundidad estrecha: cuando ya hubo un arreglo o un cambio pequeño, comprueba que esa área concreta se comporta de forma razonable antes de invertir en una regresión completa. El ISTQB describe la prueba de sanidad como la ejecución para determinar si una parte del sistema sigue funcionando de manera razonable tras un cambio menor [1].
Una forma de recordarlo: el humo pregunta "¿está viva la build entera?"; la sanidad pregunta "¿este parche puntual tiene sentido?". El humo suele correr sobre cada build; la sanidad, sobre builds ya estables a las que se les tocó algo concreto.
Si acabas de recibir una build entera, corre humo. Si acabas de recibir un arreglo puntual sobre una build que ya funcionaba, corre sanidad. Y ninguna de las dos sustituye a la regresión: solo deciden si vale la pena llegar a ella.
03 · el pipelineDónde encaja el smoke test en tu flujo
La prueba de humo brilla en integración continua. Cada vez que se genera una build (por un merge, por un despliegue a un entorno de pruebas), un smoke test automatizado corre primero y decide en minutos si la build sigue con vida. Si falla, el pipeline se detiene, avisa, y nadie más pierde tiempo con esa versión.
El orden importa por economía: las pruebas más baratas y rápidas van primero. Correr una suite completa de horas sobre una build que ni compila bien es tirar recursos. El smoke test es el filtro de bajo costo que protege a las pruebas caras que vienen detrás. Esta idea de escalonar (muchas comprobaciones baratas abajo, pocas y caras arriba) es la lógica de la pirámide de pruebas descrita por Cohn [2], y el smoke test es la primera compuerta de ese ascenso.
Un buen smoke test tiene tres propiedades: es rápido (segundos o pocos minutos), es estable (si falla, es porque la build falló, no porque la prueba es frágil) y es automatizado (corre solo, en cada build, sin que nadie lo recuerde). Un smoke test manual que alguien ejecuta "cuando se acuerda" pierde casi todo su valor como puerta.
Para posicionar esto en tu proceso no necesitas nada exótico: bastan cinco o diez casos que cubran los caminos que más duelen si se rompen. Arrancar, autenticar, cargar el dato principal, completar la acción central. Si esos cuatro respiran, la build está viva y puedes soltar la suite de verdad. Si uno se cae, ya sabes que no hace falta seguir: hay humo, y el trabajo vuelve a desarrollo.
Cinco minutos de humo compran horas de pruebas que no desperdicias.
El smoke testing no es glamuroso ni profundo, y esa es exactamente su gracia. Es la pregunta más barata que puedes hacerle a una build, y la respuesta que más tiempo te ahorra. Antes de probar a fondo, comprueba que enciende.
Fuentes
- ISTQB (International Software Testing Qualifications Board). Standard Glossary of Terms Used in Software Testing. Definiciones de "smoke test" y "sanity test". Disponible en glossary.istqb.org.
- Cohn, M. (2009). Succeeding with Agile: Software Development Using Scrum. Addison-Wesley. Capítulo sobre la pirámide de automatización de pruebas (test automation pyramid).
- ISO/IEC 25010:2011. Systems and software engineering. Systems and software Quality Requirements and Evaluation (SQuaRE). System and software quality models. International Organization for Standardization. Modelo de características de calidad (funcionalidad, fiabilidad) que las pruebas de humo verifican a nivel básico.