Cuatro de cada cinco solicitantes de control de calidad quieren aprender a trabajar con pruebas automatizadas. No todas las empresas pueden satisfacer los deseos de los probadores manuales durante el horario laboral. Wrike organizó una escuela de automatización para empleados y hizo realidad el deseo de muchos. Participé en esta escuela precisamente como estudiante de QA.
Aprendí a trabajar con Selenium y ahora admito de forma independiente una cierta cantidad de pruebas automáticas prácticamente sin ayuda externa. Y, basándose en los resultados de nuestra experiencia conjunta y mis conclusiones personales, intentaré derivar la fórmula misma para la escuela de automatización más ideal.
La experiencia de Wrike en la organización de una escuela
Cuando se hizo evidente la necesidad de una escuela de automatización, su organización recayó en Stas Davydov, el director técnico de automatización. ¿Quién sino él puede explicar por qué se les ocurrió esta iniciativa, si obtuvieron resultados y si se arrepienten del tiempo invertido? Démosle la palabra:
— En 2016, escribimos un nuevo marco para pruebas automáticas y lo hicimos de manera que fuera fácil escribir pruebas: aparecieron pasos normales, la estructura se volvió mucho más comprensible. Se nos ocurrió una idea: necesitamos involucrar a todos los que quieran escribir nuevas pruebas y, para que sea más fácil de entender, creamos una serie de conferencias. En conjunto elaboramos un plan de temas, cada uno de los futuros profesores tomó uno y preparó un informe al respecto.
— ¿Qué dificultades tuvieron los estudiantes?
— Principalmente, por supuesto, la arquitectura. Hubo muchas preguntas sobre la estructura de nuestras pruebas. En los comentarios se escribió mucho sobre este tema y tuvimos que realizar conferencias adicionales para explicarlo con más detalle.
— ¿La escuela dio sus frutos?
- Sí definitivamente. Gracias a ella, muchas personas participaron en la redacción de pruebas y, en promedio, en el hospital todos comenzaron a comprender mejor qué son las pruebas automáticas, cómo se escriben y cómo se ejecutan. La carga para los ingenieros de automatización también ha disminuido: ahora recibimos muchas menos solicitudes de ayuda para analizar las pruebas, ya que los evaluadores y desarrolladores han comenzado a lidiar con esto ellos mismos en casi todas las situaciones. Bueno, hay varias ventajas internas para el departamento: adquirimos experiencia en presentaciones y conferencias, gracias a las cuales algunos ingenieros de automatización ya lograron hacer presentaciones en conferencias, y también recibimos un poderoso conjunto de videos y presentaciones para la incorporación de recién llegados.
Por mi parte, añadiré que la comunicación entre nuestros departamentos se ha simplificado a un nivel francamente ridículamente fácil. Por ejemplo, ahora prácticamente no necesito pensar en qué casos y en qué nivel de atomicidad automatizar. De este modo, todas las partes interesadas se ocupan plenamente de la cobertura de las pruebas, que crece constantemente. Nadie exige lo imposible a los demás.
En general, el impacto en el trabajo de los equipos es definitivamente positivo. ¿Quizás los colegas que lean este artículo también estén pensando en hacer algo similar? Entonces el consejo será sencillo: vale la pena si las pruebas automatizadas son una prioridad para ti. A continuación, hablaremos de una cuestión más compleja: cómo organizar todo esto de la forma más correcta posible para que los costes de todas las partes sean mínimos y el rendimiento máximo.
Consejos de organización
La escuela fue útil, pero, como admitió Stas, hubo algunas dificultades, por lo que fue necesario organizar conferencias adicionales. Y fue como estudiante reciente comparándome a mí mismo -en-la-ignorancia- y a mí mismo-ahora que formulé los siguientes pasos para crear, en mi opinión, la forma ideal de enseñar a los evaluadores a comprender las pruebas automatizadas.
Paso 0. Crea un diccionario
Por supuesto, este paso es necesario no sólo para el control de calidad. Sin embargo, quiero dejarlo explícito: el código base de automatización debe mantenerse en un formato legible. Lenguajes de programación: no menos importante idiomas, y desde aquí podrás comenzar tu inmersión.
Aquí hay una captura de pantalla de una vista de tareas con los nombres de los elementos. Imaginemos que está probando la vista de tareas como una caja negra y nunca ha visto Selenium en su vida. ¿Qué hace este código?
(Spoiler: la tarea se elimina a través del resto en nombre del administrador y luego vemos que hay un registro de esto en la transmisión).
Este paso por sí solo acerca los lenguajes QAA y QA. Es más fácil para los equipos de automatización explicar los resultados de una ejecución; los evaluadores manuales tienen que dedicar menos esfuerzo a crear casos: pueden hacerse menos detallados. Aún así, todos se entienden. Recibimos las ganancias incluso antes de que comenzara el entrenamiento.
Paso 1. Repetir frases
Sigamos el paralelo con el lenguaje. Cuando aprendemos a hablar desde niños, no partimos de la etimología y la semántica. Repetimos "mamá", "compra un juguete", pero no profundizamos inmediatamente en las raíces protoindoeuropeas de estas palabras. Así es aquí: no tiene sentido profundizar en las características técnicas de las pruebas automáticas sin intentar escribir algo que funcione.
Suena un poco contradictorio, pero funciona.
En la primera lección, vale la pena dar una base sobre cómo escribir pruebas automáticas directamente. Ayudamos a configurar el entorno de desarrollo (en mi caso, Intellij IDEA), explicamos las reglas mínimas de lenguaje que son necesarias para escribir otro método en una clase existente utilizando los pasos existentes. Escribimos una o dos pruebas con ellos y les damos tarea, que yo formatearía así: una rama se bifurcó del maestro, pero se eliminaron varias pruebas. Sólo quedan sus descripciones. Les pedimos a los evaluadores que restablezcan estas pruebas (no mediante show diff, por supuesto).
Como resultado, aquel que escuchó e hizo todo podrá:
- aprenda a trabajar con la interfaz del entorno de desarrollo: creando ramas, teclas de acceso rápido, confirmaciones y push;
- dominar los conceptos básicos de la estructura del lenguaje y las clases: dónde insertar inyecciones y dónde importar, por qué se necesitan anotaciones y qué tipo de símbolos se encuentran allí, además de los pasos;
- entender la diferencia entre acción, esperar y comprobar, dónde usar qué;
- Observe la diferencia entre pruebas automáticas y comprobaciones manuales: en las pruebas automáticas puede utilizar uno u otro controlador en lugar de realizar acciones a través de la interfaz. Por ejemplo, envíe un comentario directamente al backend en lugar de abrir una vista de tareas, seleccionar la entrada, escribir texto y hacer clic en el botón Enviar;
- Formule preguntas que serán respondidas en el siguiente paso.
El último punto es muy importante. Estas respuestas se pueden dar fácilmente con anticipación, pero es un principio de enseñanza importante que las respuestas sin preguntas formuladas no se recuerdan y no se utilizan cuando finalmente se necesitan.
Sería ideal si en este momento un ingeniero de automatización del equipo de control de calidad le asignara la tarea de escribir un par de pruebas en batalla y le permitiera subcomprometerse con su rama.
Qué no regalar:
- conocimiento más profundo de la funcionalidad del entorno de desarrollo y del lenguaje de programación en sí, que solo será necesario cuando se trabaje con sucursales de forma independiente. No se recordará, habrá que explicarlo dos o tres veces, pero valoramos el tiempo de los ingenieros de automatización, ¿verdad? Ejemplos: resolver conflictos, agregar archivos a git, crear clases desde cero, trabajar con dependencias;
- todo lo relacionado con xpath. En serio. Es necesario hablar de ello por separado, una vez y muy concentradamente.
Paso 2. Observando más de cerca la gramática
Recordemos la captura de pantalla de la vista de tareas del paso 0. Tenemos un paso llamado checkCommentWithTextExists. Nuestro evaluador ya comprende lo que hace este paso y podemos mirar dentro del paso y descomponerlo un poco.
Y dentro tenemos lo siguiente:
onCommentBlock(userName).comment(expectedText).should(displayed());¿Dónde está onCommentBlock?
onCommonStreamPanel().commentBlock(userName);Ahora aprendemos a decir no "compra un juguete", sino "compra un juguete en la tienda Detsky Mir, ubicada en el gabinete azul en el tercer estante desde arriba". Es necesario explicar que apuntamos a un elemento secuencialmente, desde elementos más grandes (flujo -> bloque con comentarios de una determinada persona -> esa parte de este bloque donde se encuentra el texto especificado).
No, todavía no es el momento de hablar de xpath. Sólo mencione brevemente que todas estas instrucciones son descritas por ellos y la herencia pasa por ellos. Pero necesitamos hablar de todos estos emparejadores y camareros; se relacionan específicamente con este paso y son necesarios para entender lo que está sucediendo. Pero no se sobrecargue: su alumno podrá estudiar afirmaciones más complejas por su cuenta más adelante. Lo más probable es que debería esperar hasta que se muestre();, exista();, no(); debería ser suficiente.
La tarea es obvia: una rama en la que se han eliminado los contenidos de varios pasos necesarios para un determinado número de pruebas. Deje que los evaluadores los restauren y hagan que la ejecución vuelva a ser verde.
Además, si el equipo de pruebas no solo tiene nuevas funciones en su trabajo, sino también algunas correcciones de errores, puede pedirle que escriba pruebas inmediatamente para estos errores y las publique. Lo más probable es que ya se hayan descrito todos los elementos; es posible que solo falten un par de pasos. Este será el entrenamiento perfecto.
Paso 3. Inmersión total
Lo más completo posible para un tester que va a seguir desempeñando sus funciones directas. Finalmente, necesitamos hablar de xpath.
Primero, dejemos en claro que todos estos onCommentBlock y comentarios son descritos por ellos.
Total:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"El orden de la historia es muy importante. Primero, tomamos cualquier xpath existente y mostramos cómo la pestaña de elementos contiene uno y solo un elemento. A continuación, hablaremos sobre la estructura: cuándo necesita usar WebElement y cuándo necesita crear un archivo separado para un nuevo elemento. Esto le permitirá comprender mejor la herencia.
Debe indicarse explícitamente que un solo elemento es la vista de tareas completa, contiene un elemento secundario (la secuencia completa, que contiene un elemento secundario), un comentario separado, etc. Los elementos secundarios están dentro de los elementos principales tanto en la página como en la estructura del marco de autoprueba.
En este punto, la audiencia debería haber comprendido firmemente cómo se heredan y qué se puede ingresar después del punto en onCommentBlock. En este punto, explicamos todos los operadores: /, //, ., [] y así sucesivamente. Agregamos conocimiento sobre el uso a la carga. @class y otras cosas necesarias.
Los estudiantes deben entender cómo traducir xpath de esta manera. Para consolidar, así es, tarea. Eliminamos las descripciones de los elementos, dejamos que restablezcan el trabajo de las pruebas.
¿Por qué este camino en particular?
No debemos sobrecargar a una persona con conocimientos complejos, pero debemos explicarlo todo de una vez, y este es un dilema difícil. Este camino nos permitirá primero hacer que los oyentes hagan preguntas y no entiendan algo y responderlas al momento siguiente. Si hablamos de toda la arquitectura, cuando se analice el tema de los pasos o xpath, las partes más importantes ya se habrán olvidado debido a su incomprensibilidad.
Sin embargo, algunos de ustedes probablemente podrán compartir su experiencia sobre cómo se puede optimizar aún más el proceso. ¡Estaré feliz de leer sugerencias similares en los comentarios!
Fuente: habr.com