Get best of the week

Cómo mejorar el rendimiento de los equipos ágiles mediante pruebas

El desarrollo ágil tiene como objetivo ofrecer nuevas funciones de forma rápida y con la frecuencia adecuada, asegurando un flujo constante de cambios. Un enfoque flexible permite al equipo mantener un ritmo elevado, pero debido a esto, la calidad del código y la estabilidad del producto a menudo sufren. ¿Cómo resolver este problema sin llevar al equipo a un marco ajustado y sin privarlo de las ventajas de los métodos ágiles? La ayuda viene de probadores. Mi nombre es Denis Dubovoi, encabezo el departamento de pruebas en la Dirección de Big Data de X5 Retail Group, y en este artículo le diré cómo la apariencia de los probadores ayudó a mejorar la calidad del trabajo de nuestros desarrolladores.



Hacer reglas a través de pruebas


Los equipos ágiles a menudo descuidan la calidad. Esto se debe en parte al hecho de que las metodologías de prueba tradicionales no encajan en un contexto "flexible", en parte debido a la prioridad de la velocidad sobre la calidad. La tarea principal del equipo ágil es implementar rápidamente las funciones que necesita un cliente comercial. Esto es especialmente cierto en la etapa de formación de un producto, cuando su funcionalidad se determina literalmente por prueba y error, y los desarrolladores necesitan reconstruir rápidamente el producto para las solicitudes actuales. En tal situación, el equipo a menudo decide de esta manera: llamaremos al probador más tarde, cuando hagamos el MVP / primera versión de trabajo / aprendamos Zen, porque simplemente no entiende cómo organizar pruebas flexibles. El resultado a menudo es una interrupción en los tiempos de entrega, errores en la demostración y, lo peor de todo, en el entorno PROM.

En nuestro caso, la situación fue muy similar: el Departamento de Desarrollo de Productos de Big Data del Grupo Minorista X5 ha existido durante 2 años, y al principio la calidad de los productos fue mantenida solo por los propios desarrolladores: no había un rol especializado de control de calidad, y el departamento de pruebas y el primer probador del producto aparecieron Hace solo un año, cuando los productos ya habían comenzado.

Hoy, ya hay 15 personas en el departamento de pruebas: 11 probadores acompañan a los productos en equipos, dos personas desarrollan la dirección de las pruebas de carga y dos más: la dirección de la automatización de pruebas. En muchos equipos de productos, los evaluadores se han convertido en un catalizador de cambios importantes: su llegada agilizó el proceso de desarrollo y mejoró la estabilidad de la versión. Para hacer esto, conectamos los probadores a equipos que ya trabajan de acuerdo con el siguiente esquema:

1. Sumérgete en el proceso


En la primera etapa, necesitamos entender cómo está trabajando el equipo ahora, cómo se distribuyen los roles en él y cómo se intercambia la información. El probador comienza a ayudar con las pruebas, más en forma de "control de calidad", evaluando simultáneamente la madurez del equipo y los procesos en el equipo; para esto hay un pequeño "mapa de calor" de madurez, un ejemplo del cual se puede ver a continuación. En él puede ver cómo se desarrollan varias direcciones (desarrollo, prueba, DG, DevOps, soporte) en cada uno de nuestros productos.


Mapa de calor de madurez

Los evaluadores recopilan la evaluación de la madurez del proceso junto con los desarrolladores, evaluando el conjunto de prácticas tecnológicas y metodológicas utilizadas por el equipo. Como resultado, podemos ver en el mapa de calor qué y en qué área es posible mejorar, por ejemplo, desarrollar la práctica de pruebas unitarias en desarrollo o automatizar las verificaciones API en las pruebas, para cada etapa de la vida de un producto (prototipo, piloto, industrial), se recomienda su propio conjunto de prácticas.

2. Hacemos recomendaciones para mejorar




Después de descubrir cómo vive el equipo, puede pensar en las primeras recomendaciones para mejorar su trabajo. Aquí nos adherimos a la siguiente lógica: los probadores no son una función dedicada responsable de un área específica, somos parte del equipo y podemos influir en todo el proceso. Para facilitar el lanzamiento de mejoras, comenzamos con las cosas básicas:

  • . , : , , , .. , , ! ;)
  • (, user stories) . , , , , . « » : , pdf ? , !
  • Definition of Ready ( ) Definition of Done ( ) .
  • Arreglamos las etapas de sprint y uno de los puntos críticos: el punto "congelación de código".

Examinamos las etapas antes de las pruebas y un poco en las pruebas en sí, pero también hay una parte técnica para mantener bancos de pruebas y trabajar con datos de prueba y una parte industrial con soporte de producto. Los probadores están involucrados de alguna manera en todas estas etapas: tratamos de reunir especialistas en forma de T que vean todo el proceso de producción, y no solo su función inmediata.

3. Presentamos nuestras mejoras a los líderes de equipo y partes interesadas, enfocándonos en qué problemas resolverán estas mejoras


El proceso será más fácil si solicita el apoyo del equipo. Es importante "vender" su idea, para mostrar qué beneficio traerá sus cambios propuestos. Por ejemplo, los criterios de aceptación que mencionamos anteriormente pueden parecer un trabajo adicional para el analista, pero cuando el equipo comprende qué ahorro de tiempo recibirá, y esto de horas a días, lo que puede tomar para refinar la tarea, la mejora es mucho más fácil.

En algunos casos, puede actuar a través del propietario del producto. Por ejemplo, el producto carece de monitoreo (por ejemplo, técnico, con registros y gráficos hermosos) y no hay tiempo para configurarlo, porque esta no es una tarea del producto. En este caso, puede ponerse en contacto con el producto y explicar exactamente qué beneficios recibirá del monitoreo (no se volverá más estable de inmediato, pero la velocidad de localización del problema aumentará), y pedirle que asigne recursos para esto.
Paralelamente a la estandarización del trabajo en equipos de productos, se están desarrollando enfoques de prueba que garantizan la calidad de los productos, por ejemplo, evaluando y preparando los volúmenes requeridos de datos de prueba, desarrollando un modelo de prueba, formando puntos para la automatización futura, etc.

Siempre existe la posibilidad de que el equipo no acepte los cambios propuestos, sin importar cuán razonables puedan parecerle. En cada caso, es necesario formular sus propios enfoques y buscar una forma individual de persuasión. Los productos son muy diferentes, y los enfoques que funcionan en un producto no funcionan en absoluto en otro.

Muchos equipos confían en que pueden organizar su trabajo ellos mismos, y a veces esto es cierto. Hubo casos en que nuestra participación se redujo a recomendar los principales puntos de verificación, y luego el equipo implementó perfectamente todo a nivel de código, y nos quedamos cerca, siempre listos para ayudar. Pero más a menudo sucede de manera diferente: nuestro empleado llega al equipo y los desarrolladores comienzan a "llorar" en broma por los defectos encontrados por el probador, regocijándose de que los defectos se encontraron antes de la demostración o lanzamiento industrial.

Qué cambió


Los cambios en los equipos de productos fueron diferentes y afectaron diferentes aspectos del proceso. En uno de los equipos, las pruebas al principio se convirtieron en un cuello de botella: tomó tiempo, y no todos entendieron lo que estaba sucediendo en esta etapa. Como experimento, conectamos a los desarrolladores para ejecutar pruebas, como resultado de lo cual pudieron experimentar el trabajo de los probadores e incluso ver el producto como un todo, no una función de informe separada, por ejemplo, sino todo el camino desde la autorización del usuario en el producto y la realización de operaciones comerciales hasta el final: la descarga reporte. Así que fortalecimos la participación de todo el equipo, hicimos que el proceso de prueba fuera transparente y mostramos la importancia de esta acción, y la práctica descrita anteriormente se volvió regular.

En otro producto, el ciclo de lanzamiento ha cambiado con nuestra ayuda. Inicialmente, se acordó que los resultados del sprint se pusieron a prueba el viernes por la tarde y el lunes el producto ya llegó al cliente. El final del viernes y solo el comienzo del lunes se mantuvo para probar y corregir errores críticos, y como resultado, la nueva versión a menudo salió "en bruto" o los desarrolladores tuvieron que corregir los errores con urgencia el fin de semana. Después de un par de turnos difíciles en la entrega, el equipo aún pospuso la entrega del sprint hasta el miércoles (no redujo la duración del sprint, sino que simplemente cambió el horario por dos días). Ahora el equipo tiene tiempo para verificar y corregir la entrega en un ambiente relajado.



La decisión final, si cambiar o no, queda con el equipo: es ella quien es responsable del producto y su producción, por lo que elige la opción más conveniente para ella. El objetivo de nuestro trabajo no es imponer nuestros enfoques a los programadores, sino brindar la máxima información sobre los posibles riesgos y ofrecer mejoras y acciones adecuadas para el producto.

Lo que nuestro departamento de pruebas logró hacer durante el año pasado:

  • Han aparecido pruebas funcionales regulares en 7 productos del Departamento de Big Data de X5 Retail Group, 2 de ellos han alcanzado versiones estables en PROM sin comentarios críticos. Prueba de carga regular organizada de 3 productos.
  • 15 – 1 15 :-) !

    – ( , Agile), , , , , – .

Los cambios son siempre complejos, pero son necesarios si buscamos nuestros productos. Y son los evaluadores los que pueden hacer una contribución significativa para garantizar la calidad de los productos.
En los siguientes artículos, mis colegas y yo hablaremos sobre cómo probamos productos específicos, sobre cómo elegir una estrategia de prueba, sobre herramientas (por ejemplo, la edición Allure Enterprise, una herramienta conveniente para administrar pruebas, informes e incluso administrar pruebas automáticas), y cómo implementar pruebas automáticas en pipeline y qué opciones de desarrollo vemos (Test Driven Development, si lo pensó, esta es solo una de las opciones posibles).

More articles:


All Articles