Get best of the week

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

Si no se acuerda el trabajo en equipo, las colisiones ocurrirán constantemente entre los participantes del proceso individual y equipos completos, y los productos o microservicios de la compañía dentro del mismo producto interferirán entre sí utilizando recursos e infraestructura comunes. El resultado serán averías permanentes, conflictos y ralentizaciones. Los lanzamientos rápidos y predecibles en tales condiciones serán inalcanzables.

Mi nombre es Victoria Dezhkina, me dedico a realizar pruebas en el Departamento de desarrollo y mantenimiento de productos de big data X5 Retail Group. Le diré cómo cambiamos el proceso de prueba en uno de nuestros equipos de productos para acelerar la preparación de lanzamientos a casi la mitad y aliviar el estrés del equipo. Ahora estamos presentando este enfoque para las pruebas en otros productos de la compañía.



La Dirección de Big Data de X5 Retail Group está desarrollando actualmente 13 productos, 4 de ellos en el departamento de monetización, donde los productos están orientados al mercado extranjero, y cualquier error, ya sea un defecto en un producto o una característica lanzada tardíamente, tiene un efecto económico y conduce a la pérdida de clientes. . De hecho, estos son equipos internos que ganan en el mercado extranjero y cumplen con las reglas de las pequeñas empresas dentro de una gran empresa.

Todos nuestros productos varían significativamente en sus objetivos y, por lo tanto, requieren diferentes enfoques para el desarrollo y las pruebas, pero tienen mucho en común: usan la misma infraestructura (Kubernetes, Greenplum, servidores de prueba), y los desarrolladores de diferentes equipos de productos a veces se reemplazan por un tiempo. vacaciones

En tal situación, el papel de los acuerdos aumenta drásticamente: si una parte del equipo no sabe lo que está haciendo la otra, y cada equipo tiene sus propias reglas, inevitablemente surgirán problemas.

Por ejemplo, dos productos usan la misma infraestructura de prueba de carga, y ambos necesitan realizar pruebas con urgencia. Sin notificarse entre sí, lo hacen al mismo tiempo, como resultado, obtienen resultados falsos, porque el DBMS se ha "establecido" y por quién no está claro. Querían ahorrar tiempo en las negociaciones, como resultado, perdieron mucho tiempo sin ningún resultado.
La pérdida de datos no está excluida. Supongamos que uno de los productos ocupa un servidor de prueba gratuito sin avisar a nadie al respecto. Oficialmente, el hardware se considera gratuito, por lo que otro producto ingresa allí y borra accidentalmente todos los datos de prueba del primero. Esto, por supuesto, no son datos del usuario, sino solo una prueba, pero sigue siendo un caso bastante desagradable.

Puede que simplemente no haya suficientes trabajadores si el trabajo no se planifica por adelantado. Por ejemplo, ahora las pruebas de resistencia en nuestra Dirección funcionan en un formato de servicio, es decir, seleccionamos al especialista apropiado para los equipos que lo soliciten. Si varios equipos, sin previo aviso, solicitan pruebas de carga en un día, es posible que no haya suficientes evaluadores.

Parece que la salida más fácil en tal situación es establecer reglas uniformes para la interacción de todos los productos. Pero el problema es que todos los productos son diferentes. Algunos de ellos están destinados a usuarios internos, es decir, especialistas de otros departamentos de la empresa, por ejemplo, servicios de fijación de precios o estudio de la demanda. La otra parte está desarrollada para usuarios externos, por ejemplo, para proveedores. Estos productos tienen una lógica arquitectónica y criterios de calidad completamente diferentes.

Los productos en diferentes etapas de preparación tampoco aceptan el mismo enfoque: en la etapa inicial, cuando el producto está probando ideas, la prioridad es comprender la funcionalidad para el usuario y la ausencia de amenazas para la seguridad corporativa. Cuando un producto llega al soporte, otros requisitos son lo primero: la conveniencia del usuario, la estabilidad de la funcionalidad existente, la velocidad de respuesta a los defectos y el pleno cumplimiento de la política de seguridad corporativa.

Estos dos factores, el trabajo conjunto en el mismo territorio y las características únicas del producto, nos establecen la tarea: desarrollar reglas que permitan a los equipos no interferir entre sí, pero al mismo tiempo no obligarán a los probadores y desarrolladores de pies y manosy no reducirán el desarrollo de diferentes productos a una sola plantilla, pirateando todas las ventajas de un enfoque ágil y de producto de raíz.

Diré algunas palabras sobre por qué los evaluadores juegan un papel principal en la creación de estándares para la interacción en los equipos de productos. El hecho es que, debido a los detalles de nuestro trabajo, vemos todo el producto, mientras que los desarrolladores generalmente se centran en un área pequeña. Somos los primeros en notar problemas y ofrecerles soluciones, pero la solución final se resuelve junto con los desarrolladores.

Ya escribimos cómo está funcionando este trabajo colectivo : en la etapa inicial, tenemos que componer literalmente un solo diccionario para no confundirnos en términos. Pero esto es sólo el comienzo. Luego, tenemos que acordar una masa de matices muy diferentes.

Te diré cómo sucedió esto en el ejemplo de uno de nuestros productos: un sistema de automatización de compras para una red de distribución. Su tarea es garantizar el funcionamiento de todos los procesos desde el momento en que la tienda necesita ciertos productos hasta el momento en que los recibe.

¿Qué procesos han cambiado en nuestro producto?


Cuando llegamos al producto, los lanzamientos debían lanzarse cada 2 semanas, pero casi siempre llegaban tarde por unos días, y el día del lanzamiento siempre significaba que definitivamente nos quedaríamos en el trabajo y hasta el final estabilizaríamos la versión existente. Era necesario cambiar algo.

Es importante tener en cuenta que el cambio es una causa común. Cualquiera que sea su iniciador, el probador o los propios desarrolladores, no pueden hacerlo sin el consentimiento de todo el equipo y sus aliados fuertes. Todo cambio debe ser discutido por todo el equipo para recopilar tantas ideas como sea posible y no perderse los posibles riesgos. El gerente de entrega y producto de nuestro producto y antes que yo trabajé sistemáticamente para mejorar los procesos tanto desde el punto de vista técnico como del producto. Habiendo llegado al equipo, examiné el proceso desde el lado de las pruebas, y juntos pensamos en una "estrategia de cambios" acordada. El primer punto fue un cambio en el diseño del código.

Diseño de código


El procedimiento de cálculo es uno de los principales "dolores" del desarrollo del equipo, y aquí hay problemas muy diferentes. Por ejemplo, un equipo solo tiene una rama con un código, y la corrección de errores no se detiene allí. O bien, existen varias ramas, pero las tareas con funcionalidad superpuesta pueden aparecer en el entorno de prueba al mismo tiempo, como resultado, los evaluadores no podrán localizar el defecto o verificar algunas de las nuevas funciones bloqueadas por el defecto de una de las tareas. Y sobre los desarrolladores desesperados que no consideran algo malo arreglar rápidamente las pequeñas cosas en el producto sin advertir a los demás, generalmente no diré nada.

Para evitar todo esto, necesitábamos determinar la cantidad de ramas y entornos, así como acordar el procedimiento para poner a prueba el código.

La forma más fácil sería dividir el proceso en dos ramas con código "limpio" y "sucio". Pero tuvimos que cumplir muchas condiciones:

  • « », « »
  • ,
  • .

Pasamos 2 horas discutiendo un nuevo esquema de trabajo y llegamos a lo siguiente: comenzamos tres ramas, dos de ellas (lanzamiento y maestro) serán con código limpio. En el "maestro" se encuentra la versión actual del producto, en el "lanzamiento", características que están listas para su implementación. En Dev, la prueba se lleva a cabo, aquí hay tareas listas para la prueba, el desarrollo se lleva a cabo localmente. El lanzamiento a cada rama ocurre de acuerdo con el probador. Aquí está:



¿Qué nos dio esto en términos de pruebas?

  • El tiempo de prueba para cada tarea individualmente se redujo en un 20%. Ya no era necesario comenzar la prueba nuevamente, si una nueva tarea se desplegaba sin advertencia, las nuevas tareas no bloqueaban la verificación de las ya realizadas y el tiempo para la localización de defectos se aceleraba.
  • Para el día planeado de arreglar el lanzamiento, 1-2 tareas permanecieron sin marcar en lugar de 4 (es decir, el tiempo para verificarlas se redujo a la mitad).
  • El tiempo para las pruebas de integración y las pruebas de lanzamiento de candidatos se ha reducido de 6 horas a 2 (contando la nueva prueba).
  • La cantidad de defectos encontrados en la etapa de liberación ha disminuido. Anteriormente, en la primera versión de lanzamiento, encontramos más de 10, pero ahora no más de 4. El tiempo para volver a probar ha disminuido en 2 horas.
  • Hubo una oportunidad para continuar el desarrollo en paralelo con las pruebas.

El tiempo total que pasamos en las pruebas, retrasando el lanzamiento al producto, se redujo en 8 horas. Solo 2 horas de discusión sobre un nuevo esquema para trabajar con el equipo, y se las arregló para ahorrar un día de trabajo completo, que solía pasar cada dos semanas. ¿No está mal?

Pero los problemas persistieron.

  • , .
  • - , , .
  • .
  • , .

En pocas palabras: continuamos demorándonos en el trabajo el día del lanzamiento.

Nos reunimos de nuevo. Parte de los problemas se resolvió refinando el proceso de desarrollo y agregando CI:



configuramos la implementación automática en todos los entornos durante casi un mes, pero esto dio una aceleración en el tiempo de casi 2 días hábiles. El equipo se ha estado moviendo hacia esto durante mucho tiempo, el gerente de distribución y los desarrolladores mismos se involucraron en esto, pero hasta ahora no han logrado lograr dos cosas: para que la implementación en todos los entornos sea uniforme y al mismo tiempo se mantenga el control de la versión. La implementación automática viola el principio principal de las pruebas "en cualquier momento, el probador debe saber qué hay en cada entorno", o ralentiza a los desarrolladores que no pueden completar el desarrollo de la tarea sin permiso para implementar la prueba.

Este es un dilema difícil. Ignore el primer principio y, en lugar de acelerar, obtendrá una fuerte disminución en la previsibilidad de las versiones y las tareas desinfladas erróneamente. Por ejemplo, si un defecto ya se corrige junto con una "tarea limpia", entonces, cuando se despliega una tarea fija, ciertamente detectará la defectuosa. Por lo tanto, tendrá que esperar a que se corrija el defecto de la tarea relacionada, posponer la fecha de lanzamiento o volver a arreglar el defecto ya solucionado.

La implementación automática no es una persona, no estará de acuerdo con ella. Por lo tanto, resolvimos el problema con los errores restantes de una manera diferente: un enfoque especial para la planificación y luego agregamos otro soporte.

Planificación para el desarrollo y las pruebas.


Inicialmente, cuando planificamos, el equipo y yo discutimos si la tarea era clara para los desarrolladores, cuánto tiempo tomaría y si encajaríamos en el sprint. El probador estimó cuánto tiempo tomaría la prueba.

Al mismo tiempo, no discutimos en absoluto los errores que podrían ocurrir: no los previmos de antemano y no los incluimos en la lista de posibles tareas. Como resultado, cuando estos casos salieron durante el proceso de prueba, se agregaron como una tarea separada, necesitaban tiempo para trabajar y aumentaron el volumen de liberación, y a veces solo se encontraron en el candidato de liberación, en la etapa de prueba de tarea conjunta, posponiendo el despliegue indefinidamente. Nos reunimos para tres: un probador, entrega y producto, y pensamos en un nuevo esquema de interacción.

Ahora pronunciamos todos los posibles errores antes de comenzar el desarrollo. Me llevó a convertirme en un estudiante aburrido, que en la etapa de planificación pregunta todo y todo: "¿Qué sucederá si el servicio de terceros se cae?", "¿Y si nos volvemos nulos, pero no 0?", "¿Qué pasa si no obtenemos todos los datos? "," ¿Y si los Pechenegs atacan? " y así sucesivamente, pero ahora estábamos listos para todo.

También comenzamos a hablar sobre cómo implementaremos esta o aquella tarea y cómo la probaremos. Esto permitió reducir la iniciativa (la invención de todo tipo de bicicletas, por ejemplo) y dio a cada miembro del equipo una comprensión de lo que estaban haciendo sus colegas. Esto, por cierto, nos permitió abandonar los criterios de aceptación (AC).

Para evitar que la discusión en el nuevo formato se vuelva demasiado engorrosa, comenzamos a hacer esto no con 2 semanas de anticipación, sino durante una semana.

El nuevo diseño del código y la programación de tareas fueron solo los primeros pasos. En la siguiente parte del artículo, que se lanzará mañana, hablaré en detalle sobre cómo cambiamos toda una serie de procesos en el equipo:

  • El formato para establecer y aceptar tareas y defectos: dejaron las historias de usuario para el híbrido “caso de uso + tarea técnica” más conveniente para nosotros.
  • Momento de prueba: se establecieron 5 puntos en el ciclo de lanzamiento en el que los probadores controlan activamente el proceso de creación de productos.
  • Las reglas de interacción de la conexión “backend - testing - frontend”: desarrollamos un esquema que nos permitió verificar todos los datos que se transmiten entre el backend y el frontend.
  • Aceleración del trabajo para corregir defectos: reglas establecidas sobre cómo priorizar las tareas de depuración para no volver a distraer a los desarrolladores.

Estas medidas nos permitieron acortar el ciclo de lanzamiento de 2.5 semanas a 1. El aumento de la velocidad puede parecer pequeño, pero el principal logro fue que nuestros lanzamientos se volvieron más estables y predecibles: tuvimos la oportunidad de lanzar lanzamientos "bajo orden": podemos reunirnos cualquier día, despliegue tareas y al anochecer todo estará listo y depurado.

More articles:


All Articles