La metodología ágil introduce sus propias reglas en el proceso de prueba de software, y cada equipo desarrolla, prueba e implementa sus servicios de forma independiente. Sin embargo, en sistemas complejos, cuando se requiere el trabajo coordinado de docenas de servicios para respaldar el proceso comercial, existe la necesidad de un nivel adicional de pruebas. Por lo tanto, en M.Video - Eldorado hemos creado un departamento especial para pruebas entre sistemas. Lea sobre cómo se formó, qué hacen los probadores de sistemas cruzados y cómo se organizan los procesos de prueba aquí.
En una publicación anterior ( tyk ), ya hablamos sobre por qué las pruebas entre sistemas son importantes para nuestra empresa. Hoy nos centraremos en cómo trabajan nuestros especialistas y hablaremos de la metodología de este proceso.
Cuatro proyectos piloto
Para formar un enfoque típico para las pruebas de sistemas cruzados, necesitábamos acumular información y rastrear las interacciones entre sistemas. No fue fácil abordar este tema, por lo que decidimos no estar a solas con ella y recurrimos al contratista.
Juntos describimos nuestro "dolor" y llegamos a la conclusión de que nuestra empresa debería tener probadores especializados que se dediquen a pruebas de sistemas cruzados, así como administradores de pruebas que supervisen dichos proyectos. Su trabajo se complementa con analistas de sistemas cruzados que, incluso en la etapa de diseño, monitorean la interacción entre sistemas y crean una base de conocimiento sobre las relaciones entre los diferentes componentes de los procesos comerciales.
Para establecer este trabajo, se decidió poner en marcha una serie de proyectos piloto. El primero fue un proyecto de prueba de promociones que nuestros colegas probaron de forma regular. Este piloto nos permitió comenzar a construir la base de conocimientos del departamento (se crearon 137 páginas de pautas en Confluence) y los empleados comenzaron a trabajar con instrucciones estándar, lo que significa que se volvieron más intercambiables.
El segundo proyecto piloto se organizó completamente sobre la base y el modelo a seguir de la nueva unidad. Probamos el proceso de generación de códigos de productos digitales. El proyecto denominado Contenido Digital 2.0 tuvo una duración de 5 meses. Afectó a 15 sistemas y se desarrollaron 114 casos de prueba para su implementación. Durante este piloto, llegamos a la necesidad de una gestión centralizada de los entornos de prueba y los datos maestros del proyecto, y creamos un equipo de especialistas para respaldar el trabajo de todos los equipos en el entorno de prueba.
El tercer proyecto piloto de MarketPlace se llevó a cabo de forma totalmente independiente, sin la participación de un contratista. Nuestro equipo probó 15 sistemas, cuyo trabajo conjunto nos permitió vender productos del mercado de productos en el sitio web M.Video. Se desarrollaron otros 209 casos de prueba, pero lo más importante es que creamos una plantilla común de alto nivel para el proceso de prueba entre sistemas que podría usarse en nuevos proyectos.
Durante MarketPlace, comenzamos a ejecutar casos de prueba en Jira, recopilando informes y estadísticas de una forma conveniente.
En el transcurso de este proyecto, en la primavera de 2020, el trabajo de todo el departamento se transfirió a un horario de trabajo remoto y se hizo evidente que se necesitaban materiales adicionales para capacitar a los probadores que trabajaban a distancia unos de otros, y comenzamos a Forme una base de videos de capacitación.
El cuarto piloto, después del cual nuestro trabajo pasó a una nueva calidad, está probando la aplicación móvil Eldorado. La prueba bajo el nombre Eldo Mobile se convirtió en una prueba de producto, es decir, su cliente no era el Projet Manager, sino el Product Owner. Y aunque probamos solo 16 sistemas relacionados durante la etapa piloto de tres meses, el nuevo enfoque hizo posible planificar pruebas entre sistemas para cada nueva versión de la aplicación móvil.
El trabajo de la división de pruebas de sistemas cruzados hoy
En la actualidad, la división de pruebas de sistemas cruzados actúa como un proveedor de servicios de control de calidad interno para los propietarios de productos y procesos. Recibimos solicitudes de diferentes departamentos, y los gerentes de pruebas elaboran un cronograma y distribuyen las tareas de prueba. La programación se lleva a cabo una vez a la semana: las tareas grandes y pequeñas se distribuyen entre los administradores de pruebas y los evaluadores, teniendo en cuenta su carga de trabajo y experiencia.
Si se está probando un proceso complejo, el evaluador puede trabajar en el mismo proyecto toda la semana. En otros casos, el especialista logra resolver dos o tres tareas de diferentes clientes. A veces, un evaluador trabaja con dos administradores de pruebas a la vez, quienes distribuyen su tiempo de acuerdo con un cronograma digital dinámico.
Una metodología prediseñada implica trabajar con casos de prueba típicos. Gracias a esto, una persona puede pasar fácilmente de una tarea a otra. En nuestro trabajo, esto a menudo es necesario, especialmente si algo comienza a "quemarse" repentinamente, y para otros proyectos, la fecha límite le permite cambiar ligeramente la fecha límite.
Para que nuestro departamento pueda interactuar con los testers de los equipos de producto, también desarrollamos normativas claras para la ejecución de los casos de prueba: criterios de inicio y finalización de las pruebas, tiempo y orden de las tareas, lista de responsables de cada etapa, etc.
De hecho, hoy estamos llevando la metodología de prueba de sistemas cruzados a equipos ágiles establecidos. Este enfoque nos permite evitar aprobaciones constantes y realizar pruebas dentro de un marco de tiempo claro.
Cualidades de un probador de sistemas cruzados
Incluso cuando todo el desarrollo está en el ritmo ágil, las pruebas entre sistemas permanecen inherentemente basadas en proyectos, con todas las necesidades consiguientes de planificación y reasignación de recursos, tanto en cada equipo como dentro de todo el grupo.
El punto es que el entorno de trabajo para los probadores de sistemas cruzados y los administradores de pruebas cambia constantemente. Por ejemplo, recientemente recibimos tareas para realizar pruebas entre sistemas de un chatbot, así como el proceso de firma de contratos para compras no comerciales. Para completar estas tareas, los evaluadores deben unirse a una nueva área, comprender la funcionalidad y las características de sistemas previamente desconocidos.
En tales proyectos, incluimos una fase de formación para probadores, que puede oscilar entre una semana y un mes. Al mismo tiempo, se requiere que las personas puedan involucrarse rápidamente en nuevos temas, comunicarse con analistas de diferentes equipos y administrar su tiempo de manera efectiva.
Sin embargo, incluso sin esto, existen muchas incertidumbres en el trabajo de la unidad. Los administradores de pruebas pueden comenzar el día con un plan y cambiarlo drásticamente a la hora del almuerzo. Todos los clientes tienen diferentes fechas límite y diferentes prioridades para las tareas, cualquier sistema puede desconectarse repentinamente y requerir una reasignación de recursos.
Finalmente, el entorno de prueba puede verse abrumado. Por lo tanto, los propios directores de pruebas deben ser PM fuertes y pueden manejar la planificación literalmente sobre la marcha.
Pruebas de producto
Después de la finalización de nuestros proyectos piloto, la empresa ha trazado un curso claro para las pruebas de productos. Debo decir que este enfoque facilita las pruebas multifuncionales, porque algunas de las tareas de prueba permanecen en el equipo de producto.
Determinamos de antemano en qué momento y por qué el equipo de pruebas multifuncionales se conecta al proceso y asigna claramente los recursos de los probadores.
En este sentido, las pruebas de productos son más fáciles de planificar porque se realizan según lo programado, de acuerdo con las oleadas de desarrollo. Cuando recibimos una nueva versión, le preguntamos al equipo qué se debe verificar, ajustamos los casos de prueba y nos ponemos manos a la obra. Al mismo tiempo, se asignan ciertos probadores de sistemas cruzados a cada producto.
La ventaja del enfoque centralizado es que un evaluador puede trabajar con varios proyectos o productos a la vez. Por ejemplo, una aplicación móvil suele ocupar el 50% del tiempo de los especialistas asignados. Pueden gastar el 50% restante en probar otros sistemas, de acuerdo con las tareas de los administradores de pruebas.
Resultados de la nueva división
Todavía no hemos vivido en el paradigma de las pruebas entre sistemas durante tanto tiempo, pero ya está claro que el tiempo de las pruebas se ha acortado (a veces varias veces) y la calidad de las pruebas es mayor.
Un equipo de probadores de sistemas cruzados es más barato para la empresa que expandirse con un tester adicional para equipos de productos y, gracias a la presencia de un centro de acumulación de competencias, las pruebas de sistemas cruzados pasan cada vez más rápido con cada nueva tarea. Además, también desarrollamos una metodología para ingresar a “proyectos desconocidos” para que el lanzamiento de pruebas multifuncionales en nuevas direcciones fuera más rápido.
La nueva metodología ha añadido transparencia al trabajo de todos los equipos y ha mejorado el control de calidad. La acumulación continua de experiencia y análisis de sistemas cruzados hace posible predecir con mayor precisión qué cambios en algunos sistemas pueden afectar el funcionamiento de otros sistemas.
La base de conocimientos está creciendo, y hoy ya podemos abordar casos de prueba que hace unos meses no hubiéramos podido realizar sin una preparación adicional. Por lo tanto, la práctica de pruebas entre sistemas se está convirtiendo gradualmente en una parte natural del ecosistema de desarrollo de M. Video-Eldorado y de la cultura corporativa de la empresa en su conjunto.
PD: Nuestro equipo se está expandiendo. Necesitamos probadores talentosos . Si es así, ¡bienvenido a bordo!