¿Qué es la prueba de humo?
Tomas Hamilton
⚡ Resumen inteligente
Las pruebas de humo determinan si una compilación nueva es lo suficientemente estable como para realizar pruebas. Esta página explica cuándo ejecutarlas, quién las ejecuta, cómo funciona el ciclo y cómo las suites automatizadas controlan los flujos de trabajo de entrega modernos.
¿Qué es la prueba de humo?
Prueba de humo es un proceso de prueba de software que determina si la compilación de software implementada es estable o no. La prueba de humo es una confirmación para que el equipo de control de calidad proceda con más pruebas de software. Consiste en un conjunto mínimo de pruebas ejecutadas en cada compilación para probar las funcionalidades del software. La prueba de humo también se conoce como "Prueba de verificación de compilación" o "Prueba de confianza".
En pocas palabras, las pruebas de humo consisten en verificar que las funciones importantes operen correctamente y que no haya fallos críticos en la versión que se está probando. Se trata de una prueba de regresión breve y rápida de las funcionalidades principales. Esto ayuda a determinar si la versión tiene algún defecto que haga que cualquier prueba adicional sea una pérdida de tiempo y recursos.
Compara Pruebas de humo versus pruebas de cordura
¿Por qué realizamos pruebas de humo?
Las pruebas de humo desempeñan un papel fundamental en el desarrollo de software, ya que garantizan la corrección del sistema en las etapas iniciales. De esta forma, podemos ahorrar tiempo y esfuerzo en las pruebas. Solo después de completar las pruebas de humo podemos comenzar con las pruebas funcionales.
- Todos los fallos críticos en el proceso de construcción se identificarán mediante pruebas de humo.
- Con la ayuda de las pruebas de humo, la mayoría de los defectos se identifican en las etapas iniciales de Desarrollo de software ad-hoc.
- Con las pruebas de humo, simplificamos la detección y corrección de defectos importantes.
- Mediante pruebas de humo, el equipo de control de calidad puede encontrar defectos en la funcionalidad de la aplicación que pueden haber surgido con el nuevo código.
- Las pruebas de humo encuentran los defectos de mayor gravedad.
Ejemplo 1: Ventana de registro: Puede pasar a la siguiente ventana con un nombre de usuario y contraseña válidos al hacer clic en el botón Enviar.
Ejemplo 2: El usuario no puede cerrar sesión en la página web.
¿Cuándo realizamos las pruebas de humo?
Estos beneficios solo se materializan si la verificación se activa en el momento adecuado. Las pruebas de humo se realizan cuando se desarrollan nuevas funcionalidades de software y se integran con una versión existente implementada en el entorno de control de calidad o de preproducción. Garantizan que todas las funcionalidades críticas funcionen correctamente. El siguiente diagrama muestra cómo una versión llega al entorno de control de calidad antes de que comiencen las pruebas de humo.
En este método de prueba, el equipo de desarrollo implementa la compilación en QA. Los evaluadores toman un subconjunto de casos de prueba y los ejecutan contra las funcionalidades críticas de la compilación. Esta serie de casos de prueba está diseñada para exponer errores que se encuentran en la compilación. Si estas pruebas se superan, el equipo de QA continúa con Prueba de funcion.
Cualquier falla indica la necesidad de devolver el sistema al equipo de desarrollo. Siempre que hay un cambio en la construcción, realizamos pruebas de humo para garantizar la estabilidad.
Ejemplo: -Se agrega un nuevo botón de registro en la ventana de inicio de sesión y la compilación se implementa con el nuevo código. Realizamos pruebas de humo en una construcción nueva.
Las pruebas de humo permiten validar la compilación para pruebas formales posteriores y están diseñadas para demostrar la estabilidad del sistema y su conformidad con los requisitos. El objetivo principal es detectar problemas importantes de forma temprana. Una compilación incluye todos los archivos de datos, bibliotecas, módulos reutilizables y componentes de ingeniería necesarios para implementar una o más funciones del producto.
¿Qué sucede si no realizamos la prueba de humo?
Si no realizamos pruebas de humo en las primeras etapas, pueden encontrarse defectos en etapas posteriores, lo que puede resultar costoso. Defecto Los problemas detectados en etapas posteriores pueden ser un obstáculo insalvable que afecte a la entrega de los productos finales.
¿Quién realizará las pruebas de humo?
Después de lanzar la compilación al entorno de control de calidad, los ingenieros/líderes de control de calidad realizan las pruebas de humo. Siempre que hay una nueva compilación, el equipo de control de calidad determina la funcionalidad principal de la aplicación para realizar pruebas de humo. El equipo de control de calidad busca obstáculos destacados en la aplicación que se está probando.
¿Cómo realizar una prueba de humo?
Las pruebas de humo generalmente se realizan manualmente, aunque existe la posibilidad de realizar lo mismo mediante la automatización. Puede variar de una organización a otra.
Prueba manual de humo
Las pruebas de humo se realizan para asegurar que la navegación por las rutas críticas se desarrolle según lo previsto y no afecte la funcionalidad. Se seleccionan casos de prueba de funcionalidad de alta prioridad y se prueban para detectar defectos críticos en el sistema. Si la prueba es exitosa, se continúa con las pruebas funcionales. Si falla, la compilación se rechaza y se devuelve al equipo de desarrollo para su corrección.
El equipo de control de calidad (QA) inicia nuevamente las pruebas de humo con una nueva versión de compilación. Estas pruebas se realizan en la nueva compilación y se integrarán con las compilaciones anteriores para garantizar la correcta ejecución del sistema. Antes de realizar las pruebas de humo, el equipo de QA debe verificar que las versiones de compilación sean correctas.
Pruebas de humo mediante automatización
Pruebas de automatización se utiliza para Pruebas de regresiónSin embargo, también podemos usar un conjunto de casos de prueba automatizados para ejecutar pruebas de humo. Con la ayuda de las pruebas automatizadas, los desarrolladores pueden verificar la compilación de inmediato, siempre que haya una nueva compilación lista para su implementación.
En lugar de repetir las pruebas manualmente cada vez que se implementa la nueva compilación de software, se ejecutan casos de prueba de humo registrados contra la compilación. Verifica si las funciones principales aún funcionan correctamente. Si la prueba falla, pueden corregir la compilación y volver a implementarla inmediatamente. De esta manera, podemos ahorrar tiempo y garantizar una construcción de calidad en el entorno de control de calidad.
Utilizando una herramienta automatizada, el ingeniero de pruebas registra todos los pasos manuales que se realizan en la compilación del software.
Ciclo de prueba de humo
El siguiente diagrama de flujo muestra cómo se ejecuta la prueba de humo. Una vez que la compilación se implementa en QA y las pruebas de humo se superan, procedemos con las pruebas funcionales. Si la prueba de humo falla, finalizamos las pruebas hasta que se solucione el problema en la compilación.
Mejores prácticas para el diseño de casos de pruebas de humo
Conocer el ciclo es una cosa; mantenerping El conjunto de pruebas que lo hace confiable es otro factor. Un conjunto de pruebas de humo solo se gana su lugar cuando se mantiene compacto, rápido y reproducible.
- Primero, identifique las rutas críticas: Enumera los flujos de trabajo que hacen que el producto sea comercialmente utilizable, como el inicio de sesión, la búsqueda, la entrada de datos, el pago y el cierre de sesión. Si alguno falla, la versión no tiene valor para un evaluador.
- Mantén la suite poco profunda pero ancha: Revisa cada módulo principal una sola vez en lugar de explorar cada módulo en profundidad. Los valores límite, los datos negativos y la redacción de los mensajes de error pertenecen a las pruebas funcionales, no a este ámbito.
- Limitar el tiempo de ejecución: La mayoría de los equipos mantienen la carrera entre diez y quince minutos y limitan el tiempo de descanso a aproximadamente veinte o treinta minutos. Casos de pruebaUn trayecto que dura una hora deja de ser una puerta de acceso y se convierte en un cuello de botella.
- Ejecuta los mismos casos en cada compilación: La coherencia permite atribuir un fallo al código en lugar de a un cambio en la selección de pruebas.
- Eliminar los casos inestables y con muchas dependencias: Un caso que pasa y falla sin ningún cambio de código destruye la confianza en la puerta. Servicios de terceros inestables simulados o ficticios donde el marco de automatización de pruebas permite.
- Registren un veredicto inequívoco: Cada caso necesita un único resultado esperado para que la compilación pueda aceptarse o rechazarse sin debate.
- Versiona el paquete con la compilación: Almacene los casos de prueba en el mismo repositorio que el código de la aplicación para que la puerta de enlace siempre coincida con la versión que se está probando.
RevRevisa el conjunto de herramientas en cada lanzamiento: elimina los casos de las funciones que ya no importan y agrega nuevos flujos de trabajo críticos.
Pruebas de humo en pipelines de CI/CD
Un conjunto de herramientas diseñado de esta manera es lo suficientemente económico como para ejecutarse en cada confirmación, que es lo que exige la entrega moderna. integración continua servidor como Jenkins Compila el código, lo implementa en un entorno de prueba y luego activa la suite de pruebas de humo como primera etapa automatizada. Una ejecución exitosa (en verde) promueve el artefacto a las etapas funcional y de regresión, mientras que una ejecución fallida (en rojo) indica un fallo en el proceso y notifica al desarrollador responsable en cuestión de minutos.
Es común realizar dos tipos de pruebas. Una prueba previa a la fusión protege la rama principal validando cada solicitud de extracción, y una prueba posterior al despliegue confirma que el entorno desplegado es accesible y está configurado correctamente. Los equipos que practican el despliegue continuo suelen añadir una tercera prueba, más específica, en producción inmediatamente después del lanzamiento.
Dado que el proceso ejecuta el conjunto de pruebas varias veces al día, los casos deben ser no interactivos, autolimpiables e independientes. Cualquier caso que requiera una decisión humana o que deje datos de prueba pendientes detendrá el proceso.
Ventajas de las pruebas de humo
A continuación se enumeran algunas ventajas de las pruebas de humo.
- Fácil de realizar y funciona rápidamente.
- Los errores y defectos críticos son fáciles de detectar y corregir en las primeras etapas.
- Mejora la calidad del sistema.
- Reduce el riesgo
- El progreso es más fácil de evaluar.
- Ahorra tiempo y esfuerzo de prueba
- Minimiza los riesgos de integración
⚠ Limitación a tener en cuenta: Una prueba de humo superficial solo indica que la compilación es comprobable. Analiza las funcionalidades principales de forma superficial, por lo que los defectos menores, los casos límite y las características poco utilizadas permanecen ocultos hasta que se ejecutan las pruebas funcionales y de regresión. Nunca considere un resultado positivo en la prueba de humo como una señal de que la compilación está libre de defectos.
Pruebas de humo vs. Pruebas de cordura vs. Pruebas de regresión
Los tres se ejecutan tras un cambio de código, por lo que a menudo se confunden. Difieren en alcance, profundidad y en la pregunta que responde cada uno.
Las pruebas realizadas en un entorno de desarrollo sobre el código para garantizar la corrección de la aplicación antes de su lanzamiento al equipo de control de calidad se conocen como pruebas de cordura. Este proceso verifica que la aplicación en desarrollo cumpla con sus requisitos funcionales básicos.
Las pruebas de cordura determinan la finalización de la fase de desarrollo y toman la decisión de aprobar o no el producto de software para la fase de pruebas adicionales.
| BASE | PRUEBA DE HUMO | PRUEBA DE CORDURA | PRUEBAS DE REGRESIÓN |
|---|---|---|---|
| <b></b><b></b> | Amplio y poco profundo | Estrecho y profundo | Amplio y profundo |
| Pregunta respondida | ¿Esta versión es lo suficientemente estable como para realizar pruebas? | ¿Funciona esta solución en concreto? | ¿Se ha estropeado algo que antes funcionaba? |
| Secuencia | Primero, en cada compilación | Después de que la prueba de humo se haya superado | Después de las pruebas de cordura |
| Duración típica | 10 a 15 minutos | 30 a 60 minutos | Hours a días |
| Ajuste de automatización | Muy alto | Moderado, a menudo manual | Muy alto |
En la práctica, se ejecutan en secuencia: pruebas de humo para aceptar la compilación, pruebas de cordura para verificar el cambio entregado y pruebas de regresión cuando el cronograma lo permite.
Ejemplo de casos de prueba de humo
La tabla que aparece a continuación documenta una breve simulación de humo, con una fila por cada ruta crítica.
| T.ID | ESCENARIOS DE PRUEBA | DESCRIPCIÓN | PASO DE PRUEBA | RESULTADO ESPERADO | RESULTADO ACTUAL | ESTADO |
|---|---|---|---|---|---|---|
| 1 | Credenciales de inicio de sesión válidas | Pruebe la funcionalidad de inicio de sesión de la aplicación web para asegurarse de que un usuario registrado pueda iniciar sesión con nombre de usuario y contraseña. | 1.Inicie la aplicación 2.Navega por la página de inicio de sesión 3.Ingrese un nombre de usuario válido 4.Ingrese una contraseña válida 5.Haga clic en el botón de inicio de sesión |
El inicio de sesión debería ser exitoso | como se esperaba | Pasó |
| 2 | Agregar funcionalidad de elemento | Capaz de agregar artículo al carrito | 1.Seleccione la lista de categorías 2.Agregue el artículo al carrito |
El artículo debe agregarse al carrito. | El artículo no se agrega al carrito | No pasó |
| 3 | Funcionalidad de cierre de sesión | Verifique la funcionalidad de cierre de sesión | 1. seleccione el botón cerrar sesión | El usuario debería poder cerrar sesión. | El usuario no puede cerrar sesión | No pasó |
