Te va a interesar!

6/recent/ticker-posts

El Dream Team de Automation Testing


Cuando hablamos de Automation Testing, generalmente nos imaginamos a esos pedantes (no me miren a mi che!) SDET. Ingenieros de Test haciendo complejos códigos que prueban la aplicación bajo test, dependencias, librerías, artefactos, source control...pero hay mucho más que gente técnica en el equipo ideal de Automation.
De hecho, si pensamos en Agile, el foco está puesto en la colaboración entre distintas especialidades en pos de entregar un producto que siga los lineamientos de los requerimientos y que sea de una calidad óptima. Por eso, en este artículo, te voy a contar sobre el Dream Team de Automation...o más bien de Testing! A ver qué tan cerca estás en tu actual equipo de lograr la perfección!

Business Analysts: No están de adorno.

Sabemos que son el nexo entre las alocadas ideas del cliente y lo que se va a desarrollar. Son los encargados de plasmar en diseños funcionales los requerimientos que aquellos que ponen el billete esperan recibir. Cuando hablamos del rol del BA en Automation, lo que quiero decirles es que ellos deberían ser los encargados de desarrollar los Scenarios de prueba. Cómo? Simple...ahí entra Cucumber y su lenguaje, Gherkin. 
Ellos pueden ser la piedra filosofal de lo que se va a construir como suite de tests automatizados. Después de todo, ellos conocen la palabra final sobre cómo debería funcionar cada parte y qué es necesario probar en cada caso. Al menos inicialmente, claro está, porque este trabajo puede y debe ser complementado por lo que los testers funcionales, con su experiencia en la aplicación, puedan aportar. Casos de prueba negativos, prueba de límites, pruebas de seguridad, etc. 
El lenguaje Gherkin, para los que no vienen siguiendo los tutoriales ACA, es una forma de escribir los casos prueba en términos amigables para las personas no técnicas. Por si solo no hace nada este escenario, no va a ejecutar nada. Para eso, debemos definir los steps que el BA escribió y darles acciones. Ahí es donde entra el...

Tester funcional y manual: La mejor manera de hacer la transición a Automation. 

El equipo tiene los Scenarios necesarios para probar el diseño funcional, y no solo eso...viene del mismísimo BA que tradujo lo que el cliente quería en algo que los desarrolladores pueden empezar a hacer. Pero esos escenarios no se van a definir solos, no? Necesitamos definir los steps que conforman cada uno de ellos y decir qué van a hacer. El Tester funcional, en este caso, es el más indicado para hacerlo. Y digo ésto porque es el que más contacto tiene con la aplicación. Es el encargado de probar inicialmente mediante la interfaz, que todo funcione bien. Se sabe cada click, reload y campo a llenar de memoria y es este conocimiento lo que se capitaliza en esta fase. 
El tester funcional va a ser el encargado de poner las acciones necesarias dentro de cada step. No requiere de conocimientos profundos sobre programación, aunque va a estar expuesto a un entorno de desarrollo y va a empezar a saber más. También va a interactuar con el IDE, lo que le va a dar una iniciación en lo que posteriormente es crear las funciones que ahora mismo está simplemente colocando en su lugar. Y bueno...estas acciones que el tester funcional está poniendo cual rompecabezas tienen que salir de algún lado, no? Y ahí es donde entra, recién, el famoso...

Ingeniero de Test: Porque testing también necesita un héroe.

Esta es la sección más compleja de la suite de automatización. El Ingeniero de Test va a ser el encargado de armar el Framework en el cual va a descansar todo el equipo y en el que van a trabajar en conjunto. Si el BA escribió un Scenario con un Step que, al ser definido por el Tester Funcional, se encontró que necesitaba una función para manejar una grilla de Infragistics la cuál no tienen...es a él al que le van a pedir que desarrolle una función o las necesarias para poder interactuar con esa grilla de manera de poder definir los steps como hace falta. 
También va a ser el encargado de mantener limpio el código, implementar una política de Source Control adecuada, en la que el Master siempre tiene la última versión estable del Framework de automatización. Va a configurar Jenkins de manera que los tests puedan ser ejecutados mediante Jobs para la correcta visualización de los resultados por parte de Management y va a estar ahí para responder a cualquier desafío técnico que el equipo de testing enfrente. 

Test Lead: hands on y con conocimiento técnico.

Pido mucho? Yo creo que no! Como les comentaba en este otro artículo, el Test Lead tiene que ser una persona capaz de resolver de forma eficaz y rápida cualquier problema relacionado al testing, la prioridad de los tests a automatizar y/o ejecutar y el que va a velar por mantener la expectativa a niveles sanos con los Managers. Es un veterano de testing, que sabe de automatización y pasó por los 7 infiernos de QA. Va a facilitar el trabajo del resto del equipo, dejando que hagan lo que mejor saben hacer y les conté más arriba, mientras él se ocupa de la parte más administrativa y burocrática si se quiere, al mismo tiempo que está al pie del cañón listo para resolver cualquier emergencia o duda técnica.
La interacción con los managers van a ser para mantener las expectativas de las que les hablo dentro del mundo de lo realizable. Y eso lo va a lograr porque tiene conocimiento de las herramientas que se están usando. Eso le permite aceptar y estimar con una eficiencia mucho mayor a la que podríamos aspirar con una persona que no es técnica y no sabe qué hace falta para realizar lo que se está pidiendo del otro lado. 


Conclusión: un equipo multidisciplinario con un mismo objetivo.

Esto que les presento en este artículo es la base a la que un equipo de Testing debería aspirar. Hay más detalle en cada rol y algunos roles que pueden complementar lo que detallo acá, pero con un equipo así podés conquistar cualquier desafío! 
Y vos...cómo te sentís al respecto de la configuración del equipo en el que te encontrás? Qué cambiarías? Estás de acuerdo con lo que planteo o cambiarías/agregarías/sacarías algo? Déjame tu comentario! 

Publicar un comentario

0 Comentarios