Estrategia de pruebas automatizadas para proyectos ágiles

Estrategia de pruebas automatizadas para proyectos ágiles

En este artículo, voy a enumerar los puntos clave a considerar cuando empiece a planificar su estrategia de automatización de pruebas para su proyecto ágil para aprovechar al máximo su esfuerzo de automatización de pruebas.

Una pequeña introducción

Las pruebas automatizadas son una actividad central de cualquier metodología de desarrollo ágil. A medida que avanzamos hacia la implementación continúa, la automatización de pruebas se vuelve aún más importante debido a la rápida respuesta de retroalimentación que proporciona al equipo de desarrollo sobre el bienestar de la aplicación.

Para obtener esta retroalimentación rápida, las pruebas automatizadas deben ejecutarse continuamente, deben ser rápidas y los resultados de las pruebas deben ser consistentes y confiables. Para lograr estos objetivos, la mayoría de las verificaciones deben completarse como parte del desarrollo de nuevas características. En otras palabras, el desarrollo y las pruebas deben ser una actividad coherente y la calidad debe ser «incorporada» desde el principio, asegurando que lo que se está desarrollando funciona y que no rompe ninguna funcionalidad existente.

Esto requiere «invertir la pirámide de automatización de pruebas» presionando hacia abajo las pruebas de GUI que demoran mucho tiempo en ejecutarse, a niveles más bajos, por ejemplo, a la capa API que puede ejecutarse inmediatamente después de las pruebas unitarias como parte de la compilación para proporcionar el nivel inicial de confianza.

Visión general de la estrategia de automatización de pruebas

Prevención en lugar de detección: si bien, en primer lugar, debe dedicarse todo su esfuerzo a prevenir la introducción de defectos en la aplicación, las técnicas y los métodos para ello están fuera del alcance de esta publicación. Aquí, las metodologías se definen para permitir la detección rápida de errores cuando se introducen en el sistema y la retroalimentación al desarrollo.

La calidad debe favorecerse a la cantidad, en la mayoría de los casos es mejor lanzar una función que sea sólida como una roca en lugar de múltiples características que son inestables. Cuando se libera, como requisito mínimo es no tener ninguna característica recientemente desarrollada con  defectos de regresión .

Como ya se mencionó, una retroalimentación rápida sobre el bienestar de la aplicación es de gran importancia para respaldar la entrega continua. Por lo tanto, es necesario crear un proceso y un mecanismo mediante el cual podamos obtener retroalimentación rápidamente.

Una forma de obtener retroalimentación rápida es aumentando el número de pruebas unitarias, pruebas de integración y pruebas API . Estas pruebas de bajo nivel proporcionarán una red de seguridad para garantizar que el código funciona según lo previsto y ayuda a evitar que los defectos se escapen en otras capas de prueba. Las pruebas unitarias forman las bases para la automatización de pruebas en niveles superiores.

El segundo elemento de mejora es ejecutar pruebas de regresión con mayor frecuencia y alineadas con el proceso de integración continua, ver más adelante. Las pruebas de automatización no deben verse como una tarea aislada, sino más bien como una actividad coherente incorporada en el ciclo de vida del desarrollo del software.

Pruebas automatizadas de regresión

Las pruebas de regresión automatizadas son el corazón de la estrategia de automatización de prueba. Definiciones de diferentes paquetes de regresión:

Paquete de regresión de humo/smoke test, Es una comprobación de que la aplicación se puede cargar y acceder. Además, solo se deben ejecutar algunos escenarios clave para asegurarse de que la aplicación sigue siendo funcional.

El objetivo del paquete de pruebas de humo es detectar los problemas más obvios, como si la aplicación no se está cargando o no se puede ejecutar un flujo de usuario común; Por esta razón, las pruebas de humo no deben durar más de 5 minutos para dar una respuesta rápida en caso de que algo importante no esté funcionando. El paquete de pruebas de humo se ejecuta en cada implementación y puede ser una mezcla de API y / o GUI.

Paquete de regresión funcional, que están diseñados para verificar la funcionalidad de la aplicación con más detalle que la prueba de humo.

Deberán existir múltiples paquetes de regresión para diferentes propósitos. Si hay varios equipos trabajando en diferentes secciones de la aplicación, lo ideal es que haya diferentes paquetes de regresión que puedan enfocarse en el área en la que está trabajando el equipo.

Estos paquetes deben poder ejecutarse en cualquier entorno cuando sea necesario, siempre que el comportamiento de las características permanezca constante en todos los entornos. Se ejecutan varias veces al día y no deben durar más de 15 a 30 minutos.

Como estas pruebas funcionales son más detalladas, lleva más tiempo ejecutarlas. Por lo tanto, es importante tener la mayoría de las pruebas funcionales en una capa API donde las pruebas se pueden ejecutar más rápido para que podamos estar dentro del límite de tiempo de 15 a 30 minutos .

Paquete de regresión end 2 end, que prueba toda la aplicación como un todo. El objetivo de estas pruebas es garantizar que varias partes de la aplicación que se conectan a varias bases de datos y aplicaciones de terceros funcionen correctamente.

Las pruebas de extremo a extremo no están destinadas a probar todas las funcionalidades, ya que las que ya se probaron en los paquetes de regresión funcional, sin embargo, esas pruebas son “ligeras” que solo están verificando las transiciones de un estado a otro, y Un puñado de los escenarios o viajes más importantes del usuario.

Estas pruebas se ejecutan principalmente a través de la GUI (Interfaz grafica de usuario), ya que están verificando cómo los usuarios usarían el sistema. El tiempo necesario para ejecutarlos puede variar de una aplicación a otra, pero generalmente se ejecutan una vez al día o por la noche.

Pruebas unitarias automatizadas

  • La automatización de pruebas comienza en el nivel de pruebas unitarias. Las pruebas unitarias deben ser escritas por los desarrolladores para cualquier característica nueva que se desarrolle. Estas pruebas unitarias forman la base de una práctica de automatización más amplia que abarca todas las pruebas de la GUI (Interfaz grafica de usuario) del sistema. Es responsabilidad de los desarrolladores garantizar que para cada nueva característica que se desarrolle, se escriban un conjunto de pruebas unitarias coherentes y sólidas para demostrar que el código cumple con los requisitos y funciona según lo previsto.
  • Las pruebas unitarias proporcionan el mayor retorno de la inversión al equipo, ya que son muy rápidos de ejecutar, fáciles de mantener y modificar (ya que no hay dependencias) y cuando hay errores en el código, se devuelve rápidamente al desarrollador.
  • Las pruebas unitarias se ejecutan en la máquina del desarrollador, así como en el entorno de CI (Integración continúa).

Integración automatizada / API o pruebas de servicio

Mientras que en pruebas unitarias se basa en probar las funciones dentro de una clase, las Pruebas de integración forman el siguiente nivel desde las pruebas unitarias hasta las clases que conforman colectivamente el componente para entregar una pieza de funcionalidad. Estas pruebas se ejecutan solo cuando las pruebas unitarias se han ejecutado y aprobado.

Las pruebas de servicio se ejecutan naturalmente en una capa API sin la intervención de la interfaz web de la GUI; por lo tanto, las pruebas podrían verificar la funcionalidad en una forma pura y debido a que las pruebas hablan directamente de los componentes, son rápidas de ejecutar y serán parte de la compilación.

Cuando sea necesario, se utilizarán sumuladores como wiremock para determinar la dependencia de otros sistemas de terceros y cuando los sistemas posteriores no estén disponibles para proporcionar los datos necesarios para las pruebas de automatización.

Las Pruebas de Integración y/o las Pruebas de Servicio también se pueden ejecutar en la máquina del desarrollador y ser parte de la compilación, pero si comienzan a tomar mucho tiempo, entonces es mejor ejecutarlas en el entorno de CI (Integración continúa).

Herramientas como SoapUI se pueden usar para Pruebas de Servicio.

Pruebas de aplicación

Una aplicación de comercio electrónico típica se puede dividir en diferentes aplicaciones o “aplicaciones” que proporcionan diferentes funcionalidades. El concepto de Pruebas de Aplicación es que un grupo de pruebas que prueban la funcionalidad de una aplicación se organizan juntos y se ejecutan en la aplicación deseada. Este paquete será útil en los casos en que un equipo desee lanzar una aplicación individual y desee saber si está funcionando correctamente.

Las pruebas de aplicaciones generalmente requieren una interfaz para interactuar con los diferentes componentes, por lo que se anticipa que estas pruebas se ejecutarán a través de un navegador en la GUI.
El propósito de la prueba de la aplicación es asegurar que las características de la aplicación sean correctas funcionalmente. Debido a que la prueba se organiza de una manera que indica el estado de una aplicación en particular, estas pruebas normalmente se denominan Pruebas verticales, ya que ejecutan «abajo» una aplicación en particular. Las pruebas son muy completas y la cobertura es grande.

Selenium WebDriver podría usarse para ejecutar estas pruebas automatizadas contra el navegador. Esta herramienta es el controlador de prueba de software más popular para la automatización web que se implementa en su estrategia de automatización de prueba, que proporciona un SDK completo que permite verificaciones complejas.

Pruebas End to End

Las pruebas automatizadas de GUI que se ejecutan en el sistema, sirven como flujos de usuario, viajes o escenarios de extremo a extremo típicos. Debido a problemas con este tipo de pruebas (que se analizan a continuación), éstas se mantendrán al mínimo. Los escenarios de extremo a extremo se incluyen en el paquete de regresión nocturno.

Invirtiendo la pirámide de pruebas automatizadas

Como parte de la estrategia de automatización de pruebas, debemos minimizar la cantidad de pruebas automatizadas que se ejecutan en la capa GUI. Mientras que las pruebas automatizadas a través de la GUI proporcionan pruebas buenas y significativas en términos de simular la interacción de un usuario con la aplicación, es propenso a muchos problemas como los siguientes:

Pruebas frágiles: dado que las pruebas se basan en localizadores html para identificar elementos web con los que interactuar, tan pronto como el cambio de ID o el metodo de selección empleado, las pruebas fallan, por lo tanto, conllevan una gran cantidad de costos de mantenimiento.

Pruebas limitadas: la GUI podría limitar la capacidad del probador para verificar completamente una función, ya que la GUI puede no contener todos los detalles de la respuesta de la web para permitir la verificación.

Tiempo de carga de la página lento: debido a que las pruebas se ejecutan a través de la GUI, los tiempos de carga de la página pueden aumentar sustancialmente el tiempo de prueba general y, por lo tanto, la respuesta a los desarrolladores es relativamente lenta.

Menor retorno de la inversión: debido a los problemas mencionados anteriormente, las pruebas automatizadas de la GUI proporcionan el menor retorno de la inversión.

IMPORTANTE: Las pruebas automatizadas del navegador deben mantenerse al mínimo y se utilizarán para simular el comportamiento de un usuario incorporando flujos de usuarios comunes y escenarios de extremo a extremo en los que el sistema se ejerce como un todo.

-Aquí tienes tu estrategia de automatización de prueba para tus propios proyectos ágiles. Una vez que lo siga, podrá aumentar la eficiencia y la eficacia de sus proyectos.

Compartir artículo

1 Comments

  1. Pingback: Page Object Model y Page Factory - Tutorial Selenium

Leave Comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.