El desarrollo de software rápido y eficiente hoy en día es impensable sin flujos de trabajo bien definidos: cada componente se transfiere al ensamblaje en el momento de la instalación, el producto no permanece inactivo. Hace dos años, junto con M.Video, comenzamos a introducir este enfoque en el proceso de desarrollo en el minorista y hoy continuamos desarrollándolo. ¿Cuáles son los subtotales? El resultado dio sus frutos: gracias a los cambios implementados, fue posible acelerar el lanzamiento de lanzamientos en un 20-30%. ¿Quieres algunos detalles? Bienvenido a nuestro backstage.

De Scrum a Kanban

En primer lugar, se implementó un cambio en la metodología: la transición de Scrum, es decir, el modelo de sprint, a Kanban. Anteriormente, el proceso de desarrollo se veía así:



Hay una rama de desarrollo, hay sprints para cinco equipos. Codifican en sus propias ramas de desarrollo, los sprints terminan el mismo día y todos los equipos combinan los resultados de su trabajo con la rama maestra el mismo día. Después de eso, las pruebas de regresión se ejecutan durante cinco días, luego la rama se entrega al entorno piloto y luego a la productiva. Pero, antes de comenzar las pruebas de regresión, tomó de 2 a 3 días estabilizar de alguna manera la rama maestra, eliminando conflictos después de fusionarse con las ramas de comando.

¿Cuál es la ventaja de Kanban? Los equipos no esperan el final del sprint, sino que combinan sus cambios locales con la rama maestra al finalizar la tarea, cada vez que verifican conflictos de colisión. El día señalado, todas las asociaciones con el maestro se bloquean y se inician las pruebas de regresión.



Como resultado, logramos deshacernos de los constantes cambios de términos a la derecha, regresiones
no se retrasa, el candidato de liberación se envía a tiempo.

Automatización ubicua

Por supuesto, solo cambiar la metodología no fue suficiente. El segundo paso, nosotros, junto con el minorista, las pruebas automatizadas. En total, se prueban unos 900 escenarios, divididos en grupos por prioridad.

Cerca de 100 escenarios son los llamados bloqueadores. Deberían trabajar en el sitio, la tienda en línea M.Video, incluso durante una guerra atómica. Si uno de los bloqueadores no funciona, entonces hay grandes problemas en el sitio. Por ejemplo, los bloqueadores incluyen un mecanismo para comprar bienes, aplicar descuentos, autorizar, registrar usuarios, realizar un pedido de crédito, etc.

Cerca de 300 escenarios más son críticos. Estos incluyen, por ejemplo, la capacidad de seleccionar productos usando filtros. Si esta característica se rompe, es poco probable que los usuarios compren productos, incluso si los mecanismos de compra y búsqueda directa en el catálogo funcionan.

Otros escenarios son mayores y menores. Si no funcionan, las personas obtendrán experiencia negativa al usar el sitio. Esto incluye muchos problemas de diversa importancia y visibilidad para el usuario. Por ejemplo, el diseño (mayor) desapareció, la descripción del stock (menor) no se muestra, la sugerencia automática de contraseñas en la cuenta personal (menor) no funciona, la recuperación (mayor) no funciona.

Junto con M.Video, automatizamos las pruebas de bloqueadores en un 95%, de los escenarios restantes, en aproximadamente un 50%. ¿Por qué aproximadamente la mitad no está automatizada? Hay muchas razones, y diferentes. Hay escenarios a priori no susceptibles de automatización. Existen casos complejos de integración, cuya preparación requiere trabajo manual, por ejemplo, llamar al banco y cancelar una solicitud de préstamo, contactar al departamento de ventas y cancelar pedidos en un entorno productivo.
La automatización de las pruebas de regresión redujo su duración. Pero fuimos más allá y automatizamos las pruebas de humo para los bloqueadores después de cada fusión de las ramas de comando con la rama maestra.

Después de automatizar las pruebas, finalmente nos deshicimos de los retrasos después de completar las asociaciones con la rama maestra.

Pepinillo al rescate

Para consolidar el éxito, nuestro equipo reelaboró ​​las pruebas ellos mismos. Anteriormente, estas eran tablas: acción → resultado esperado → resultado real. Por ejemplo, inicié sesión en el sitio con dicho nombre de usuario y contraseña; resultado esperado: todo está en orden; el resultado real también está bien, voy a otras páginas. Estos eran escenarios engorrosos.

Los tradujimos a la notación Gherkin y automatizamos algunos de los pasos. Tomemos la misma autorización en el sitio, el script ahora está formulado de la siguiente manera: " como usuario del sitio, inicié sesión con los datos de autorización y el procedimiento fue exitoso ". Además, el " usuario del sitio " y " conectado con los datos de autorización " se enumeran en tablas separadas. Ahora podemos ejecutar rápidamente casos de prueba independientemente de los datos.

¿Cuál es el valor de este paso? Digamos que un probador se dedica a probar un proyecto. No le importa cómo escribe los exámenes, puede hacer cheques incluso en forma de una lista de verificación: "se verifica la autorización, se verifica el registro, la compra se verifica con tarjeta, la compra por Yandex. El dinero se verifica - Soy guapo". Viene una nueva persona y pregunta: ¿inició sesión por correo electrónico o Facebook? Como resultado, la lista de verificación se convierte en un script.

Cinco equipos trabajan en el proyecto, y cada equipo tiene al menos dos evaluadores. Anteriormente, cada uno de ellos escribía pruebas a su gusto, y como resultado, las pruebas solo podían ser respaldadas por sus autores. Con la automatización, todo fue aburrido: o necesita contratar ingenieros de automatización independientes que traducen todo el zoológico de pruebas a un lenguaje de secuencias de comandos, u olvidarse de la automatización como un fenómeno. Gherkin ayudó a cambiar todo: con la ayuda de este lenguaje de secuencias de comandos creamos "cubos" (autorización, canasta, pago, etc.) de los cuales los evaluadores ahora recopilan varias secuencias de comandos. Cuando necesita crear un nuevo guión, una persona no lo escribe desde cero, sino que simplemente extrae los bloques necesarios en forma de pruebas automáticas. Las anotaciones de pepinillo han entrenado a todos los probadores funcionales, y ahora pueden interactuar independientemente con la automatización, los scripts de soporte y los resultados de análisis.

No nos detuvimos allí.

Bloques de funciones

Digamos que la versión 1 es la funcionalidad que ya está en el sitio. En la versión 2, queríamos hacer algunos cambios en los escenarios empresariales y de usuarios, y como resultado, parte de las pruebas dejaron de funcionar porque la funcionalidad cambió.

Estructuramos el sistema de almacenamiento de prueba: lo dividimos en bloques funcionales, por ejemplo, "cuenta personal", "compra", etc. Ahora, cuando se introduce un nuevo script de usuario, los bloques funcionales necesarios ya están marcados con marcas.

Gracias a esto, después de combinarse con la rama maestra, los desarrolladores pueden verificar el trabajo no solo de los bloqueadores, sino también de los scripts relacionados con el área temática que afectan los cambios realizados.

La segunda consecuencia es que se ha vuelto mucho más fácil mantener las pruebas por sí mismas. Por ejemplo, si algo ha cambiado en su cuenta personal, al realizar un pedido y una entrega, no necesitamos cambiar el modelo de regresión completo, porque los bloques funcionales que se cambian son visibles de inmediato. Es decir, mantener actualizado el conjunto de pruebas se ha vuelto más rápido y, por lo tanto, más barato.

El problema con las gradas

Nadie solía probar el rendimiento de los stands antes de las pruebas de aceptación. Por ejemplo, nos dan un banco de pruebas, ejecutamos pruebas de regresión durante varias horas. Caen, entienden, arreglan, ejecutan pruebas nuevamente. Es decir, perdemos tiempo en la depuración y las ejecuciones repetidas.

El problema se resolvió simplemente: escribieron un total de 15 pruebas API que verifican la configuración de los stands, que de ninguna manera están relacionadas con la funcionalidad. Las pruebas son independientes de la versión de compilación; solo verifican todos los puntos de integración críticos para pasar scripts.

Esto ha ayudado a ahorrar mucho tiempo. De hecho, antes de la automatización, teníamos 14 probadores, los controles eran engorrosos y largos, había guiones para casi todo el día de trabajo, que constaban de 150 pasos. Y aquí está probando, y en algún lugar del paso 30–40–110 se da cuenta de que el soporte no funciona. Multiplicamos el tiempo de trabajo perdido por 14 personas y estamos horrorizados. Y después de la introducción de la automatización y las pruebas de los stands, logramos reducir a la mitad el número de probadores y eliminar el tiempo de inactividad, lo que alegraba mucho al contador principal.

Cerezas en el pastel

La primera cereza es el flujo de errores. Formalmente, este es el ciclo de vida de cualquier error, pero de hecho de cualquier entidad. Por ejemplo, operamos este concepto en Jira. Un estado adicional nos permitió acelerar los lanzamientos.

En general, el proceso se ve así: encontraron un incidente, lo llevaron a trabajar, lo completaron, lo entregaron a prueba, lo probaron y lo cerraron.



Entendemos que el defecto se ha cerrado, el problema se ha resuelto. Y agregaron otro estado: "para pruebas de regresión". Esto significa que después del análisis, los escenarios que detectan errores críticos se agregan al conjunto de regresión de 900 escenarios. Si no estaban allí, o si no tenían suficientes detalles, entonces tenemos comentarios instantáneos sobre el estado del productivo o piloto.



Es decir, entendemos que hay un problema, y ​​por alguna razón no lo tomamos en cuenta. Y ahora agregar un script de verificación de errores ahorra mucho tiempo.

También presentamos una retrospectiva a nivel de prueba. Se ve así: compilaron una tableta "número de versión, la cantidad de errores en ella, la cantidad de bloqueadores y otros scripts, y la cantidad de resoluciones". Al mismo tiempo, estimamos el número de resoluciones inválidas. Por ejemplo, si obtiene 15 errores no válidos de 40 errores, entonces este es un indicador muy malo, los evaluadores están perdiendo no solo su tiempo, sino también el tiempo de los desarrolladores que trabajan en estos errores. Los muchachos comenzaron a reflexionar, tratar con esto, introdujeron el procedimiento para revisar errores por probadores más experimentados antes de enviarlos al desarrollo. Y lo hicieron muy bien.

Por lo tanto, hay una constante reflexión y trabajo para mejorar la calidad. Se analizan todos los errores del producto: se crea una prueba para cada error, que se incluye inmediatamente en el conjunto de regresión. Si es posible, esta prueba está automatizada y se ejecuta de manera regular.

Resultados

Inicialmente, se planeó aumentar la frecuencia de los lanzamientos y reducir la cantidad de errores, pero el resultado superó las expectativas. Un proceso de automatización razonablemente construido hizo posible aumentar el número de pruebas automatizadas en poco tiempo, y el análisis de errores perdidos permitió al equipo de desarrollo y pruebas priorizar óptimamente los scripts y centrarse en los más importantes.

Resultados de automatización:

• hasta 4 días (en lugar de los 10 anteriores) redujeron la duración de las pruebas de regresión;
• equipo de prueba manual disminuyó en un 50%;
• de 30 a 35 días, el tiempo de comercialización se redujo, desde el momento en que una característica ingresó en la cartera de pedidos del equipo hasta que ingresó al piloto.

Equipo de automatización de pruebas, Jet Infosystems