Al leer los artículos sobre el tema de las pruebas web, dos temas surgen condicionalmente: 1) las pruebas manuales están desapareciendo, las pruebas automáticas (en adelante denominadas pruebas automáticas son pruebas de Selenium UI y REST) son nuestro todo; 2) las pruebas automáticas no son una panacea; las pruebas manuales son indispensables. Al mismo tiempo, de los artículos hay una tendencia hacia un aumento en los requisitos para la calidad del software y la velocidad del desarrollo del producto. Wrike es el caso cuando estos requisitos son críticos.
El producto ya tiene 12 años, pero todavía está creciendo activamente. Las implementaciones ocurren una vez al día, y algunas veces dos. Por lo tanto, es de vital importancia para nosotros que la regresión se lleve a cabo exclusivamente en autotest. Sin embargo, en Wrike (en la compañía) hay más de 30 equipos scrum, y el personal del equipo de automatización no es de goma. En tales condiciones, esperar la automatización de escenarios manuales en el mejor de los casos, uno o dos sprints no es una opción. La experiencia de nuestra empresa dice que un probador manual puede escribir pruebas automáticas de forma independiente, sujeto a ciertos matices. En el artículo contaré sobre ellos y por qué, en mi opinión, esta capacidad no solo ayuda a mantenerse al día con las tendencias, sino que también será útil para el probador mismo.
Proceso estándar
¿A qué proceso están acostumbrados muchos equipos? Varía de un caso a otro, pero las características comunes son casi las mismas. Hay departamentos de pruebas automáticas y manuales. Los probadores manuales se pueden distribuir entre los comandos scrum. En este caso, la automatización, por regla general, no tiene relación con un equipo específico.
Al trabajar con una nueva funcionalidad, el probador crea scripts de prueba, algunos de los cuales marca de manera predeterminada para los automatizadores. Además, si ya hay casos en los que se realizan ajustes, también se anotan para actualizar el código. Luego, las pruebas marcadas se transfieren al departamento de automatización. Un equipo de ingenieros de automatización asume la tarea de arreglar las pruebas automáticas actuales y nuevas en uno de los siguientes sprints. Además de programar escenarios de prueba, las tareas del automatizador incluyen ejecutar pruebas automáticas, analizar los resultados, así como apoyar y desarrollar el proyecto de prueba. Resulta que el departamento de automatización actúa como un ejecutor externo y los probadores manuales son una especie de clientes.
El cliente también pasa tiempo compilando un TOR detallado y preciso, discutiendo periódicamente los métodos de implementación y seleccionando las pruebas necesarias. También hay riesgos de que durante la ausencia de autotests se puedan omitir errores. No olvide que hay una capa de problemas técnicos que solo podrían acumularse en las pruebas automáticas, lo que ahorraría mucho tiempo. Dichas tareas deberán verificarse manualmente en la parte donde todavía falta la automatización.
El contratista, que no está muy inmerso en la funcionalidad en la que se involucró el equipo, se tomará un tiempo para sumergirse superficialmente en la tarea y en la conciencia de los TOR. Al mismo tiempo, es probable que la prueba no se traduzca con precisión al código, por lo que no comprobará lo que nos gustaría. En consecuencia, la eficiencia de la base de prueba se reduce.
El equipo de automatización, que es el único contribuyente al proyecto de prueba, tiene control total sobre su base de código, lo que le permite desarrollarse fácilmente en cualquier dirección. Sin embargo, el tiempo para esto se vuelve insuficiente debido a la creciente carga de otros equipos. El problema puede resolverse expandiendo el personal, pero luego el costo de la automatización excederá su efectividad. Incluso si elimina parte de la carga, dando a los probadores manuales la oportunidad de ejecutar pruebas y analizar las caídas, esto no traerá el resultado adecuado. Como no tienen herramientas para depurar las pruebas, es posible que no entiendan que la prueba se bloqueó debido a un cambio en xpath, etc.
En consecuencia, en el resultado se obtiene que las pruebas automáticas con este esquema no se mantienen al día con el crecimiento del producto, lo que conduce a una cobertura deficiente del código. Debido a una interpretación inexacta de los conocimientos tradicionales, las pruebas pueden omitir errores. Cuando no están actualizados por mucho tiempo, los caídos no se reparan de inmediato, y es difícil para los evaluadores manuales saber de inmediato qué parte del sistema está bien cubierta por la automatización. Las pruebas automáticas se convierten en una especie de caja negra, a la que los evaluadores desconfían. Por lo tanto, el número de comprobaciones manuales innecesarias está creciendo, los términos de las tareas se estiran y la calidad disminuye a largo plazo.
Puede trabajar con estas deficiencias, pero cuanto más grande sea el producto y la empresa, más doloroso para los participantes en el proceso, y lo más importante, es difícil seguir la tendencia de aumentar la velocidad y mejorar la calidad. El probador mismo se convierte en un rehén de la rutina y prácticamente no permanece en el desarrollo del tiempo.
Camino de Wrike
Entonces, cómo funciona en el ejemplo del equipo en el que trabajo. Hay equipos de prueba automáticos y manuales. Los datos iniciales siguen siendo similares, pero luego comienzan las diferencias. Los probadores manuales se distribuyen entre sus equipos scrum. Cada equipo scrum tiene su propio autotest. A veces se puede asignar no a uno sino a dos equipos, si la carga lo permite.
Cuando trabaja con una nueva funcionalidad, el probador escribe listas de verificación, de acuerdo con las cuales realiza verificaciones manuales. La parte mínima requerida de las pruebas de esta lista de verificación es automática. El probador mismo escribe estas pruebas automáticas en el momento en que la característica está en desarrollo o en prueba. Además, el código escrito se entrega al revisor para su revisión. Con raras excepciones, no se puede emitir una tarea sin autotests.
Por supuesto, no hay ningún requisito en Wrike para escribir autotests por probadores manuales. Esto queda a discreción del equipo. Puedes dar todo a la automatización. Puede limitarse a arreglar las pruebas rotas y / o escribir nuevas pruebas por analogía, y delegar tareas más complejas (crear nuevas pruebas o expandir antiguos controladores de fondo, objetos de página o pasos de prueba y clases) a una herramienta de automatización dedicada. Todo depende de usted, pero es estúpido perder esas ventajas que brinda la escritura independiente de las pruebas automáticas.
Toda nuestra regresión se basa en pruebas automáticas, y las responsabilidades de los probadores manuales incluyen ejecutar y analizar fallas de la prueba automática. Para cada rama en la que trabaja el equipo, realizan pruebas automáticas como el garante inicial y final de la calidad. Por lo tanto, es mucho más fácil para aquellos que escriben autotests comprender por qué se bloqueó una prueba que se ejecutaba en su rama. A veces, las herramientas como volver a ejecutar y un informe en
Allure son realmente suficientes, donde puede comprender el motivo del bloqueo de la prueba a partir de la captura de pantalla y los pasos. Sin embargo, a menudo el mejor asistente es la capacidad de ejecutar pruebas localmente, jugar con pasos o ejecutarlos en modo de depuración, ver el xpath esperado y real. Sin experiencia trabajando con un proyecto de prueba, esto llevará mucho tiempo o será necesario distraer la herramienta de automatización dedicada.
Además, la escritura independiente de las pruebas automáticas permite ejecutarlas incluso antes de que se lance la función. El probador siempre conoce el grado de cobertura de su parte del sistema, y las tareas técnicas solo funcionan en las pruebas automáticas, lo que ahorra significativamente tiempo y recursos al equipo. Las pruebas en sí mismas siempre son relevantes, ya que los bloqueos se ajustan antes del lanzamiento. Las pruebas rotas se corrigen inmediatamente en la misma rama donde se escriben las nuevas.
El probador manual está inmerso al máximo en la tarea del equipo, por lo que se selecciona el mínimo necesario de pruebas automáticas, cubriendo la mayoría de los casos. La muestra se revisa varias veces durante las pruebas, ya que durante las comprobaciones manuales, la funcionalidad se estudia con más detalle con todos los matices. En consecuencia, la eficiencia de tales pruebas está creciendo. Escribir autotests le permite comprender mejor la arquitectura de la aplicación, los componentes utilizados y la interacción del front-end con el back-end. En última instancia, este conocimiento ayuda a un enfoque más consciente y efectivo para las pruebas de productos. Por ejemplo, si algún comando realiza cambios en el componente general, es más probable que sepa de antemano si su alcance se verá afectado o no, ya que cuando trabaja con xpath comprende qué componentes se utilizan en su parte de la aplicación.
Se puede argumentar que escribir autotests lleva tiempo. Sí, las tareas se lanzarán de uno a tres días más tarde de lo habitual, pero a la larga vale la pena. Además, hay métodos de optimización. Por ejemplo, mientras una característica está en desarrollo, puede elaborar las listas de verificación necesarias y dejar un espacio en blanco para las pruebas, ahorrando así tiempo. Si tiene un marco de funcionalidad listo para usar, es posible agregar o corregir xpaths existentes, si es necesario, crear un nuevo Objeto de página o ajustar los pasos. Luego, en la etapa de escritura de las pruebas automáticas, después de las comprobaciones manuales, solo necesita agregar los bloques de código en el orden correcto.
Gracias al marco desarrollado por nuestro equipo de automatización, escribir autotests en su mayor parte representa compilar código a partir de bloques, como Lego. Esta simplicidad le permite adaptarse rápidamente a los probadores manuales y comenzar a escribir autotests por analogía con los existentes. Desde mi propia experiencia, diré que pasaron cerca de dos semanas desde el momento en que trabajé en Wrike hasta las primeras pruebas automáticas que escribí, junto con otras tareas.
El control de calidad de las pruebas automatizadas escritas se lleva a cabo a través de la revisión del código. Ni una sola rama de prueba ingresa a la versión sin una revisión. Este es un buen momento de entrenamiento, ya que el probador extrae información útil de los comentarios sobre su código y desarrolla la experiencia de buenas soluciones: por ejemplo, administra la biblioteca estándar de Java de manera más eficiente o define xpath con mayor precisión. La próxima vez estará claro cómo trabajar mejor con una situación particular.
Por supuesto, el desarrollo de un proyecto de prueba, un marco y la capacitación de probadores manuales utilizan los recursos de la automatización, especialmente en la etapa inicial, pero me parece que estos esfuerzos están totalmente recompensados. Tenemos muchas mejoras en el entorno de pruebas automatizadas que facilitan nuestro trabajo. El producto en sí tiene una buena cobertura, por lo que puede confiar en la regresión. Esto ayuda a acelerar el proceso de implementación de funciones en el entorno del usuario y protege enormemente los nervios de los evaluadores.
Según la experiencia de nuestro equipo, este es uno de los mejores procesos para trabajar con un producto grande y de rápido desarrollo en una gran empresa. Además, está en línea con las tendencias actuales en la mejora de la calidad del software y la velocidad de su entrega a los usuarios. El probador mismo prácticamente elimina la rutina, se desarrolla en varias direcciones y observa la aplicación desde varios ángulos.
Brevemente sobre lo principal
Para mayor comodidad, destacaré las ventajas de un probador manual en un solo lugar, para que sea más fácil darse cuenta de su importancia individualmente o en conjunto:
- Se forma una imagen más completa sobre el nivel y la calidad de la automatización de sus ámbitos;
- Las pruebas automáticas están disponibles antes de que se lance la función, lo que permite verificar rápidamente su calidad en cualquier momento;
- La eficiencia de las pruebas automáticas aumenta, al igual que la eficiencia de las pruebas en general;
- Se está formando un enfoque más informado y efectivo para las pruebas;
- Deshacerse de regresiones manuales monótonas y pruebas de evaluación largas;
- Crecimiento personal y desarrollo de competencias.
Para resumir
Por supuesto, no hay bala de plata. Lo que es adecuado para una empresa puede ser rechazado por otra. En el caso de Wrike, el producto crece extremadamente rápido y no hay tiempo para largas regresiones manuales y pruebas de evaluación. Tenemos este papel desempeñado por las pruebas automáticas, que cubren casi todos los componentes de un gran producto. Esto ayuda a mantener la calidad, optimizar los recursos y proporcionar nuevas funcionalidades a los usuarios más rápido.
La mala noticia es que no puede prescindir de errores, pero en nuestro caso, a menudo estos son algún tipo de casos extremos. La buena noticia es que los errores durante las correcciones también están cubiertos de autotest.
Por alguna razón, se ha vuelto tan común en la comunidad que se rechaza la idea de escribir autotests por probadores manuales. Hay dos argumentos más populares por parte de los evaluadores: "No pagan más por esto" y "Ya tenemos suficiente trabajo". Para mí personalmente, ambos argumentos se desmoronan cuando me doy cuenta de que puedo realizar autocomprobaciones en el momento en que se desarrolla una característica y en poco tiempo entiendo cómo funciona correctamente. Vale mucho Nuestro trabajo es mejorar y mantener la calidad del producto, por lo que cada oportunidad se utiliza para facilitarlo. Desde el momento en que comencé a escribir autotests, la rutina en mi trabajo se ha vuelto cada vez menos consciente.
PD: Este artículo refleja solo la experiencia de nuestro equipo y puede no corresponder a sus creencias. Por lo tanto, me complacerá saber acerca de los enfoques que lo guían en su trabajo. También estaré contento con las críticas saludables y la oportunidad de discutir el artículo en los comentarios.