A la hora de hablar de testing, lo cierto es que hay muchísimos tipos de pruebas, con nombres distintos y que se llevan a cabo con objetivos diferentes.
Incluso hay veces (como vimos la semana pasada, en el post de Pruebas de regresión. O cómo evitar que los fallos que se habían arreglado en el software vuelvan a aparecer.), que cierto tipo pruebas en función del objetivo al que se orienten, se llaman de una manera u otra.
Poniendo el ejemplo de la semana pasada, pruebas funcionales, unitarias… que se ejecutan para comprobar que los cambios en el código no hacen reaparecer errores que ya habíamos solucionado, se llaman pruebas de regresión.
Y esto en muchas ocasiones, puede llevar a confusión.
Por eso, la semana pasada hablé sobre las pruebas de regresión. Esta semana, me gustaría explicar de forma sencilla qué es el smoke test y para qué sirve.
——-
Imagínate que desarrollamos una aplicación tipo Gmail, muy sencilla, que se conecta a una base de datos para mostrar los correos, y podemos hacer lo típico: crear correos nuevos, borrarlos etc.
Llega un momento en que queremos pasar a la gente de QA la aplicación para que haga pruebas funcionales sobre ella. Así que se hace un build del código (a grandes rasgos esto es compilar y generar un ejecutable) y se despliega, se pasa el código la máquina de QA.
Entonces llega alguien de QA para hacer las pruebas y… la aplicación no se abre. O los correos no se muestran, porque hay un error en la conexión con la base de datos.
Es decir, la funcionalidad más crítica de la aplicación no funciona. Aunque la compilación haya sido un éxito, el build no sirve porque realmente QA no ha podido ni siquiera empezar a probar a fondo la aplicación.
Y lo que es peor, hemos perdido tiempo en todo este proceso, en pasar el software a QA para nada.
Aunque este es un ejemplo muy sencillo, aquí es donde nos ayuda el smoke test.
¿Qué es el smoke test?
El smoke test se realiza después de ejecutar una build del software para asegurarnos de que ciertas funcionalidades básicas y críticas del programa funcionan correctamente.
Aquí no buscamos probar todo el sistema exhaustivamente (para ello están otro tipo de pruebas) sino que buscamos probar la funcionalidad más crítica: verificar que las conexiones se realizan correctamente, que se lanza la aplicación correctamente, que funcione el login, que el botón principal de la aplicación funcione etc.
Digamos que si queremos hacer smoke test, lo que tendremos que hacer primero es identificar las funcionalidades básicas, críticas que debe satisfacer nuestro producto y desarrollar los casos de prueba para probar esas funcionalidades básicas.
Después, cada vez que se hace una build del producto, esta suite de smoke test debe ejecutarse. Si se detectan fallos en estos elementos básicos, se corrigen, y si no se continua con otro tipo de pruebas que analicen la aplicación más en profundidad (regresión, funcionales…).
Pero no os confundáis, como smoke test podríamos tener también pruebas funcionales, unitarias o de sistema…, siempre que comprueben si las cosas críticas de la aplicación funcionan.
Si estas funcionalidades críticas de nuestra aplicación no funcionan (valga la redundancia), no tiene sentido seguir con otras pruebas más exhaustivas, ya que perderemos tiempo para nada.
Además, a lanzar smoke test para verificar que una build es correcta, se le llama también test de verificación del build.
Bajo smoke test pueden englobarse pruebas manuales o automáticas. Aunque como son chequeos, se suelen automatizar para ser más rápidos y ejecutarlos periódicamente.
Las buenas prácticas de hacer build periódicos y el smoke test ya tienen sus años.
Además, el smoke test se suele incluir en el proceso de integración continua, por ejemplo como una batería de pruebas más ligeras que se ejecutan después del build y antes de las pruebas de regresión (La integración continua y el «smoke test»).
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
muchas gracias, hasta ahora no tenía claro que era el smoke test.
Muchas gracias, me encantó la explicación con los ejemplos simples, claros y concisos =)
Gracias!!! Buen post!!!