Get best of the week

¿Las auto-pruebas piensan en errores eléctricos?

Recientemente, la automatización de pruebas ha sido llamada la "bala de plata" de todos los problemas del proyecto. Muchas personas comienzan la automatización de manera muy espontánea y ligera, sin calcular todos los pros y los contras, pros y contras, mantenimiento y recuperación. 

En general, la automatización de pruebas es una herramienta muy costosa y específica. Por lo tanto, debe abordarse con el nivel adecuado de madurez del código y del proyecto en sí. De lo contrario, puede gastar millones de horas y dinero, y el efecto es microscópico o nada.

En este artículo probé:

  • para iluminar las "llagas de los niños" de la gestión de pruebas, buscando automatizar todo lo que no está fijado,
  • Explicar cómo la automatización de pruebas puede beneficiar el presupuesto del proyecto sin un análisis detallado de su alcance y preparación adecuada,
  • compilar una hoja de ruta para prepararse para la automatización del proyecto.

Fuente 

La tendencia es que ahora las pruebas de automatización tapan agujeros en todos los proyectos, en realidad clavan clavos con un microscopio. Llega al punto de que es difícil para un probador sin habilidades de automatización encontrar un trabajo, porque en la mayoría de las vacantes, faltan habilidades en el análisis de pruebas y el diseño de pruebas, pero se requiere experiencia en la automatización de algo.

Me gustaría creer que con el tiempo todos tendremos un deseo obsesivo de automatizar todo de una vez, pero por ahora una lista de verificación nos ayudaría mucho a determinar si se necesitan pruebas automáticas en el proyecto y si el proyecto está listo para ellas. 

En realidad, con estos pensamientos, fui a hacer una presentación sobre "Strike-2019" y luego escribí esta publicación basada en ella.

Hablaremos de grandes autotests de extremo a extremo que automatizan la regresión en términos de IU y servicios web. Y también lo que está conectado con ellos. No tocaremos el tema de las pruebas unitarias que los desarrolladores escriben o deberían escribir. Esta es una capa separada de autocomprobación, y ya se han escrito muchos artículos al respecto:

 
No nombraré el proyecto, solo diré que este es un sistema de información diseñado para varias decenas de millones de usuarios. Está integrado con varios portales estatales, así como con docenas, si no cientos, de portales regionales y comerciales. De ahí los mayores requisitos de fiabilidad, tolerancia a fallos y seguridad. Bueno, en general, para que todo "gire y no se caiga". 

Nuestro credo en todos los proyectos de prueba LANIT es la mejora continua. En general, todo lo que nos permite probar más rápido, mejor, más alto, más fuerte, ahorra tiempo y esfuerzo a los evaluadores y, como resultado, el presupuesto. Hemos implementado en este proyecto, probablemente todas las mejores prácticas que nos permitieron cumplir plazos y tareas. Como resultado, de los grandes chips no realizados, solo quedó la automatización de regresión. Este tema en sí durante bastante tiempo estuvo en el aire, y durante mucho tiempo lo rechazamos, descansando en todas nuestras extremidades, porque el beneficio no estaba muy claro. Pero al final decidieron automatizar. Y luego hubo un salto prolongado en agua fría.
 

Una pequeña digresión. Métodos de automatización


Hay dos formas principales de automatizar las pruebas de IU. 

Fuente

Automatización por probadores manuales


No tiene que ir muy lejos por ejemplos: todo está en Habré. No nombraré a la compañía. Aquellos que estaban interesados ​​en el tema probablemente vieron estos seminarios web de una hora y media, lo geniales que son, lo geniales que son, cómo todo el equipo de evaluadores de mano aprendió Java de ellos, fueron a automatizar, todo está cubierto, todo es genial, todo funciona, un futuro brillante ya ha llegado. Hay tal enfoque. 

Enfoque de diseño


Y hay un segundo enfoque: se recluta un equipo de autoevaluadores, con experiencia, con conocimientos y habilidades en OOP, y la automatización se realiza directamente por las fuerzas de este equipo, y un equipo de probadores manuales actúa como clientes y expertos. Sí, pueden fluir al equipo de automatización después del entrenamiento, la selección, pero nunca combinan dos roles al mismo tiempo.

A continuación describí las características de estos enfoques, pero no los marco específicamente como "más" o "menos": todos determinarán el signo por sí mismos.

Características de la automatización "por sí mismas"


Fuente

1) Cuando automatizamos con la ayuda de probadores manuales, obtenemos un efecto rápido "mira, esta prueba tomó un día antes, ahora puedo reemplazarla con un robot, lleva 2 días, pero no participo aquí". Naturalmente, esto mejora las calificaciones y amplía los horizontes de los especialistas: comienzan a entender el código. Pero no hay un resultado claro y tangible para el negocio. ¿Cuántas horas se dedicaron al desarrollo y cuánto se podría gastar si una persona con experiencia hiciera esto? ¿Cuántas horas se ahorran? ¿Con qué frecuencia se lanzará el caso de prueba? ¿Dónde? ¿A quién acompañar? ¿Cuanto cuesta? Esto no es muy bueno para mí porque, desafortunadamente, todavía no he visto clientes que estén dispuestos a pagar dinero sin cesar, por el proceso. Por lo tanto, un resultado claro y tangible siempre es importante para mí.

2) Sin plazos. Por un lado, es bueno: nadie anima al equipo, "automaticemos todo rápidamente, aprendamos rápidamente", la tensión no crece en una persona. Continúa probando con sus manos y se sumerge tranquilamente en la automatización. Por otro lado, no hay plazos, no podemos preguntar sobre los resultados y no entendemos cuándo estará listo.

3) No hay código de soporte y continuidad. Por un lado, diferentes enfoques, las encuestas dan lugar a mejores métodos de escritura, a veces, reescribiendo desde cero, puede acelerar la prueba automática varias veces. Pero es megatrack. Además, ¿quién acompañará todo esto si los especialistas abandonan el proyecto, y esto sucede si se van a otra área comercial u otro equipo? Tampoco muy claro.

Características del enfoque del proyecto.


Fuente

1) En este caso, ya estamos hablando del proyecto. ¿Y el proyecto es qué? Estos son recursos, tiempo, dinero. En consecuencia, el presupuesto se calcula aquí, teniendo en cuenta todos los matices que hay en este proyecto. Se calculan todos los riesgos, se calcula todo el trabajo adicional. Y solo después de acordar el presupuesto, se toma la decisión de lanzarlo.

2) En base a esto, es probable que la fase de preparación no sea rápida, ya que el cálculo del presupuesto para algo debe ser construido.

3) Naturalmente, se hacen mayores demandas a aquellos especialistas que participarán en el proyecto. 

4) Aquí también escribiré soluciones de infraestructura complejas, pero más sobre eso más adelante. 

5) Modernización de los procesos de prueba y lanzamiento existentes. Porque las pruebas automáticas son un nuevo elemento del equipo. Si no se proporcionó anteriormente, respectivamente, debe integrarlo en el proceso. Los probadores automáticos no deben colgar del lado derecho, izquierdo, del proyecto.

6) El enfoque del proyecto brinda regularidad, consistencia, aunque, por otro lado, su implementación puede ser más lenta que la implementación del primer enfoque.

7) Bueno, reportando. Muchos informes. Porque para cualquier presupuesto se te pedirá. En consecuencia, debe comprender cómo funcionan las pruebas automáticas (malo, bueno), qué tendencias, qué tendencias, qué debe aumentarse, qué debe mejorarse. Esto se controla mediante informes.

Largo camino hacia un futuro mejor


Descargo de responsabilidad: fuimos muy inteligentes de inmediato (en realidad no).

Fuente

Aquí hay una clasificación de los problemas que hemos encontrado. Analizaré cada uno individualmente. Haré esto a propósito, para que tengas en cuenta este "rastrillo". Debido a que estos problemas, que no se resuelven al comienzo del proyecto, afectarán directamente, al menos, su duración, al máximo: aumentarán su presupuesto o incluso podrán cerrar el proyecto.

Fuente

  • Diferentes equipos, diferentes enfoques.
  • Débil inmersión de la automatización en lo funcional.
  • Estructura no óptima de casos de prueba.
  • Documentación del marco.
  • Problemas de comunicación.
  • Compra oportuna de licencias.

Diferentes enfoques para la automatización.


Fuente 

Tortura número de veces


El primer intento que tuvimos fue de acuerdo con el primer modelo (ver método número 1). Un pequeño (pero orgulloso) grupo de investigadores de iniciativa decidió probar la automatización. En general, queríamos ver lo que salió de todo. Ahora, por supuesto, no haríamos esto, pero entonces no había experiencia y decidimos probarlo. 

Fuente

Teníamos un equipo líder con experiencia en automatización, 3 ardiendo con el deseo de automatizar el probador y muchas ganas de dominar este camino. Es cierto que Timlid era un recién llegado y no podía dedicar mucho tiempo al proyecto, pero el efecto positivo de su trabajo fue que escribimos nuestro propio marco. Observamos los marcos que estaban allí, eran caros y geniales o gratuitos, y se les adjuntó la instrucción "adjuntada al archivo al gusto después del ensamblaje". En general, por varias razones, no pudimos usarlos. En consecuencia, decidimos escribir nuestro propio marco. La elección en sí misma y el proceso de escritura es un tema para un artículo separado, o incluso ninguno.

No quiere decir que este intento fue un fracaso, simplemente sobrevivió y terminó. Cuando nos dimos cuenta de que necesitábamos un presupuesto, necesitábamos fuerzas adicionales, necesitábamos habilidades, necesitábamos otra organización de equipo. Automatizamos alrededor de 100 casos, vimos que funcionaba y redondeamos.

Intento número dos


Fuente 

Nada llama más que un sándwich mordido.

Después de un tiempo, volvimos nuevamente al tema de la automatización.

Pero, recordando el primer experimento, cambiamos al método No. 2. Aquí ya teníamos un equipo bastante "hábil", que automatizaba más de un proyecto. Pero aquí nos enfrentamos a otro desastre. Este equipo siguió el liderazgo del equipo de prueba de IU. ¿Cómo pasó esto?

"¡Queremos automatizar esto!"
- Quizás lo pensemos.
- No, no queremos pensar en nada, queremos estas pruebas automáticas.

Con esfuerzos titánicos, lo automatizaron e incluso funcionó. Pero con el tiempo, la estabilidad de los lanzamientos comenzó a disminuir, y cuando reunimos a nuestro propio equipo de ingenieros de automatización y comenzamos a entregarles el proyecto, resultó que la mitad de las pruebas se realizaron con muletas, la mitad verificó lo que la máquina pretendía y no lo que el probador manual quería. 

Y todo porque las pruebas automáticas se ejecutaron en código sin procesar, que estaba sujeto a correcciones diarias. Aquellos. El conjunto inicial de casos no era correcto. Tuvimos que sumergirnos en los temas que queremos automatizar, desde el punto de vista de su automatización (en adelante, mantequilla). Es muy crítico abordar los casos que regalamos para la automatización, y en algún momento descartar algunos de ellos, separar algunos de ellos, etc. Pero no lo hicimos. 

Cual es el resultado. Automatizamos otra pieza, unos 300 casos, después de lo cual el proyecto terminó, porque no hubo estabilidad en los lanzamientos y tampoco se entendió cómo acompañar esto. Y entendimos cómo no hacerlo ... por segunda vez.

Intento número tres


Fuente 

Para el tercer intento, nos acercamos, como una cierva tímida a un abrevadero. 

Alrededor vio riesgos (y desgloses de términos). Se acercaron críticamente, en primer lugar, a los casos de prueba y a sus autores (probadores de IU) como clientes de procesos. Encontramos el mismo equipo de ingenieros de automatización de pensamiento crítico y comenzamos un proyecto normalmente calculado (como pensábamos), totalmente preparado (ja, ja).

El rastrillo ya estaba mintiendo y esperándonos.

Débil inmersión de la automatización en lo funcional


Fuente 

En la primera etapa (en lo sucesivo, el tercer intento), cuando las comunicaciones todavía estaban mal establecidas, los probadores automáticos trabajaron detrás de una pantalla determinada: recibieron tareas, automatizaron algo allí. Corrimos autotest. Vimos estadísticas de que todo está mal con nosotros. Excavando registros de autotest. Y allí, por ejemplo, una caída en un error ortográfico en el nombre del archivo que se está cargando. Está claro que el probador, que probó esta funcionalidad con sus manos, comenzará un salto menor y saltará para verificar más. La prueba automática cae y golpea toda la cadena, que se basa en su base. 

Y cuando comenzamos a sumergir a los probadores automáticos en lo funcional, a explicar qué comprobamos exactamente en los casos, comenzaron a comprender estos errores "infantiles", cómo evitarlos, cómo sortearlos. Sí, hay errores tipográficos, hay algunas inconsistencias, pero la prueba automática no se cae, simplemente los registra.

Estructura de caso de prueba no óptima


Fuente 

Este es probablemente nuestro mayor dolor de cabeza. Ella dio la mayoría de los problemas, la mayor cantidad de tiempo, la mayor cantidad de horas y dinero que perdimos en ellos. Como resultado, ahora resolveremos este problema en primer lugar, si automatizamos otra cosa.

Nuestro proyecto es bastante grande, varias docenas de sistemas de información están girando en él, están unidos por grupos de trabajo. Y parece que los estándares para escribir casos son los mismos para todos, pero en un grupo esta pieza se llama "función", en otro se llama "autoridad", y el autotest lee tanto "función" como "autoridad", y cae en un estupor. Esto es solo un ejemplo. De hecho, hubo cientos de tales situaciones. Tenía que estandarizar todo esto, peinarme.

¿Qué más has encontrado además de tales ambigüedades? No encontramos casos de prueba atómica. Estos son casos de prueba, que en algunos de los pasos se pueden realizar de forma variable. Por ejemplo, en la condición, dice "puede realizar el paso 2 bajo tal autoridad y bajo tal autoridad", y en el paso 3, por ejemplo, dependiendo de la autoridad utilizada, "presione el botón" A "o el botón" C ". Desde el punto de vista de un probador manual, todo está bien. El probador entiende cómo pasarlo, el autotest no entiende cómo pasarlo. En una mala versión, él mismo elegirá el camino, en una buena, vendrá con una aclaración. Pasamos bastante tiempo convirtiendo casos de prueba no atómicos.   

Documentación marco


Fuente

Siempre debes pensar en los que vienen después de ti. Cómo analizarán su código, analizarán, etc. Es bueno si hay ingenieros, programadores competentes. Malo si no lo son. Entonces también puede enfrentar el hecho de que necesita desarmar el legado de "victorias" pasadas, documentar nuevamente, atraer personas adicionales, pasar más tiempo.

Problemas de comunicación


Fuente  

1. Falta de regulaciones para la interacción.

Vino un equipo de automatización, no saben cómo comunicarse con el equipo de pruebas funcionales manuales, y nadie, de hecho, sabe qué tipo de personas son. Sí, hay clientes potenciales que se comunican entre sí, y el resto son solo vecinos del proyecto. 

2. La presencia de regulaciones para la interacción

Luego, las regulaciones fueron escritas, pero los muchachos trabajaron por un tiempo sin el otro, y cuando las regulaciones fueron escritas, tomaron esto como la única herramienta para la interacción. Todo lo que fue más allá fue ignorado. 

Es decir, al principio los chicos simplemente no sabían cómo comunicarse entre sí, parece que estaban en las mismas salas de chat, pero si pueden hacer preguntas aquí o no, no lo saben. Y cuando ya habían trabajado durante algún tiempo en tales condiciones, desarrollaron sus propias comunidades informales y cerradas: somos "guardamanos", somos automatizadores. ¿Cómo comunicarse? Aquí tenemos la regulación, de acuerdo con la regulación. 

Compra oportuna de licencias de software especializadas


En algún momento, resultó que para el desarrollo de algunos casos todavía necesitamos software pago, pero no hay licencia para ello. Tuve que comprarlo en orden de incendio (nuevamente, costos adicionales en dinero y tiempo de inactividad). 

Mapa vial


Istonik En 

consecuencia, ahora tenemos Roadmap, cómo lanzar tales proyectos, que consiste, de hecho, en etapas, cada etapa se divide en ciertos puntos.

Etapa preliminar


Fuente 

Necesitamos un equipo líder


Timlid, un arquitecto, en general, el que estará con nosotros todo el camino, el que entiende la automatización, que es técnicamente inteligente y competente. Es recomendable que sea un desarrollador con 5 años de experiencia en ciertos lenguajes de programación que se utilizan en nuestro proyecto. Porque de una forma u otra, nuestro marco funcionará con nuestro proyecto. En consecuencia, es mejor si tanto el marco como el proyecto usan la misma pila de tecnología.

Debe haber un grupo focal


Además, esto no debería ser un grupo focal de automatización. Deben ser personas que tomarán decisiones en el futuro. Es mejor hacerlos amigos desde el principio, para que se entiendan qué decisiones toman, por qué y por qué.

Evaluación del estado de la base del caso de prueba.


Ya hablé sobre la evaluación del estado de la base de casos de prueba anterior, respectivamente, esto también se hace en la etapa muy preliminar.

Descubrimos lo que no está sujeto a automatización.


A menudo existe el deseo de automatizar todo lo que se mueve (y todo lo que no se mueve, mueve y automatiza), de hecho, alrededor del 40% de los casos de prueba suelen ser tan costosos de implementar que, en principio, nunca valdrán la pena. Por lo tanto, aquí debe ser muy claro acerca de lo que quiere: automatizar todo y volar hacia la tubería, o desea automatizar cierta prueba funcional que lo ayudará.

Evaluación de un proyecto piloto.


Evaluamos el proyecto piloto en la etapa preliminar (cuánto costará) y lo ejecutamos en los casos más difíciles (nota).

Piloto


Fuente 

Normalización de casos de prueba.


El grupo de casos recopilados está sujeto a normalización. Se eliminan las ambigüedades y las precondiciones innecesarias. 

Preparación del marco


Escribimos nuestro marco, agregamos el existente o usamos algún tipo de uno comprado.

Infraestructura


Estamos preparando soluciones de infraestructura.

Aquí es muy importante no perder: tendrá un deseo irresistible de usar en la primera etapa algún tipo de computadora doméstica debajo de la mesa para ejecutar pruebas automáticas. Esto no es necesario (las pruebas se ralentizarán y se caerán cuando alguien accidentalmente apague una computadora o derrame café sobre ella). Es necesario utilizar soluciones de infraestructura preparadas, máquinas virtuales, observar la práctica de la aplicación. En consecuencia, calcule inmediatamente su potencia tanto para este proyecto como para el próximo gran proyecto. Para hacer esto, necesitamos un especialista en automatización.

Subtotales y ajustes


Estamos escribiendo los primeros casos. Evaluamos la velocidad de toda esta felicidad. Estamos evaluando las necesidades adicionales de las personas, ya que ya comprendemos cuánto se automatizarán estos casos. Es decir, automatizamos cinco piezas, ahora necesitamos entender cuántas personas necesitamos para automatizar, condicionalmente, otros 5 mil. Algunas licencias adicionales, hardware para el soporte, tanto para el soporte que ejecutará las pruebas automáticas como para el soporte de la aplicación misma. Bueno, y, de hecho, la necesidad de finalizar los casos de prueba: qué tan malo es todo.

Resumiendo el piloto


Resumimos, escribimos un informe y tomamos una decisión sobre si iremos a la automatización o no.

Ya escribí antes que puede suceder que no vayamos. Es decir, si, por ejemplo, la recuperación de la inversión es de 18 años y el plazo de su proyecto es de 5, debe pensar por qué lo necesita.

Etapa de lanzamiento


 

Los elementos de origen se enumeran secuencialmente, pero de hecho, todos deben hacerse en paralelo.

  • Comenzamos la selección del equipo.
  • Determinamos las pistas.
  • Prioricemos los estudios de caso.
  • Normalizamos los casos de prueba.
  • Solucionamos "dificultades de infraestructura".
  • Escribimos regulaciones e instrucciones, establecemos comunicaciones, eliminamos cuellos de botella.
  • Mejoramos el marco para el trabajo simultáneo de varias pruebas automáticas y la paralelización de grupos de pruebas en ejecución.
  • Realizamos un módulo de informes y estadísticas (único y acumulativo).
  • Comenzamos a escribir autotests.

Escenario principal


Fuente 

En la etapa principal, todo es simple (jaja): se escriben las pruebas automáticas, se proporciona apoyo por escrito, se evalúan los resultados del lanzamiento, se toman decisiones de gestión, se fortalecen los poderes, se agregan flujos y, de hecho, se comunica y se comunica nuevamente con el equipo de la interfaz de usuario. Todos deben navegar en el mismo bote y remar en una dirección.

Etapa de escolta


Fuente 

La etapa de acompañamiento es ligeramente diferente de la etapa principal. Una diferencia significativa está en su duración. Además, tiene un porcentaje mucho más pequeño de nuevas pruebas automáticas que se están desarrollando. Según nuestras estimaciones, 6-10% por lanzamiento, de lo contrario es muy similar a la etapa principal.

Cual es el resultado?


Automatizamos alrededor de 1,500 casos de extremo a extremo. La estabilidad de los lanzamientos exitosos ha tenido varios lanzamientos en torno al 92-95%.

Los costos del recurso disminuyeron casi 2.5 veces. Las corridas tienen lugar en 3 a 4 horas, esto se hace por la noche, para que en la mañana tenga resultados listos.

Los detalles de la implementación técnica se describen en una serie de artículos de mis colegas:


Si comenzamos ahora, teniendo en cuenta todo lo que escribí, creo que ahorraremos mucho nuestros nervios, tiempo y presupuesto.

Gracias por la atención. Haga preguntas, lo discutiremos. 

Fuente 

¡Y también estamos esperando a nuestro equipo de jóvenes probadores!
, , .

More articles:


All Articles