¿Qué son las pruebas ágiles? Proceso y ciclo de vida

¿Qué son las pruebas ágiles?

Pruebas ágiles es una práctica de prueba que sigue las reglas y principios del desarrollo ágil de software. A diferencia del método Waterfall, Agile Testing puede comenzar desde el inicio del proyecto con una integración continua entre el desarrollo y las pruebas. La metodología de Agile Testing no es secuencial (en el sentido de que se ejecuta sólo después de la fase de codificación) sino continua.

Principios de las pruebas ágiles

Estos son los principios esenciales de las pruebas ágiles:

En este modelo de prueba ágil, el software en funcionamiento es la principal medida del progreso.
El mejor resultado lo pueden lograr los equipos autoorganizados.
Ofrecer software valioso de forma temprana y continua es nuestra máxima prioridad.
Los desarrolladores de software deben actuar para reunirse diariamente durante todo el proyecto.
Potenciar la agilidad a través de la mejora técnica continua y el buen diseño.
Agile Testing garantiza que el producto final cumpla con las expectativas de la empresa al proporcionar comentarios continuos.
En el proceso de prueba ágil, necesitamos ejecutar el proceso de prueba durante la implementación, lo que reduce el tiempo de desarrollo.
El proceso de prueba en Agile debería funcionar a un ritmo de desarrollo constante
Proporcione reflexiones periódicas sobre cómo ser más eficaz.
Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados.
Cada vez que el equipo se reúne, revisa y ajusta su comportamiento para ser más eficaz.
La conversación cara a cara con el equipo de desarrollo es el método más eficaz y eficiente para transmitir información dentro del equipo.

Agile Testing incluye varios principios que nos ayudan a aumentar la productividad del Software.

Ciclo de vida de pruebas ágiles

El ciclo de vida del Testing ágil se completa en cinco fases diferentes, como podemos ver en la siguiente imagen:

Estos son los pasos de prueba del proceso ágil:

Fase 1: Evaluación de Impacto: En esta fase inicial, recopilamos aportaciones de las partes interesadas y los usuarios. Esta fase también se denomina fase de retroalimentación, ya que ayuda a los ingenieros de pruebas a establecer los objetivos para el siguiente ciclo de vida.

Fase 2: Planificación de pruebas ágiles: Es la segunda fase del ciclo de vida de las pruebas ágiles, donde todas las partes interesadas se reúnen para planificar el cronograma del proceso de pruebas y los resultados.

Fase 3: Preparación para el lanzamiento: En esta etapa, revisamos las características que se han desarrollado/implementado, si están listas para entrar en funcionamiento o no. En esta etapa también se decide cuál necesita volver a la fase de desarrollo anterior.

Fase 4: Scrums diarios: Esta etapa incluye todas las reuniones matutinas para ponerse al día con el estado de las pruebas y establecer el objetivo para todo el día.

Fase 5: Agilidad de prueba RevVer: La última fase del ciclo de vida Agile es la Agilidad. RevVista de la reunión. Implica reuniones semanales con las partes interesadas para evaluar y valorar periódicamente el progreso respecto de los objetivos.

Plan de prueba ágil

Plan de pruebas ágil incluye tipos de pruebas realizadas en esa iteración, como requisitos de datos de prueba, infraestructura, entornos de pruebay resultados de las pruebas. A diferencia del modelo en cascada, en un modelo ágil, se escribe y actualiza un plan de prueba para cada versión. Los planes de prueba típicos en ágil incluyen

Alcance de prueba
Nuevas funcionalidades que se están probando
Nivel o tipos de pruebas según la complejidad de las características
Pruebas de carga y rendimiento
Consideración de infraestructura
Plan de Mitigación o Riesgos
Recursos
Entregables e hitos

Estrategias de prueba ágiles

El ciclo de vida de las pruebas ágiles abarca cuatro etapas

0 iteración

Durante la primera etapa o iteración 0, se realizan tareas de configuración inicial. Incluye la identificación de personas para las pruebas, la instalación de herramientas de prueba, la programación de recursos (laboratorio de pruebas de usabilidad), etc. Los siguientes pasos están configurados para lograrse en la iteración 0

Establecer un caso de negocio para el proyecto.
Establecer las condiciones límite y el alcance del proyecto.
Describir los requisitos clave y los casos de uso que impulsarán las compensaciones del diseño.
Describir una o más arquitecturas candidatas
Identificando el riesgo
Estimación de costes y elaboración de un anteproyecto.

Iteraciones de construcción

La segunda fase de la metodología de prueba ágil son las iteraciones de construcción; la mayoría de las pruebas ocurren durante esta fase. Esta fase se observa como un conjunto de iteraciones para construir un incremento de la solución. Para hacer eso, dentro de cada iteración, el equipo implementa un híbrido de prácticas de XP, Scrum, modelado ágil y datos ágiles, etc.

En la iteración de construcción, el equipo ágil sigue la práctica de requisitos priorizados: con cada iteración, toman los requisitos más esenciales que quedan de la pila de elementos de trabajo y los implementan.

La iteración de la construcción se clasifica en dos, pruebas de confirmación y pruebas de investigación. Concentrados de pruebas confirmatorias en verificar que el sistema cumpla con la intención de las partes interesadas tal como se describió al equipo hasta la fecha, y que sea realizado por el equipo. Mientras que las pruebas de investigación detectan el problema que el equipo de confirmación ha omitido o ignorado. En las pruebas de investigación, el evaluador determina los problemas potenciales en forma de historias de defectos. Las pruebas de investigación se ocupan de problemas comunes como pruebas de integración, pruebas de carga/estrés y pruebas de seguridad.

Nuevamente, para las pruebas confirmatorias hay dos aspectos. prueba de desarrollador pruebas de aceptación ágiles. Ambos están automatizados para permitir pruebas de regresión continuas durante todo el ciclo de vida. Las pruebas confirmatorias son el equivalente ágil de las pruebas según la especificación.

Las pruebas de aceptación ágiles son una combinación de pruebas funcionales tradicionales y pruebas de aceptación tradicionales mientras el equipo de desarrollo y las partes interesadas lo hacen juntos. Mientras que las pruebas de desarrollador son una combinación de pruebas unitarias tradicionales y pruebas de integración de servicios tradicionales. Las pruebas de desarrollador verifican tanto el código de la aplicación como el esquema de la base de datos.

Lanzamiento del final del juego o fase de transición

El objetivo de "Lanzar, finalizar el juego" es implementar su sistema con éxito en producción. Las actividades incluidas en esta fase son la capacitación de usuarios finales, personas de soporte y personas operativas. Además, incluye marketing del lanzamiento del producto, copia de seguridad y restauración, finalización del sistema y documentación del usuario.

La etapa final de prueba de la metodología ágil incluye pruebas de aceptación y pruebas del sistema completo. Para finalizar la etapa de prueba final sin obstáculos, deberá probar el producto con más rigor mientras se encuentra en las iteraciones de construcción. Durante el final del juego, los evaluadores trabajarán en sus historias de defectos.

Producción

Después de la etapa de lanzamiento, el producto pasará a la etapa de producción.

Los cuadrantes de pruebas ágiles

Los cuadrantes de pruebas ágiles separan todo el proceso en cuatro cuadrantes y ayudan a comprender cómo se realizan las pruebas ágiles.

Cuadrante Ágil I

La calidad del código interno es el enfoque principal en este cuadrante y consta de casos de prueba impulsados por la tecnología y implementados para respaldar al equipo.

Pruebas unitarias
Pruebas de componentes

Cuadrante ágil II

Contiene casos de prueba impulsados por el negocio y que se implementan para respaldar al equipo. Este cuadrante se centra en los requisitos. El tipo de prueba que se realiza en esta fase es

Prueba de ejemplos de posibles escenarios y flujos de trabajo.
Pruebas de experiencia de usuario como prototipos.
Prueba de pareja

Cuadrante Ágil III

Este cuadrante proporciona retroalimentación a los cuadrantes uno y dos. Los casos de prueba se pueden utilizar como base para realizar pruebas de automatización. En este cuadrante se llevan a cabo muchas rondas de revisiones de iteraciones, lo que genera confianza en el producto. El tipo de prueba realizada en este cuadrante es

Las pruebas de usabilidad
Prueba exploratoria
Pruebas en pareja con clientes
Pruebas colaborativas
Pruebas de aceptación del usuario

Cuadrante Ágil IV

Este cuadrante se concentra en los requisitos no funcionales como rendimiento, seguridad, estabilidad, etc. Con la ayuda de este cuadrante, la aplicación se crea para entregar las cualidades no funcionales y el valor esperado.

Pruebas no funcionales como pruebas de estrés y de rendimiento.
Pruebas de seguridad con respecto a autenticación y hackear
Pruebas de infraestructura
Pruebas de migración de datos
Prueba de escalabilidad
Prueba de carga

Desafíos del control de calidad con el desarrollo ágil de software

Las posibilidades de error son mayores en Agile, ya que a la documentación se le da menos prioridad, lo que eventualmente ejerce más presión sobre el equipo de control de calidad.
Las nuevas funciones se introducen rápidamente, lo que reduce el tiempo disponible para que los equipos de prueba identifiquen si las funciones más recientes cumplen con los requisitos y si realmente abordan los trajes de negocios.
A menudo se requiere que los evaluadores desempeñen un papel de semi-desarrollador.
Los ciclos de ejecución de pruebas están muy comprimidos
Mucho menos tiempo para preparar el plan de prueba.
Para las pruebas de regresión, tendrán un tiempo mínimo.
Cambio en su rol de guardián de la calidad a socio de la calidad.
Los cambios y actualizaciones de requisitos son inherentes a un método ágil, convirtiéndose en el mayor desafío para el control de calidad.

Riesgo de automatización en procesos ágiles

La interfaz de usuario automatizada proporciona un alto nivel de confianza, pero su ejecución es lenta, su mantenimiento es frágil y su construcción es costosa. Es posible que la automatización no mejore significativamente la productividad de las pruebas a menos que los evaluadores sepan cómo realizar las pruebas.
Las pruebas poco confiables son una preocupación importante en las pruebas automatizadas. Arreglar las pruebas fallidas y resolver los problemas relacionados con las pruebas frágiles debe ser una prioridad absoluta para evitar falsos positivos.
Si las pruebas automatizadas se inician manualmente en lugar de a través de CI (integración continua), existe el riesgo de que no se ejecuten regularmente y, por lo tanto, pueden provocar fallas en las pruebas.
Las pruebas automatizadas no reemplazan las pruebas manuales exploratorias. Para obtener la calidad esperada del producto, se requiere una combinación de tipos y niveles de pruebas.
Muchas herramientas de automatización disponibles comercialmente ofrecen funciones simples como la automatización de la captura y reproducción de casos de prueba manuales. Dichas herramientas fomentan la realización de pruebas a través de la interfaz de usuario y dan lugar a pruebas inherentemente frágiles y difíciles de mantener. Además, almacenar casos de prueba fuera del sistema de control de versiones crea una complejidad innecesaria.
Para ahorrar tiempo, muchas veces el plan de prueba de automatización está mal planificado o no está planificado, lo que resulta en que la prueba falle.
Los procedimientos de configuración y desmontaje de la prueba generalmente se omiten durante la automatización de la prueba, mientras que realizar pruebas manuales, procedimientos de configuración y desmontaje de la prueba suena perfecto.
Las métricas de productividad, como la cantidad de casos de prueba creados o ejecutados por día, pueden ser terriblemente engañosas y podrían llevar a realizar una gran inversión en la ejecución de pruebas inútiles.
Los miembros del equipo de automatización ágil deben ser consultores eficaces: accesibles, cooperativos e ingeniosos, o este sistema fallará rápidamente.
La automatización puede proponer y ofrecer soluciones de prueba que requieran demasiado mantenimiento continuo en relación con el valor proporcionado.
Las pruebas automatizadas pueden carecer de la experiencia necesaria para concebir y ofrecer soluciones eficaces
Las pruebas automatizadas pueden tener tanto éxito que se quedan sin problemas importantes que resolver y, por tanto, recurren a problemas sin importancia.

Conclusión

La metodología ágil en las pruebas de software implica realizar pruebas lo antes posible en el Ciclo de vida del desarrollo de programas. Exige una alta participación del cliente y código de prueba tan pronto como esté disponible. El código debe ser lo suficientemente estable como para llevarlo a pruebas del sistema. Se pueden realizar pruebas de regresión exhaustivas para asegurarse de que los errores se corrijan y prueben. Principalmente, ¡la comunicación entre los equipos hace que las pruebas de modelos ágiles sean un éxito!