Hola Mi nombre es Alyona Isakova, soy un probador líder en Avito y quiero contarles sobre mi experiencia en la presentación de las pruebas ágiles al equipo. Cuando leí artículos sobre pruebas ágiles y ATDD disponibles en ruso, tuve la impresión de que "no estaba de moda", "no sobre Agile". Parecía que se trataba de algún tipo de estructura compleja que requería la inclusión de desarrolladores, y antes de que se aplicara, todavía tenía que "arar y arar".

Durante un tiempo viví con esta idea, escribí una lista de tareas durante la configuración de las tareas, reuní reuniones del "equipo de características", a las que PM, QA, Frontend y Backend fueron invitados a discutir los matices de la tarea antes de la implementación.

Los que entienden de lo que están hablando ya han notado la captura, ¿no?

Si buscas en Google lo que es "Agile testing", puedes proponer sugerencias para tomar cursos, un par de artículos con opiniones sobre el enfoque y la definición en Wikipedia:

"Agile testing es una práctica de prueba de software que sigue los principios del desarrollo de software ágil. Las pruebas ágiles involucran a todos los miembros de un equipo ágil multifuncional, con experiencia especial aportada por los evaluadores para garantizar la entrega del valor comercial deseado por el cliente a intervalos frecuentes, trabajando a un ritmo sostenible. La especificación por ejemplo se utiliza para capturar ejemplos del comportamiento deseado y no deseado y guiar la codificación ".

No sé sobre ti, pero no terminé de leer esta definición la primera vez, fui atacado por el anhelo. De hecho, no todo está tan seco. La conclusión es que las pruebas ágiles son un enfoque para el proceso de prueba, en el que el probador está mucho más involucrado en las primeras etapas de la tarea y menos (o completamente ausente) en la última, a diferencia del enfoque de Cascada.

¿Cómo se organizó nuestro flujo de tareas?

Vale la pena decir que inicialmente nuestro equipo trabajó en el riguroso SCRUM, perdón por la expresión, que obviamente va bien con las pruebas ágiles, se puede decir que lo implica.

1. Declaración del cliente (asumir PM)

En esta etapa, la declaración del problema se realizó de acuerdo con el esquema Historia del usuario, Criterios de aceptación, Caso de uso. Tal afirmación, obviamente de Agile, no es accidental: es un mérito de mi colega en la unidad, que ya ha introducido las pruebas de Agile en su equipo. Por qué no podría simplemente tomar prestada la experiencia de un equipo vecino, te lo diré más adelante en el artículo.

2. Revisión por el probador de la declaración del problema.

En esta etapa, se verificó la tarea en busca de unicidad, consistencia y utilidad. En mi caso, también agregué el elemento "pruebas" aquí, que describía casos de prueba adicionales (por ejemplo, negativos), que no eran apropiados para escribir en el formato de caso de uso. En ese momento, no tenía plena conciencia de cómo usar los criterios de aceptación, por lo que intenté darle al desarrollador la máxima información para mis futuras comprobaciones.

3. Discusión de la tarea por todos los interesados ​​o "equipo de características"

La etapa se realizó según sea necesario. Si después de la revisión, el evaluador decidió que la tarea es clara y no se requieren discusiones adicionales, pasamos al cuarto párrafo.

Si la etapa era necesaria, en la reunión se aclararon los requisitos, trabajo adicional. A menudo, la tarea se descompuso, las condiciones de prueba se discutieron durante la operación independiente de la interfaz y el backend.

4. La tarea seguida en una cartera de pedidos, fue planeada, llevada a cabo, implementada y trajo beneficios y felicidad

Parece que no todo es tan malo, pero hay algo que mejorar: al menos puedes eliminar un par de pasos adicionales, ya que no entendemos por qué lo son.

¿Qué se ha hecho para mejorar?

Sintiendo un deseo insaciable de mejorar, el desarrollador y yo aprobamos una clase magistral interna sobre pruebas ágiles. Resultó que para cumplir completamente con el enfoque, el equipo solo necesita cambiar la terminología y apretar un poco los tornillos de nuestra bicicleta personalizada.
Introducir el enfoque, observar los equipos en los que ya existe, no es suficiente, necesita un bloque de conocimiento y una etapa de conciencia, que en mi caso fue impartida por una clase magistral. Una gran ventaja fue el hecho de que recibimos capacitación con el desarrollador, lo cual aconsejo encarecidamente a todos, es difícil sobreestimar su ayuda. Ustedes dos (probador y desarrollador) son un mínimo necesario y suficiente para comenzar a implementar el enfoque. Además, cada equipo y producto es individual, para poder perfeccionar este método usted mismo, al menos debe intentarlo.

Por ejemplo, en un equipo vecino hay experiencia en el uso útil de pruebas unitarias con una descripción preliminar en una herramienta para almacenar casos de prueba y su posterior automatización. Nuestro equipo decidió determinar primero la verificación necesaria conceptualmente, automatizarla y luego seleccionar automáticamente los casos del código en una herramienta de almacenamiento. Puede tener su propia forma de interactuar.

No declaro que sin un evento especial es imposible introducir un enfoque, en ningún caso. Pero debe tomarse el tiempo para comprender, motivar al equipo y comenzar a cambiar y cambiar. Esté preparado para que no todos acepten de inmediato el aumento en el tiempo dedicado a la tarea con los brazos abiertos, tuve suerte en este sentido.

Qué leer sobre este tema

“Pruebas ágiles. Curso de capacitación para todo el equipo ”, Janet Gregory y Lisa Crispin. El libro ha sido publicado recientemente en traducción rusa y está disponible en Ozone.

¿Qué ha cambiado exactamente?

1. En nuestras reuniones para aclarar el retraso (PBR), me convertí en un excelente alumno molesto preguntando todo y todo: "¿Qué sucederá si el servicio de terceros se cae?", "¿Qué sucederá si regresamos nulo, no 0?", "A ¿por qué llamamos a esto y no allá? "," ¿Y si no obtenemos todos los datos? "," ¿Y si el planeta es capturado por dinosaurios rebeldes? " Es broma, solo preguntas importantes, no "nulo" y "0".
   Con el tiempo, los muchachos se dieron cuenta de que en esa discusión, nacen varios casos no contados por adelantado que ahora pueden prever. Anteriormente, preguntas como "¿Qué pasa si todo se desmorona?" Me preguntaba en la fase de prueba, y ahora en la fase de configuración.
2. En lugar del ítem “Pruebas” en las tareas, escribimos “Criterios de aceptación” en detalle y conscientemente, y también determinamos el número y los niveles de futuras pruebas automáticas.
   Para ser sincero, vale la pena decir que no en el 100% de los casos conocemos los niveles de autotest de antemano. Hay momentos en que técnicamente no podemos hacer esto o lleva más tiempo del que tenemos en la reunión. En la práctica, a menudo no es posible actuar dramáticamente. Y esto es permisible: algo vendrá con el tiempo.
3. Los ítems “Revisión del enunciado del problema por parte del probador” y “equipo de características” que no estamos realizando actualmente. Resolvemos todos los problemas en las reuniones de PBR, ya que todas las personas necesarias ya están aquí, y los criterios de aceptación se discuten en el proceso.
4. El probador se agrega al código de revisión de prueba de la unidad para confirmar que hay suficientes verificaciones.
5. En lugar de las pruebas habituales de funcionalidad, al final del proceso de desarrollo, se realizan pruebas automáticas (en todos los niveles) y solo se realizan pruebas de investigación.
   Idealmente, por supuesto, las pruebas no deberían estar ahí, pero en nuestra práctica hemos descubierto que cuando realiza cambios en un producto desarrollado por muchos equipos, es más fácil y más correcto agregar pruebas de investigación.

¿Qué dificultades enfrentaste?

1. ¿Qué es una prueba unitaria?

Nos enfrentamos con el hecho de que nosotros, QA, no entendemos qué pruebas unitarias están probando y, por lo tanto, no confiamos en ellas, y en homenaje a nuestra vigilancia, escribimos pruebas un nivel más alto y con un taco de golpe "para automatizar, no se puede tener piedad".

Según lo decidido:
Nosotros, con nuestro desarrollador ágil (gracias a él y su paciencia), nos sentamos en la esquina y, durante una hora, me explicó con los dedos qué son las pruebas unitarias, con qué comen y por qué aún no pueden comprobar "esta pequeña cosa". Como resultado de nuestro sufrimiento, nació un increíble esquema de servicio: lo dibujaron de tal manera que ellos mismos lo entendieron.

Una flecha seleccionada - un viaje - un chequeo en la prueba de la unidad

Como resultado, después de un par de meses, yo mismo escribo unas pequeñas pruebas unitarias y borro cheques redundantes en los niveles superiores. Esto, por supuesto, es principalmente copiar y pegar, ¡pero consciente!

Quizás ya comprenda bien la esencia de las pruebas unitarias y no tenga que dedicar tiempo a este elemento, pero si no, subcautice a su desarrollador en un entorno tranquilo y ataque con preguntas.

2. En la implementación actual, no todas las pruebas pueden omitirse sin modificaciones

Según lo decidido:
Se eliminaron los conjuntos de datos innecesarios de las pruebas e2e al aumentar el número de pruebas unitarias.
Ya hemos revisado las pruebas unitarias que se han implementado, hemos anotado las comprobaciones que queremos de ellos. Después de eso, bastante esperado, resultó que nos faltaban algunos de los controles.
Habiendo determinado qué y a qué nivel queremos, establecemos tareas para el futuro.
Después de habernos capacitado en lo que ya existe, retomamos la aplicación real del enfoque y comenzamos a escribir controles sobre métodos que aún no están disponibles. Ya fue más difícil.

Conclusiones

• La peculiaridad de este enfoque es que es natural y surge de cosas tales como: "transmitir valor al usuario", "reducir el control de calidad manual", "proporcionar cobertura". Cómo hará exactamente esto es otro asunto, pero este enfoque tiene algo que ofrecerle y sugerir qué claves maestras usar para simplificar su vida y no perder nada.
  Por ejemplo, las "prácticas de prueba ágiles" son herramientas listas para su aplicación, y los "valores" y los "principios" son lo que entiende el evaluador de una persona sana, pero aún así vale la pena decírselos repetidamente a usted y a su equipo, porque sé por experiencia : a menudo se relegan a un segundo plano en modo de carga alta.

  
  

• Lo principal en la metodología ATDD es que antes de hacer algo, debe elaborar un criterio para el trabajo realizado y un criterio para que el trabajo se realice correctamente. En términos generales, el enfoque determina el período de tiempo en el que está de acuerdo con el equipo. El resto va junto con la obra.

  
  

Por ejemplo, te das cuenta de que en tus condiciones no puedes distinguir la capa de integración de las pruebas, eso está bien. Comience con los primeros pasos del enfoque: escriba los criterios de aceptación, defina las pruebas y sus niveles, cree una tarea para un futuro más brillante. La etapa más útil aquí es la definición de controles por adelantado, a partir de sus preguntas meticulosas en la etapa de configuración de la tarea: el resultado positivo más rápido que demostrará a su equipo que no está perdiendo el tiempo.

• En general, el enfoque de evaluación ágil y los valores, principios y prácticas propuestos en él se derivan de cosas bastante obvias, como dijo mi maestro favorito en álgebra superior: "Pero aquí es necesario aplicar el sentido común". Vale la pena seguirlo, y no solo en las pruebas.

Una vez, en medio de una discusión, el equipo y yo nos dimos cuenta de que estábamos escribiendo cheques en demasiadas condiciones, y esto nos llevó a la pregunta: "¿Estamos llamando al método exactamente en ese parámetro?" Resultó que la formulación del problema se puede simplificar fundamentalmente llamando a la esencia misma, y ​​no a la lógica por encima del nivel. Es decir, las condiciones cuando tenemos una entidad dependiente, pero no hay una entidad en sí misma, no existe. Nos hizo la vida más fácil.

Según cómo determinar el nivel del caso de prueba, este es un holivar separado, cuando comience a sentir dolor, intente consultar la literatura. Y recuerde que la práctica debe aplicarse donde realmente resuelve el problema, donde facilita la vida. Todo bien, buena suerte y sellos!