Pruebas de humo

En programación informática y pruebas de software, el smoke testing (también confidence testing, sanity testing,^[1] build verification test (BVT)^[2][3][4] y build acceptance test) es una prueba preliminar o prueba de cordura destinada a revelar fallos simples lo suficientemente graves como para, por ejemplo, rechazar una versión de software pendiente de lanzamiento. Las pruebas de humo son un subconjunto de casos de prueba que cubren la funcionalidad más importante de un componente o sistema, y se utilizan para ayudar a evaluar si las funciones principales del software parecen funcionar correctamente.^[1][2] Cuando se utilizan para determinar si un programa informático debe someterse a pruebas más detalladas, un smoke test puede denominarse pretest^[5] o intake test.^[1] Alternativamente, es un conjunto de pruebas ejecutadas en cada nueva compilación de un producto para verificar que dicha compilación es testeable antes de ser entregada al equipo de pruebas.^[6] En el paradigma DevOps, el uso de un paso de verificación de compilación (build verification test) es un rasgo distintivo de la etapa de madurez de integración continua.^[7]

Por ejemplo, un smoke test puede abordar preguntas básicas como “¿el programa se ejecuta?”, “¿la interfaz de usuario se abre?” o “¿al hacer clic en el botón principal ocurre algo?”. El proceso de smoke testing pretende determinar si la aplicación está tan defectuosa que hace innecesarias pruebas adicionales inmediatas. Como señala el libro Lessons Learned in Software Testing:^[8] “las pruebas de humo cubren ampliamente las características del producto en un tiempo limitado [...] si las funciones clave no funcionan o si los fallos principales aún no se han corregido, tu equipo no perderá más tiempo instalando o probando”.^[3]

Las pruebas de humo suelen ejecutarse rápidamente, aportando los beneficios de una retroalimentación más rápida, en contraste con la ejecución de baterías de pruebas más extensas, que naturalmente tardarían más.

La reintegración frecuente junto con smoke testing se encuentra entre las mejores prácticas de la industria.^[9] Idealmente, cada commit en un repositorio de código fuente debería activar una compilación de Integración Continua para identificar regresiones lo antes posible. Si las compilaciones tardan demasiado, es posible agrupar varios commits en una sola compilación, o en sistemas muy grandes efectuar una recompilación diaria. En general, recompilar y retestear tan a menudo como sea posible.

El smoke testing también lo realizan los testers antes de aceptar una compilación para pruebas adicionales. Microsoft afirma que, después de las revisiones de código, “el smoke testing es el método más rentable para identificar y corregir defectos en software”.^[10]

Las pruebas de humo pueden realizarse manualmente o mediante herramientas automatizadas. En el caso de herramientas automatizadas, el proceso que genera la compilación suele iniciar dichas pruebas.^{[cita requerida]}

Los smoke tests pueden ser pruebas funcionales o pruebas unitarias. Las pruebas funcionales ejercitan el programa completo con diversas entradas. Las pruebas unitarias ejercitan funciones, subrutinas u objetos individuales. Las pruebas funcionales pueden consistir en una serie de entradas programadas, incluso con mecanismos automatizados para controlar movimientos del ratón. Las pruebas unitarias pueden implementarse como funciones separadas dentro del propio código, o como una capa de ejecución que enlaza con el código sin modificarlo.^{[cita requerida]}