Mi nombre es Maria Snopok, soy la gerente de la dirección de automatización en el Departamento de Pruebas del Departamento de Desarrollo y Soporte de Productos Big Data de X5 Retail Group. En este artículo, compartiré nuestra experiencia con la implementación de pruebas automáticas y la reducción de los costos asociados. Esperamos que esta información sea útil para los equipos que tienen dificultades para realizar la transición a las pruebas automatizadas.
Cómo llegamos a los autotest
Antes de la llegada de la automatización, trabajé como gerente de pruebas en uno de nuestros productos. Cuando se formó un modelo de prueba bastante grande allí, comenzamos a distribuir el grupo de pruebas de regresión a todo el equipo de desarrollo; si ella es responsable del lanzamiento, también está probando. Dicha regresión en equipo resolvió las siguientes tareas:
- los desarrolladores que previamente se habían ocupado de sus distintas funcionalidades pudieron ver el producto completo;
- hicimos la regresión más rápido y lanzamos más a menudo debido a esto;
- ya no redujimos los recursos, la calidad mejoró.
Pero era caro, porque las pruebas las realizaban especialistas costosos, desarrolladores y analistas, y comenzamos a avanzar hacia la automatización.
Las pruebas de humo fueron las primeras en irse: verificaciones simples para asegurarse de que las páginas se abran, carguen, no se bloqueen y que todas las funciones básicas estén disponibles (hasta ahora sin verificar la lógica y los valores).
Luego, automatizamos los scripts positivos de extremo a extremo. Este paso trajo el máximo beneficio: las pruebas permitieron asegurarse de que los principales procesos comerciales del producto están funcionando, incluso si hubo errores en los escenarios negativos, alternativos y secundarios.
Y finalmente llegamos a la automatización de controles de regresión avanzados y escenarios alternativos.
En cada una de estas etapas, enfrentamos una serie de dificultades que ralentizaron y complicaron seriamente todo el proceso. ¿Qué soluciones prácticas nos han ayudado a acelerar y facilitar el trabajo de los automatizadores?
Cuatro formas de reducir los costos de las pruebas automáticas
1. Acordar los formatos de los atributos de prueba en la costa.
Los desarrolladores y los probadores automatizados deben acordar de antemano las reglas para nombrar elementos HTML para su uso posterior como localizadores en autotest. Es deseable tener el mismo formato para todos los productos. Hemos desarrollado requisitos para comprender cómo nombrar atributos, incluso antes de que la función se transfiera al desarrollo; este entendimiento existe tanto del lado de los desarrolladores como del lado de los probadores. Acordamos que a cada elemento html visible se le asigna un atributo data-qa personalizado, mediante el cual el evaluador lo buscará. El atributo se nombra de acuerdo con el siguiente patrón:
[nombre de pantalla] [formulario / tabla / nombre de widget] [nombre del elemento]
Ejemplo:
data-qa = "plu-list_filter-popover_search-input"
data-qa = "common_toolbar_prev-state"
Es fácil aislar este atributo simplemente de la documentación y el diseño, y todos saben cuál debería ser su significado. Cuando un desarrollador toma una tarea para trabajar, él, de acuerdo con estas reglas, asigna atributos data-qa a todos los elementos visibles de la página: encabezados, botones, enlaces, selectores, filas y columnas de tablas, etc. Como resultado, el evaluador puede comenzar a escribir autotests incluso durante el desarrollo de la función, basándose en solo para el diseño y la documentación, porque ya sabe cómo se nombrarán los atributos.
La introducción de atributos de prueba nos permitió reducir los costos de desarrollo y soporte de autotest en un promedio de 23% en comparación con el período anterior al reducir los costos de actualización de pruebas y localizar elementos para autotest.
2. Escribimos pruebas manuales para que sean fáciles de automatizar.
Los probadores manuales y los ingenieros de automatización viven en universos diferentes. Los manuales están destinados a verificar varios objetos de prueba cercanos diferentes con un script. Los automatizadores, por otro lado, tienden a estructurar todo y verificar solo objetos del mismo tipo dentro de una sola prueba. Por esta razón, las pruebas manuales no siempre son fáciles de automatizar. Cuando recibimos casos manuales para la automatización, enfrentamos una serie de problemas que no nos permitían automatizar los scripts resultantes palabra por palabra, porque estaban escritos para que una persona viva los ejecutara fácilmente.
Si un automatizador está profundamente inmerso en el producto, no necesita casos "manuales", puede escribir él mismo un guión para la automatización. Si llega al producto "desde afuera" (en nuestro Departamento, además de los probadores, los equipos también tienen pruebas como un servicio dedicado), y ya hay un modelo de prueba y scripts preparados por probadores manuales, es posible que tenga la tentación de indicarle que escriba autotests en la base de estos casos de prueba "manuales".
No ceda a esto: lo máximo para lo que un automatizador puede usar casos de prueba manuales es solo para comprender cómo funciona el sistema desde el punto de vista del usuario.
En consecuencia, es necesario preparar inicialmente pruebas manuales para que puedan automatizarse , y para que esto pueda hacer frente a problemas comunes.
Problema 1: simplificación de casos manuales.
Solución: detallando los casos.
Imaginemos una descripción de un caso manual:
- abre la página de lista de versiones de revisión
- haga clic en el botón crear
- completa el formulario
- haga clic en el botón "crear"
- asegúrese de que se crea la versión de revisión
Este es un mal escenario para la automatización, porque no especifica qué es exactamente lo que se debe abrir, con qué datos completar , qué exactamente esperamos ver y en qué campos mirarlo. Las instrucciones "asegúrese de que la versión se haya creado correctamente" no son suficientes para la automatización: la máquina necesita criterios específicos mediante los cuales pueda estar convencida del éxito de la acción.
Problema 2: ramificación de casos.
Solución: el caso solo debe tener un escenario lineal.
Las construcciones con "o" a menudo aparecen en estuches portátiles. Por ejemplo: "abrir revisión 184 bajo el usuario 1 o 2". Esto es inaceptable para la automatización, el usuario debe estar claramente indicado. Deben evitarse las conjunciones "o".
Problema 3: irrelevancia del caso.
Solución: verifique los casos antes de enviarlos a la automatización.
Este es el mayor problema para nosotros: si la funcionalidad cambia con frecuencia, los evaluadores no tienen tiempo para actualizar los casos de prueba. Pero si un evaluador manual se encuentra con un caso irrelevante, no le resultará difícil corregir rápidamente el guión. Un automatizador, especialmente si no está inmerso en el producto, no podrá hacer esto: simplemente no entenderá por qué la carcasa no funciona correctamente y lo percibirá como un error de prueba. Pasará mucho tiempo en el desarrollo, después de lo cual resulta que la funcionalidad probada se ha cortado durante mucho tiempo y el script es irrelevante. Por lo tanto, se debe verificar la relevancia de todos los scripts para la automatización.
Problema 4: no hay suficientes condiciones previas.
Decisión:pila completa de datos auxiliares para la ejecución del caso.
Los probadores manuales se vuelven borrosos y, como resultado, al describir las condiciones previas, pierden algunos matices que son obvios para ellos, pero no obvios para los automatizadores que no están tan familiarizados con el producto. Por ejemplo, escriben: "abre una página con contenido calculado". Saben que para calcular este contenido es necesario ejecutar un script de cálculo, y el automatizador, que ve el proyecto por primera vez, decidirá que es necesario tomar algo ya calculado.
Conclusión: en las condiciones previas es necesario escribir una lista exhaustiva de acciones que se deben realizar antes de iniciar la prueba.
Problema 5: múltiples comprobaciones en un escenario.
Decisión:no más de tres comprobaciones por escenario (excepto en escenarios costosos y difíciles de reproducir).
Los probadores manuales a menudo desean ahorrar dinero en casos, especialmente cuando son pesados, y probar tanto como sea posible en un escenario, metiendo una docena de pruebas en él. Esto no debe permitirse, porque tanto en las pruebas manuales como en las automatizadas, este enfoque genera el mismo problema: la primera prueba falló y todas las demás se consideran no pasadas o no arrancan en absoluto en el caso de la automatización. Por lo tanto, en los scripts de autotest, se permiten de 1 a 3 comprobaciones. Las excepciones son escenarios realmente difíciles que requieren cálculos previos que requieren mucho tiempo, así como escenarios que son difíciles de reproducir. Aquí puede comprometer la regla, aunque es mejor no hacerlo.
Problema 6: cheques duplicados.
Solución: no es necesario automatizar la misma funcionalidad una y otra vez.
Si tenemos la misma funcionalidad en varias páginas, por ejemplo, un filtro estándar, entonces no tiene sentido verificarlo en todas partes durante las pruebas de regresión, es suficiente buscar en un solo lugar (a menos que, por supuesto, estemos hablando de una nueva característica). Los evaluadores manuales escriben scripts y prueban este tipo de cosas en cada página, simplemente porque miran cada página de forma aislada, sin entrar en el funcionamiento interno de la misma. Pero los automatizadores deben entender que probar repetidamente lo mismo es una pérdida de tiempo y recursos, y es bastante fácil para ellos detectar tales situaciones.
La solución de los problemas anteriores nos permitió reducir el costo de desarrollo de autotest en un 16%.
3. Sincronización con los equipos de productos en el tema de refactorización, rediseño, cambios significativos en la funcionalidad, para no escribir pruebas "sobre la mesa".
En nuestro departamento de Big Data, donde se desarrollan 13 productos, existen dos grupos de automatizadores:
- automatizadores directamente en equipos de producto;
- un servicio de flujo de automatización fuera de los equipos de productos, comprometido en el desarrollo del marco y componentes comunes y trabajando en las solicitudes de productos con pruebas funcionales listas para usar.
Inicialmente, los automatizadores de transmisión no están tan profundamente interesados en el producto, y antes no asistían a las reuniones diarias del equipo, porque les llevaría demasiado tiempo. Una vez que este enfoque nos decepcionó: accidentalmente nos enteramos de fuentes de terceros que un equipo iba a refactorizar su producto (dividir el monolito en microservicios), por lo que algunas de las pruebas que escribimos se envían al archivo. Fue muy doloroso.
Para evitar que esto suceda en el futuro, se decidió que al menos una vez a la semana, un automatizador de la transmisión vendrá a las reuniones del equipo de desarrollo para estar al tanto de lo que está sucediendo con el producto.
También acordamos que las pruebas están automatizadas solo para la funcionalidad que está lista para producción y no experimenta cambios frecuentes (regresión). Debemos estar seguros de que al menos en los próximos tres meses, no le sucederá refactorización o reelaboración mayor, de lo contrario los automatizadores simplemente no tendrán tiempo con las pruebas.
Los ahorros de costes derivados de la implementación de estas medidas son más difíciles de calcular. Nos tomamos el tiempo para desarrollar autotests como base, que han perdido su valor debido a la transición planificada de parte de la funcionalidad a microservicios. Si supiéramos de esta transición de antemano, no cubriríamos la funcionalidad variable con autotests. La pérdida total (también conocida como ahorro potencial) es del 7%.
4. Actualización de un comprobador manual a ingeniero de automatización
Hay pocos automatizadores de prueba en el mercado laboral, especialmente los buenos, y los estamos buscando activamente. También actualizamos activamente los probadores manuales existentes que tienen un deseo y un conocimiento básico de la automatización. En primer lugar, enviamos a esas personas a cursos en el lenguaje de programación, porque necesitamos automatizadores completos y autotests completos, y de los grabadores, en nuestra opinión, hay más desventajas que ventajas.
Paralelamente al aprendizaje de un lenguaje de programación, una persona aprende a escribir scripts estructurados correctos sin problemas desde el punto 2, leer y analizar los resultados de los informes de autotest, corregir errores menores en localizadores, métodos simples, luego mantener pruebas listas para usar y solo entonces escribir las suyas propias. Todo el desarrollo se lleva a cabo con el apoyo de colegas experimentados del servicio de transmisión. En el futuro, pueden participar en la finalización del marco: tenemos nuestra propia biblioteca, escalable para todos los proyectos, se puede mejorar agregando algo propio.
Esta dirección de reducción de costos está en su infancia, por lo que es demasiado pronto para calcular los ahorros, pero existen muchas razones para creer que la capacitación del personal ayudará a reducir significativamente los costos operativos. Y al mismo tiempo, dará a nuestros probadores manuales la oportunidad de desarrollarse.
Salir
Ahora hemos automatizado alrededor del 30% de las pruebas en cinco productos, lo que ha llevado a una reducción del doble del tiempo de prueba de regresión.
Este es un buen resultado, ya que el tiempo es de gran importancia para nosotros: no podemos probar indefinidamente y no podemos regalar el producto sin verificación; la automatización, por otro lado, nos permite proporcionar el volumen requerido de controles de productos en el momento óptimo. En el futuro, planeamos aumentar el porcentaje de autotests al 80-90% para lanzar lanzamientos con la mayor frecuencia posible, pero al mismo tiempo no cubrir proyectos con autotests donde las pruebas manuales son aún más rentables.