Smoke Test

Ref. 1. - Jenkins, Nick. A Software Testing Primer: An Introduction to Software Testing. En http://www.softwaretestinghelp.com/ (en línea). 2008. Disponible en Internet: http://www.nickjenkins.net/prose/testingPrimer.pdf. El Smoke Test Una parte importante del proceso de control de releases es la verificación de la funcionalidad básica de un release particular. Usualmente los errores en la construcción, armado o proceso de compilación pueden resultar en fallas en el release entregado. Es frustrante y no tiene sentido, perder el tiempo identificando y aislando estas fallas, dado que son simples artefactos de una mala contrucción/compilación. La funcionalidad básica de un release debe ser verificada a través del uso de smoke tests. La frase Smoke test hace referencia a una serie de pruebas de alto nivel, que tienen como objetivo asegurar la funcionalidad principal o crítica del release. Esto significa que, antes de ser pasado a cualquier otro grupo, el equipo responsable de la compilación de un nuevo release debe correr una serie de tests simples para determinar que ese release está funcionando correctamente. De esta forma se detectarán rápidamente errores groseros de funcionalidad y se prevendrá cualquier atraso en la liberación del release. Estos tests pueden ser automatizados como parte del proceso de compilación/release y los resultados chequeados antes de que el release sea librado. El término "smoke testing" surge de la industria eléctronica. Si un ingeniero diseña un circuito o un sistema eléctrico el primer test al que lo somete es enchufarlo a la energía brevemente y encenderlo. Si sale humo se lo apaga y se lo regresa a la mesa de diseño (o al soldador). Si no aparece humo entonces básicamente esta bien y se le aplican otros test para ver si funciona correctamente. El mismo principio puede ser aplicado en el desarrollo de software. ¿Que criterios podemos usar para identificar los test que debemos de incluir en el Smoke Test? Es aconsejable que incluyamos en estas pruebas los test cases de los flujos principales que sean end to end, además de los casos de test de las nuevas funcionalidades implementadas. Los flujos end to end nos asegurarán de que las partes de la aplicación que no sufrieron modificaciones, sigan funcionando correctamente. Y por otro lado, los casos de test de las nuevas funcionalidades nos permitirán verificar que la aplicación está lo suficientemente estable para comenzar a ejecutar nuestra serie de pruebas. Este tipo de pruebas las podemos usar como criterio para determinar si un release debe o no debe subirse a nuestro entorno de pruebas. ¿Cual sería el flujo a seguir? Si todos los test han pasado satisfactoriamente, el release puede ser deployado en nuestro entorno; en caso contrario, se reportan los defectos encontrados, desarrollo los arregla (corrigiendo el código) y genera una nueva versión, sobre la que se vuelve a ejecutar el smoke test otra vez. Así hasta que esté estable y listo para comenzar las pruebas. En muchas ocasiones, el Smoke Test va asociado con el Daily Build. Una buena práctica es automatizar los Smoke Test y ejecutarlos todos los días después del Daily Build. Un práctica muy aconsejable, aunque difícil de llevar a cabo. Llevando a cabo esta práctica, podremos saber a diario si los cambios introducidos en el código han roto alguna funcionalidad. ¿Qué es el ''Daily Build''? El principio de este método es construir y probar las funcionalidades disponibles del producto todos los días. ¿Entregar diariamente código? Los equipos de desarrollo envían diariamente código acompañado con un documento de entregar al builder (el responsable de armar el producto). Construir un build todos los días vale la pena solo si modificaciones y/o nuevo código son agregados al producto. Si hubo corrección de defectos, debe indicarse que defectos se corrigieron.