Donde haya desarrolladores, debería haber probadores cerca. Y cuanto más complejo es el sistema, más importante es el papel de este último. Pero no todos los probadores realizan la misma función de la misma manera, y hoy queremos hablar sobre la aparición de una unidad especial en M. Video-Eldorado, que se ocupa de las pruebas entre sistemas. Lea acerca de por qué decidimos crear una casta separada de probadores, cómo ayudó a la empresa y cómo llegamos a esta decisión bajo el corte.
Si no verifica si el sistema funcionará después de que la actualización se haya implementado en producción, un pequeño error puede "poner" todo el servicio al cliente o, por ejemplo, los procesos administrativos. Para evitar que esto suceda, cualquier equipo ágil debe tener su propio tester, que verifica la ejecución de los escenarios básicos e informa de los errores a los desarrolladores. Si un servicio interactúa con otros componentes del sistema, los equipos a menudo realizan pruebas de integración, verificando la influencia de los componentes más cercanos del ecosistema de servicios entre sí.
Pero en nuestro tiempo, los procesos comerciales son a menudo mucho más complicados y para lograr el resultado deseado se requiere el trabajo de una docena de servicios. En este caso, es necesario probar la compatibilidad de los cambios no solo en dos o tres sistemas vecinos, sino en todo el flujo.
Por tanto, las pruebas de integración ya no garantizan un funcionamiento sin errores. Aquí hay un ejemplo: cuando los desarrolladores de una aplicación móvil lanzan una versión, entonces, como máximo, se verifica su compatibilidad con Bitrix (en el que se ejecuta el sitio web de Eldorado). Esto le permite evaluar el trabajo solo del servicio en sí, pero no brinda ninguna garantía de que se cumplirán los pedidos, se entregarán los bienes a los clientes y los precios de emisión corresponderán a los precios en la aplicación, etc.
De hecho, los procesos complejos son la norma moderna. Por ejemplo, en M.Video y Eldorado, los pedidos en línea requieren la participación de más de 20 sistemas. Desde el lado del cliente, todo parece simple: el comprador simplemente ingresa a la aplicación móvil o al sitio web de la tienda online, selecciona el producto, lo pone en la cesta y asigna la entrega a la próxima fecha que le convenga. El mensajero entrega la mercancía en el momento indicado por el comprador a la dirección indicada.
Pero para que todo esto sea posible por parte de los servicios de TI, existe una interacción de los sistemas de autorización, motor del sitio, módulo de cálculo de precios, pasarela de pago, sistema CRM, contabilidad, etc. Y para evaluar si algún cambio en uno de los componentes dará lugar a una “avería” del proceso de compra, es necesario comprobar la interacción de todos los sistemas.
- ?
Por un lado, cada equipo ya tiene su propio tester. Y, al parecer, puede participar en pruebas de un extremo a otro. Pero hemos visto por nuestra propia experiencia que este enfoque no es el más eficaz. Una prueba entre sistemas es, por definición, difícil; para llevarla a cabo, debe tomar un probador de cada sistema, instruirlo y ponerlo en funcionamiento.
Después de completar su etapa, el probador N debe informar al probador N + 1 que su etapa se ha completado. Por lo general, los chicos están ocupados con su propio negocio: pruebas funcionales y de integración, y el proceso de prueba entre sistemas es lento.
Un caso real: el probador fue a almorzar, pero cuando regresó, se olvidó de que tenía que completar su etapa, tiene mucho trabajo más. Hasta que se le recuerde, el proceso vale la pena.
Si encontramos un problema en algún momento, entonces surge inmediatamente la pregunta: "¿De qué lado está?" Por ejemplo, el probador N + 1 devuelve un error al especialista anterior. Y el probador N está indignado: “¿Qué tenemos que ver nuestro sistema y yo con eso?”. Hasta que los muchachos descubran de qué lado surgió el problema, que sinceramente no consideran "suyo", pueden pasar varios días. El resultado es el incumplimiento de los plazos y la necesidad de impulsar constantemente el proceso.
Finalmente, para realizar una prueba de este tipo, debe lanzar un proyecto, conectar un gerente de proyecto, reunir periódicamente a 20 personas en una sala (una para cada sistema) y averiguar de qué lado surge el problema al dar el siguiente paso. Esto requiere mucha mano de obra, es ineficiente y distrae a las personas del trabajo que, con razón, consideran su trabajo principal.
Decidimos que sería mejor crear un departamento de pruebas de sistemas cruzados, que ahora prueba todos los procesos comerciales antes del lanzamiento de todas las actualizaciones clave para la producción.
Experiencia propia - PROMO-acciones
Cuando decidimos hacer esto, una gran ventaja fue la presencia de experiencia interna en pruebas entre sistemas. En 2017, comenzamos a implementar una nueva práctica de prueba de extremo a extremo para respaldar las campañas publicitarias federales para la marca M.Video. La empresa realiza constantemente diversas promociones, por ejemplo, "Su precio", "Compre un televisor, recibirá un regalo", etc.
Tales promociones implican precios especiales, la presencia de obsequios en el kit y la emisión de obsequios. Las promociones se realizan simultáneamente, se combinan o se excluyen en una compra específica.
Pero, en el proceso de recogida, por ejemplo, la compra de productos promocionales se llevó a cabo en un sistema, el trabajo del empleado del centro de llamadas, en otro, y la recepción de los productos, en el tercero. Como resultado, el televisor podría quedarse sin un regalo, o cuando se agregó otro artículo al recibo, se canceló el precio promocional del puesto principal. Obviamente, cualquier actualización de los sistemas podría romper algo, y creamos un pequeño equipo que se dedicó específicamente a las pruebas de extremo a extremo de la promoción antes del lanzamiento de las promociones federales.
Aproximadamente un año después, este equipo desarrolló un proceso de trabajo eficiente y pasó a la operación sin errores y sin problemas de las promociones federales. Y como bono adicional, la empresa comenzó a recibir comentarios e informes sobre la viabilidad técnica y la efectividad de las campañas publicitarias lanzadas.
Cuando nos dimos cuenta de que la empresa necesita un proceso completo de pruebas entre sistemas en otros proyectos, esta experiencia resultó ser muy útil. La necesidad de un nuevo tipo de pruebas fue especialmente clara en el momento de la unificación de M.Video y Eldorado. Hemos aumentado la cantidad de cambios complejos y volumétricos, se hizo necesario realizar proyectos para dos marcas a la vez, la cantidad de productos y sistemas de back-office incluidos en un cambio superó los 20.
Beneficios del nuevo enfoque
En la actualidad, el departamento de pruebas de sistemas cruzados emplea a tres administradores de pruebas y seis evaluadores, y en el futuro planeamos emplear permanentemente a unas 40 personas en pruebas de sistemas cruzados para M. Video-Eldorado.
La tarea de nuestro departamento es realizar pruebas de extremo a extremo, detectando aquellos errores que pudieran no haber sido notados durante las pruebas funcionales y de integración, antes de la liberación en producción de los cambios lanzados en los procesos y productos de la empresa. La división evalúa el impacto de la actualización de cada uno de los componentes en los procesos internos y externos. Para ello, se desarrolló una metodología unificada para la preparación y ejecución de pruebas, así como reglas para interactuar con los testers internos de cada equipo de desarrollo.
A mediados de 2021, M.Video-Eldorado ya admite más de 100 productos y sistemas / servicios de back-office y, en consecuencia, más de 100 equipos están comprometidos con su desarrollo. Cada semana hay más y más componentes de software (después de todo, vivimos en la era de los microservicios) y los cambios son casi continuos. La empresa ejecuta constantemente de 5 a 6 proyectos a gran escala que afectan a docenas de sistemas a la vez.
En tales condiciones, el proceso de pruebas continuas entre sistemas se vuelve necesario, ya que le permite establecer una verificación oportuna de la interacción de los servicios y evitar que ingresen al producto actualizaciones incompatibles.
Si hablamos de indicadores específicos, logramos :
- , -, - end2end 2 ;
- 15%;
- 20%;
- end2end 10%;
- 50%;
- , -, Jira
La historia de cómo llevamos a cabo un proyecto piloto y sobre qué procesos de negocio desarrollamos la metodología de prueba merece un texto aparte. Por lo tanto, en la próxima publicación, hablaremos sobre nuestro camino hacia las pruebas omnipresentes de sistemas cruzados, así como también compartiremos la metodología y los criterios existentes para la implementación exitosa de las pruebas end2end en la empresa, que hemos desarrollado a partir de nuestra propia experiencia.
PD: Hay varias vacantes interesantes en nuestro equipo . ¡Bienvenidos!