Get best of the week

Cómo organizar las pruebas para acelerar y estabilizar los lanzamientos de productos. Parte 2

El probador tiene muchas oportunidades para mejorar la calidad del producto y hacer que el equipo trabaje más cómodamente. Lo principal es discutir cualquier cambio con el equipo e implementar solo lo que sea conveniente y útil para todos.

Mi nombre es Victoria Dezhkina, soy responsable de probar varios productos en la Dirección de Big Data de X5 Retail Group. En la última parte del artículo, comencé a hablar sobre cómo cambiamos los procesos en el equipo del producto "Sistema de automatización para la adquisición de una red minorista". Los lanzamientos de productos se retrasaron constantemente durante varios días y, a menudo, salieron en bruto. Cambiamos el cálculo del código y el orden de planificación de tareas, lo que nos permitió acortar el ciclo de lanzamiento en unos pocos días, pero aún teníamos que encontrar el formato óptimo para establecer y aceptar tareas, establecer puntos de prueba en el ciclo de lanzamiento y aprender a priorizar problemas para corregir defectos.



El formato de formulación y aceptación de tareas y defectos.


El método para establecer la tarea determina en gran medida la rapidez y la correcta ejecución de la misma. Puede describir tareas de diferentes maneras, por ejemplo, utilizando historias de usuarios que reflejen las necesidades del usuario final del sistema. Suena así: "el usuario quiere recibir un informe presionando el botón verde".

La desventaja de este enfoque es que no explica qué será "bajo el capó" de esta decisión. Las historias de los usuarios dejan a los desarrolladores demasiada libertad, y a veces se convierte en un problema: el equipo comienza a reinventar la rueda o sierras algo demasiado laborioso. Y dado que en condiciones de desarrollo rápido, casi nunca hay tiempo suficiente para la documentación completa, con este enfoque se obtiene un código críptico que complica enormemente la integración de nuevos desarrolladores en el producto.

Discutimos varias opciones de diseño para tareas y defectos y nos decidimos por un enfoque "híbrido": caso de uso + subtareas técnicas. El cliente comercial escribe el caso de uso, es decir, describe las opciones para usar la nueva funcionalidad, y el analista con el probador, en base a esto, es técnicamente subtareas para desarrolladores. En la descripción de la tarea en Jira, agregamos el caso de uso del que está hecho, o un caso de prueba que le permite reproducir el error, mientras que el nombre y la descripción de la tarea principal siguen siendo "legibles para los humanos".

Veamos, por ejemplo, qué hay dentro del defecto con el nombre "El usuario no comprende cómo se manejan los errores que ocurren al elegir una tasa de compra". La descripción de la tarea contiene:

  • un caso donde puede reproducir el error;
  • resultado real y esperado;
  • subtareas para el backend y la interfaz con instrucciones claras para que los desarrolladores las arreglen. "Backend: para esta API, proporcione la respuesta correspondiente a la interfaz" + una matriz de opciones que muestra qué respuestas deberían estar en cada una de las situaciones posibles. "Frontend: para esta API, dependiendo de la respuesta de la parte posterior, emita el texto de error correspondiente" + matriz de opciones.

Cuando el desarrollador finaliza su subtarea, simplemente la cierra. Si todas las subtareas están cerradas, el defecto se vuelve a probar. Si se detectan problemas adicionales, la subtarea correspondiente se crea nuevamente.

Se obtiene la regla correspondiente para la descripción del defecto:

  1. Cree una tarea con una descripción de un problema funcional, un caso para reproducir el error y un enlace al historial, durante la verificación de la cual se encontró un defecto.
  2. . : , , API , use case . , , API, , , , , , .

También nos negamos a formar AC (criterios de aceptación) en nuestro producto, ya que en la etapa de planificación discutimos no solo lo que estamos desarrollando y probando, sino también cómo.

¿Qué le dio? Este enfoque nos permitió en cualquier momento entender qué estaba mal con la funcionalidad por parte del usuario, en qué etapa del trabajo en el defecto y, dependiendo de la carga en la parte posterior y frontal, priorizar las subtareas al mismo defecto de diferentes maneras.

Como resultado, incluso antes del inicio del desarrollo, todo el equipo comprende qué parte de cada tarea lo afectará personalmente y, al final, cada tarea contiene información: cómo se desarrolló, cómo se probó, si había documentación en él y también qué se corrigió durante el proceso de desarrollo.

Este enfoque se usa solo en nuestro producto, porque resultó ser el más conveniente para nosotros. Otros productos de X5 Big Data Directorate utilizan sus propios esquemas: por ejemplo, Historias de usuarios con AC.

Parece que nuestra opción no contribuye en absoluto a acelerar el desarrollo, porque requiere más pasos para comenzar. Pero esto no es así.

Organizamos el proceso para que las pruebas se llevaran a cabo en paralelo con el desarrollo. Gracias a esto, el desarrollador no permanece inactivo mientras el probador trabaja y localiza la tarea tanto como sea posible.Además, siempre vemos qué desarrollador en particular trabajó en la tarea, cómo se implementó; esto nos permite comprender en el futuro cuáles de los desarrolladores enfrentarán más rápidamente nuevos problemas similares. La lógica es simple: cuanto menos haga un desarrollador cosas que no estén directamente relacionadas con la escritura de código, mejor y la localización más precisa de un defecto permite una reflexión más profunda sobre las posibles conexiones y problemas causados ​​por un error en particular.

También puede surgir la pregunta de si las reglas que hemos establecido en nuestro producto no interfieren con la formación de pruebas uniformes y estándares de desarrollo en el departamento. En realidad no: las reglas generales del departamento determinan qué debe contener la tarea en una determinada etapa de desarrollo, y cumplimos con estos requisitos, simplemente resolvemos la tarea en etapas anteriores.

Momentos de prueba


Discutimos durante mucho tiempo la cuestión de en qué etapa realizar las pruebas. Al principio, existía la idea de verificar cada tarea individual en la sucursal local, pero con este enfoque sería imposible verificar cómo funcionan juntas estas tareas, y sus conflictos se revelarían solo en la etapa del lanzamiento ensamblado, cuando es demasiado tarde para cambiar algo.

Por lo tanto, acordamos probar cada tarea por separado, pero en un banco de pruebas. Al principio queríamos implementar varias tareas a la vez, pero anteriormente ya te dije qué riesgos conlleva esta idea. Uno a la vez mucho más rápido. Este es un efecto conocido: la reducción del número de tareas paralelas no se ralentiza, sino que acelera el proceso. En Kanban, por ejemplo, existe un límite de WIP (WIP es un trabajo en progreso), que limita la cantidad de tareas que cada rol puede resolver simultáneamente.

Como resultado, establecimos cinco puntos donde los evaluadores participan activamente en el proceso de desarrollo:

  • En la etapa de documentación. Nos aseguramos de que no haya problemas que entren en conflicto con la lógica de lo que ya se ha hecho; arreglamos los detalles de la implementación de cada tarea.
  • En la etapa de establecer el problema. Hablamos con el analista de todos los casos posibles relacionados con la tarea y los tomamos en cuenta al formar la tarea.
  • En la etapa de planificación. Hablamos sobre cómo la implementación planificada puede engancharse en la funcionalidad relacionada y qué problemas puede traer. Coordinamos con el producto todos los defectos críticos y complementamos el sprint.
  • En preparación para el lanzamiento. Verificamos iterativamente cada tarea en un banco de pruebas, y el día antes del lanzamiento planeado reunimos todas las tareas juntas y verificamos en un banco.
  • Después del lanzamiento. Verificamos cómo funciona la versión en el producto.

Al principio, cuando teníamos lanzamientos cada 2 semanas, el esquema de trabajo se veía así: se



ha convertido (lanzamiento una vez por semana):



Reglas para la interacción del backend - prueba - conexión frontend


Cuando se envían muchos datos diferentes entre el backend y el frontend en la API, no siempre está claro por qué son necesarios y cómo interactúan. Debido a esto, pueden ocurrir fallos de funcionamiento en el extremo frontal. Por ejemplo, el número de cálculo, demanda cal, se transfiere desde atrás. Nominalmente, este es un parámetro, pero se deben "atraer" ocho campos más al respaldo para realizar el cálculo junto con él. Si no los pasa junto con el número de cálculo de costos, esta operación no se realizará en la parte frontal.

Para evitar tales situaciones, comenzamos a describir los parámetros pasados, indicándolos en los comentarios a la subtarea para desarrollar la API en Jira, que explicaba qué datos intercambiarían el frente y el frente. Intentamos describir todas las API en el marco de Swagger, pero con su ayuda al generar documentación automáticamente, no fue posible pasarle a la interfaz exactamente lo que hará el backend con los parámetros pasados. Por lo tanto, acordamos que si estamos hablando de un parámetro que no solo está escrito en la parte posterior, sino que usa otros parámetros, es necesario describir su propósito en la tarea.

También comenzamos a controlar la designación de variables para que en la misma API todos los campos estuvieran estandarizados. Nuestro producto consta de microservicios, y cada uno puede tener sus propios nombres de campo. En un campo con el nombre del proveedor puede ser proveedor, en otro: ID del proveedor, en el tercer nombre, etc. Al transferir estos datos a un componente del front-end, pueden comenzar las dificultades, por lo que revisamos todos los parámetros y comenzamos a estandarizar todos los nombres de variables. Para hacer esto, recopilamos una tabla resumen de todas las designaciones actuales, una tabla de todos los componentes frontales y las variables utilizadas por ellos (con lo que el desarrollador front-end ayudó mucho) y los comparamos. Ahora todas las API nuevas obtienen nombres de variables estándar, y las API antiguas se corrigen cuando surgen tareas para su finalización.

Reparación de defectos acelerados


En la etapa de establecimiento de la tarea, el cliente empresarial determina las prioridades: sabe mejor qué y en qué orden se necesita para el desarrollo del producto. Pero después de implementarse en dev, cuando hay tareas para corregir defectos, el probador confirma sus prioridades.

A veces es necesario cambiar urgentemente las prioridades de estas tareas; por ejemplo, encontramos un defecto menor en el back-end, sin el cual el equipo de front-end no puede comenzar a solucionarlo.

Anteriormente, en tales situaciones, fuimos inmediatamente a los desarrolladores y les pedimos que cambiaran la prioridad de las tareas, pero esto los distrajo. Por lo tanto, acordamos que nos contactaremos solo en ciertos momentos, después de la congelación del código, hasta 5 veces al día. ¿Qué le dio? Dejamos de reducir la productividad de los desarrolladores mediante llamadas repentinas, eliminamos el tiempo de inactividad y aumentamos el tiempo para que el analista trabaje en las tareas.

Además, debido al hecho de que las tareas ya no aparecen espontáneamente para los desarrolladores, siempre sabemos quién tiene qué tipo de carga, quién solía trabajar en una tarea y podrá manejarla más rápido. Como resultado, entendemos mucho mejor si lograremos preparar el lanzamiento a tiempo o no.

Estas medidas, junto con la lógica unificada de implementar el código en dev, release y prod, permitieronReduzca el período de corrección de defectos de 3 días a 3-4 horas.

resultados


Durante los 9 meses de trabajo de nuestro producto de automatización de compras, logramos acortar el ciclo de lanzamiento de 2.5 semanas a 1 semana con la posibilidad de un despliegue diario, aumentando significativamente la estabilidad de los lanzamientos.

Qué cambió:

  1. Eliminamos la necesidad de corregir defectos después del desarrollo, ya que llevamos este trabajo a la etapa de preparación de tareas al máximo.
  2. Redujo el período de corrección de defectos de 3 días a 3-4 horas.
  3. Tuvimos la oportunidad de lanzar lanzamientos "a pedido". Ahora podemos empacar cualquier día, desplegar las tareas y al anochecer todo estará listo y depurado.
  4. Aumentamos la transparencia de los procesos para todos los participantes en el proceso: ahora todos los desarrolladores y evaluadores del equipo entienden lo que está sucediendo en este momento, quién está ocupado con qué tareas, cuánto tiempo se necesita para desarrollar y corregir errores, etc.

BONIFICACIÓN: fue posible reducir el nivel de estrés en el equipo (espero), y gracias al trabajo coordinado del equipo (gracias a la entrega), pude ir fácilmente al control remoto :-) Implementando

estas mejoras, cumplimos con varias reglas:

  • Los probadores y los desarrolladores están en el mismo barco (¡repítelo como un mantra!), Por lo que lo primero que debe hacer un probador es llevarse bien con el equipo y descubrir qué es lo que más le preocupa, obtener su apoyo. Mis aliados y socios en el equipo fueron el gerente de distribución y los desarrolladores.
  • No existe una solución ideal preparada, y debe buscarse. El probador no impone sus reglas a nadie, se adapta al equipo y cambia sus enfoques con él, teniendo en cuenta la imagen de un futuro brillante e introduciendo suavemente medidas para lograrlo).
  • Las restricciones y la estandarización demasiado severas no son un método. Si se excede, los equipos pueden perder flexibilidad.

Las reglas de interacción, que nos ayudaron a acelerar el desarrollo de este producto, no pueden transferirse de forma pura a otros productos de la Dirección: están organizadas de manera diferente y las necesidades de los desarrolladores allí difieren. Pero el principio de crear estas reglas será el mismo: establecer el orden del cálculo del código, encontrar los puntos óptimos para las pruebas, documentar el código y la API.

Paralelamente al trabajo dentro de los productos, estamos desarrollando reglas que están diseñadas para facilitar la interacción entre los productos, y lo explicaremos en los siguientes materiales. Entonces, en la Dirección de Big Data, se está formando gradualmente una estrategia para desarrollar la calidad del producto.

More articles:


All Articles