¿Qué es el smoke testing? Los cinco minutos que deciden si merece la pena seguir probando

Un smoke test es un recorrido corto y superficial por las cosas que una compilación tiene que saber hacer antes de que nadie le dedique tiempo. ¿Arranca? ¿Puede alguien iniciar sesión? ¿Se dibuja la página principal? ¿Se guarda un registro? Si algo de eso falla, la compilación se rechaza y nadie mira más allá, porque todo lo que viniera después sería probar una compilación que nunca mereció la pena probar.

No es exhaustivo a propósito. Para la exhaustividad está el resto de la suite, y ejecutarla contra una compilación rota gasta un día demostrando de cuarenta maneras que el inicio de sesión no funciona.

De dónde viene el nombre

Del hardware, y la historia es literal. Montas una placa, le das corriente y esperas a ver si sale humo. Si sale humo, no tiene sentido medir nada: el fallo es grosero e inmediato y la placa vuelve atrás. Los fontaneros usan la misma expresión para bombear humo por las tuberías y encontrar fugas antes de cerrar las paredes.

El software tomó prestado el término por la misma razón. Una compilación que no puede autenticar a un usuario ha echado humo, y la respuesta correcta es parar.

Lo que un smoke test no es

Tres términos se usan indistintamente en las reuniones diarias y son tres cosas distintas.

Smoke test

¿Merece la pena probar esta compilación? Amplio y superficial, se ejecuta primero, en cada compilación

Prueba de regresión

¿Ha dejado de funcionar algo que antes funcionaba? Profunda y lenta, se ejecuta cuando hay tiempo

Una prueba de sanidad es la tercera: una comprobación estrecha de que una corrección concreta funciona de verdad, ejecutada después de que un cambio entre en lugar de antes de empezar a probar. El smoke es amplio y superficial; la sanidad es estrecha y superficial; la regresión es amplia y profunda.

La diferencia práctica está en lo que pasa cuando una falla. Una prueba de regresión fallida es un error que se reporta. Un smoke test fallido es una decisión: esta compilación se queda aquí.

Qué entra en uno

La regla que mantiene útil una suite de smoke es que todo lo que hay en ella tiene que ser algo cuyo fallo haga inútil seguir probando. Esa lista es mucho más corta de lo que parece al principio.

Una suite típica para una aplicación web:

1. La aplicación arranca y la página de inicio devuelve 200
2. Un usuario conocido puede iniciar sesión
3. La lista principal carga y muestra datos
4. Se puede crear un registro y volver a leerlo
5. Un usuario autenticado puede cerrar sesión

Cinco comprobaciones, un minuto o dos, y ninguna afirmación sobre el comportamiento más allá de “esto ha ocurrido siquiera”. Sin casos límite, sin mensajes de validación, sin matrices de permisos. Todo eso pertenece a la suite que se ejecuta después.

Merece la pena nombrar dos formas de fallar, porque las dos son comunes. Una suite que crece hasta ochenta comprobaciones ya no es un smoke test, es una suite de regresión lenta con el nombre equivocado, y la gente empieza a saltársela. Una suite que solo prueba la página de inicio tampoco lo es: pasará en una compilación en la que no funciona nada más.

Cuándo se ejecuta, y quién lo mira

En cada compilación, antes que nada, y de forma automática. Un smoke test que alguien tiene que acordarse de ejecutar es uno que nadie ejecuta la tarde en que habría importado.

Lo habitual es una etapa de integración continua que corre después del despliegue a un entorno de pruebas y condiciona todo lo que viene detrás. Si falla, la tubería se detiene, la compilación no se promociona y al equipo se le avisa de inmediato: a los pocos minutos del commit, mientras quien lo escribió todavía recuerda qué cambió.

Esa inmediatez es la mayor parte del valor. El mismo defecto encontrado un día después le cuesta a alguien una hora de reconstrucción antes de poder siquiera empezar.

Cómo escribir el primero

Empieza por el camino más corto que un usuario real recorre en tu producto, y comprueba solo que cada paso se completa.

• Elige cinco cosas, no cincuenta. Si no puedes defender que un fallo hace inútil seguir probando, no es una comprobación de smoke.
• Usa una cuenta conocida y datos conocidos. Un smoke test que depende de lo que haya en la base de datos en ese momento fallará por razones que no tienen que ver con la compilación.
• Comprueba existencia, no corrección. “El total de la factura es 45,00” pertenece a otro sitio. “Se ha dibujado una página de factura” pertenece aquí.
• Mantenlo por debajo de cinco minutos. En cuanto cueste más, alguien lo sacará del camino crítico, y entonces dejará de condicionar nada.
• Falla en voz alta. Una tubería roja de la que nadie se entera es una tubería verde con pasos de más.

Cuando falla

Un smoke test fallido no es un informe de error. Es la señal de que hace falta uno, y los dos se confunden con facilidad: “ha fallado el smoke test 3” no le dice nada a quien lo recoge sobre lo que ha pasado.

Lo que necesita es lo mismo que necesita cualquier defecto: qué se esperaba, qué ocurrió en su lugar, en qué entorno y con todo lo que el navegador o el ejecutor registraron en ese momento. Nuestra guía para escribir un informe de error que se arregle es la versión larga, y su plantilla es un archivo que puedes entregar a quien esté en triaje.

Para un fallo con el que alguien tropieza a mano, y no uno que atrapó la tubería, el contexto es la parte que suele perderse.

La versión corta

Un smoke test responde a una pregunta: ¿merece esta compilación el tiempo de alguien? Cinco comprobaciones, ejecutadas primero, ejecutadas siempre, y un fallo detiene la cadena en lugar de llenar el gestor de incidencias. Todo lo demás que quieras saber sobre la compilación es una pregunta que solo vale la pena hacerse cuando esta ya se ha respondido que sí.