Una prueba de humo es una verificación rápida y superficial que se hace sobre una versión nueva de un software para comprobar que sus funciones esenciales arrancan y responden antes de invertir tiempo en pruebas más profundas. Si el sistema “echa humo” nada más encenderlo, no tiene sentido seguir.
En esta guía verás qué son las pruebas de humo, por qué ahorran tiempo, cómo ejecutarlas paso a paso, en qué se diferencian de las pruebas de cordura y cómo aplicar la misma lógica a la usabilidad antes de sentar a usuarios reales frente a tu producto.
¿Qué es una prueba de humo?
Una prueba de humo (smoke test, en inglés) es un conjunto pequeño de pruebas que se ejecuta sobre cada nueva compilación para confirmar que es “probable”, es decir, que lo bastante estable como para que el equipo de calidad dedique tiempo a revisarla. El glosario de ISTQB, citado por la propia Wikipedia, la define justamente así: pruebas ejecutadas en cada nueva versión para verificar que puede probarse antes de entregarla al equipo de testing.
El término viene del mundo del hardware. Cuando se conectaba por primera vez un dispositivo electrónico, la prueba consistía en ver si salía humo. Si no salía, el equipo pasaba a la siguiente fase. El software heredó la metáfora y la adaptó: aquí el “humo” es un error crítico que impide usar el producto, como no poder iniciar sesión o que la aplicación se cierre al abrirla.
Son pruebas anchas pero poco profundas. Tocan muchas funciones críticas, pero ninguna a fondo. No buscan encontrar todos los errores, sino responder a una sola pregunta: ¿vale la pena seguir probando esta versión?
Se mencionan con frecuencia como sinónimos las pruebas de verificación de compilación (BVT, por Build Verification Test) y las pruebas de confianza. En la práctica, casi todos los equipos las usan como sinónimo de prueba de humo, aunque algunos reservan BVT para la versión automatizada que se dispara en cada build.
¿Por qué son importantes las pruebas de humo?
Probar a fondo una versión rota es una de las formas más caras de perder tiempo. El equipo de QA ejecuta decenas de casos, descubre al cabo de horas que el inicio de sesión no funciona y todo lo anterior queda invalidado. Una prueba de humo detecta ese problema en minutos.
Este filtro temprano beneficia a todos. Los desarrolladores reciben aviso inmediato de que algo básico se rompió, cuando el cambio aún está fresco en su cabeza. Los testers dejan de recibir compilaciones inservibles. Y los responsables de producto ganan confianza en que lo que se está evaluando es una versión razonable.
- Detecta fallos críticos de despliegue o configuración en las primeras etapas.
- Evita gastar pruebas manuales en versiones inestables.
- Acorta el ciclo de retroalimentación entre desarrollo y calidad.
- Da una señal clara de “sí” o “no” para pasar a las pruebas funcionales o de aceptación, algo que encaja bien en el ciclo de vida del testing de software.
Conviene recordar el límite: aprobar una prueba de humo no significa que el software sea bueno, solo que no está roto de forma evidente. Es una condición necesaria, nunca suficiente.
¿Cómo se hace una prueba de humo? Paso a paso
El proceso es corto por diseño. Si tu prueba de humo tarda una hora, probablemente ya no es una prueba de humo.
- Identifica las funciones críticas. Define qué debe funcionar sí o sí: inicio de sesión, pagos, conexión con la base de datos, pantalla principal.
- Escribe casos de prueba simples para cada una. Un caso por función suele bastar.
- Despliega la nueva versión en un entorno de pruebas o de preproducción y ejecuta los casos, a mano o con automatización.
- Analiza el resultado. Si todo pasa, la versión avanza a pruebas más detalladas. Si algo falla, se devuelve al equipo de desarrollo y se corrige antes de continuar.
La clave del primer paso es ser selectivo. Una lista de cinco a quince comprobaciones esenciales, bien elegidas, vale más que cien casos mal priorizados. Pregúntate qué función haría que un usuario abandone el producto al instante si fallara.
En el tercer paso, la automatización suele ser la mejor inversión: los mismos casos se repiten en cada compilación y los resultados llegan en minutos. Aun así, una revisión manual rápida sigue siendo útil cuando el producto es nuevo y aún no justifica montar scripts.
El último paso es el que más se descuida. Define de antemano quién decide, y con qué criterio, que una versión se rechaza. Sin esa regla, los fallos “menores” se normalizan y la prueba de humo pierde su valor.
Tipos de pruebas de humo
No existe un único formato. Lo que cambia es quién ejecuta la prueba, cuándo y con qué herramientas.
| Tipo | Cómo funciona | Cuándo conviene |
|---|---|---|
| Manual | Una persona recorre las funciones esenciales siguiendo una lista corta. | Productos nuevos o equipos pequeños sin automatización. |
| Automatizada | Scripts que se ejecutan solos tras cada build, normalmente en integración continua. | Equipos con despliegues frecuentes. |
| Verificación de compilación (BVT) | Subconjunto de pruebas que valida la estabilidad de cada build antes de entregarla a QA. | Proyectos grandes con muchas compilaciones al día. |
| De hardware | Se enciende el equipo y se busca sobrecalentamiento o conexiones defectuosas. | Electrónica y dispositivos físicos. |
En proyectos grandes se combinan: una versión automatizada en cada commit y una breve revisión manual antes de cada entrega importante.
Mención aparte merece la industria de la fontanería, donde la expresión también existe: se inyecta humo en las tuberías para localizar fugas. Es la misma idea, una señal visible que revela un fallo sin desmontar todo el sistema.
¿Prueba de humo o prueba de cordura?
Se confunden con frecuencia. La prueba de humo es amplia y se hace sobre una versión nueva: ¿arranca y funciona lo esencial? La prueba de cordura (sanity testing) es estrecha y se hace después de un cambio concreto: ¿el arreglo funciona y no rompió lo que tenía al lado?
Dicho de otro modo, la de humo responde “¿merece la pena probar esta versión?” y la de cordura responde “¿este cambio específico se comporta como esperábamos?”. Algunas fuentes las tratan como sinónimos, pero separar los términos ayuda a que el equipo hable el mismo idioma.
Cómo aplicar una prueba de humo a la usabilidad
La lógica también sirve fuera del código. Antes de reclutar participantes para una prueba de usabilidad, conviene hacer una revisión interna que confirme que el prototipo o la versión se puede recorrer de principio a fin. Si un enlace está roto o el formulario no envía, tus participantes pasarán la sesión tropezando con errores técnicos en lugar de revelar problemas de diseño.
El resultado es un estudio más limpio y con mejores hallazgos. Esta es una práctica que recomienda el sentido común más que una norma publicada, y aun así evita sesiones desperdiciadas, que además cuestan dinero cuando hay incentivos para participantes.
- Define los flujos críticos: registro, búsqueda, compra, acceso a las funciones clave.
- Recórrelos tú mismo en el dispositivo y navegador de los participantes.
- Comprueba que los datos de prueba, cuentas y permisos funcionan.
- Corrige lo bloqueante antes de la primera sesión.
Una vez superado este filtro, el siguiente paso es observar a usuarios reales. Para eso puedes apoyarte en herramientas de investigación como QuestionPro UX, que permite realizar pruebas con usuarios y analizar sus resultados.
5 usuarios
Nielsen y Landauer (1993) estimaron que, con un promedio de 31% de problemas descubiertos por participante, cinco usuarios detectan alrededor del 85% de los problemas de usabilidad de un diseño.
Fuente: Nielsen Norman Group, a partir de Nielsen y Landauer, 1993
Es un promedio y no una garantía: simulaciones posteriores, como la de Laura Faulkner, encontraron que grupos de cinco descubrían desde un 55% de los problemas. Por eso la regla se aplica mejor en rondas pequeñas y repetidas, con correcciones entre una y otra, y esa es otra razón para empezar con una prueba de humo que elimine los errores obvios.
Buenas prácticas para unas pruebas de humo efectivas
Mantén el alcance pequeño y estable. Cuando la lista crece sin control, la prueba deja de ser rápida y el equipo empieza a saltársela. Revisa el conjunto cada cierto tiempo y retira lo que ya no sea crítico.
Automatiza lo repetitivo y deja a las personas lo exploratorio. Y trata un fallo de humo como bloqueante: la versión no avanza hasta corregirlo, sin excepciones por presión de calendario.
Documenta los resultados, aunque sea con un registro breve de versión, fecha y estado. Con el tiempo, ese historial muestra qué áreas se rompen con más frecuencia y dónde hace falta reforzar las pruebas más profundas, como las que describe la guía de QA testing.
Por último, combínalas con otras técnicas. Las pruebas de humo abren el camino, pero después necesitas pruebas funcionales, de regresión y de usuario. Si buscas el panorama completo de herramientas, revisa esta lista de herramientas de pruebas de software.
Conclusión
Las pruebas de humo son una inversión mínima con un retorno desproporcionado: unos minutos para evitar horas de pruebas inútiles sobre una versión rota. Funcionan en software, en hardware y hasta en el diseño de la experiencia de usuario.
Cuando tu producto ya supere ese primer filtro, el siguiente paso es comprobar cómo lo vive la gente real. QuestionPro UX te ayuda a llevar esa investigación con usuarios de la idea al análisis.
Preguntas frecuentes sobre las pruebas de humo
Es una verificación rápida y superficial que se ejecuta sobre una versión nueva para confirmar que sus funciones críticas funcionan. Si falla, la versión se rechaza y no pasa a pruebas más detalladas, lo que ahorra tiempo al equipo de calidad.
La prueba de humo es amplia y se aplica a cada versión nueva para ver si lo esencial funciona. La de cordura es más estrecha y se aplica tras un cambio concreto para confirmar que el arreglo funciona sin romper lo cercano.
Se hacen justo después de generar o desplegar una nueva compilación y antes de las pruebas funcionales o de regresión. En equipos con integración continua se ejecutan automáticamente en cada build.
No es obligatorio, pero es lo recomendable cuando hay despliegues frecuentes. Los mismos casos se repiten en cada versión, y automatizarlos da resultados en minutos. En proyectos pequeños puede bastar una lista manual corta.
Los suficientes para cubrir las funciones críticas y terminar en pocos minutos. Una lista de entre cinco y quince comprobaciones esenciales suele ser un buen punto de partida, aunque depende de la complejidad del producto.
