Te va a interesar!

6/recent/ticker-posts

Full Stack Automation Tester: Si...otra manera más de rotular al tester!

Bienvenidos nuevamente a un post en The Free Range Tester! Acá, su instructor amigo y coach de todas las cosas relacionadas a Automation, Pato...el Argentino perdido en alguna isla del Pacífico.

Hoy les quería hablar de algo con lo que vengo bromeando hace unas semanas en el trabajo. Pero como sabrán, en toda broma hay algo de verdad...así que en parte es algo que siento tiene que ser dicho. Habiendo ya expuesto la temática de Automation en UI vs WebServices, como así también explicado el concepto de API, ahora voy a hablar de algo que, en mi opinión, es requisito fundamental de todo Tester que aspire a crecer en Automation y que lo va a convertir, al final del camino, en un Full Stack Automation Tester.

¿Qué es un Full Stack Automation Tester?

Para ponernos en contexto, analicemos un poco a qué se refiere uno cuando dice el término "Full Stack". En el ambiente de desarrollo, se refiere al dev que maneja tanto tecnologías de Back End como de Front End. Va a usar tecnologías en ambas capas, como JavaScript y HTML para el FE y Python, Java o Ruby para el BE. Osea...su "stack", o pila, de tecnologías, cubre todo desde el BE al FE. 
Digamos que es un todoterreno y, hoy por hoy, casi el requisito para trabajar como desarrollador. Si bien se pide que sea apto para todo, no se pide que sea especialista en todo. Con manejar una de las tecnologías a fondo y saber de las demás suele estar bien.

Entonces...en Automation Testing, ¿a qué podemos llamar Full Stack? Como sabrán, Automation Testing puede y debe ocurrir en dos capas principalmente: UI y API. Esto es, en cierta manera, análogo al BE y FE en el que el Dev tiene que ser Full Stack. Entonces, para ser un Full Stack Automation Tester, podemos decir que es necesario que sea capaz de realizar automatizaciones tanto en la capa de UI como en la de API, con sus WebServices y diferentes implicaciones. 
Para esto va a necesitar, igual que el Dev, conocer las herramientas que van a permitirle trabajar en ambas capas y poder decidir cuál y cuándo usarlas, como así también decidir qué tipo de Test (¿integración o UI?) va a ser el más indicado para lo que se quiere probar.

¿Por qué ser un Full Stack Automation Tester?

Algo que veo muy a menudo en los testers que quieren aprender Automation es "si, quiero hacer automation así que tengo que aprender Selenium". Es como la cara más visible y, a pesar de todo e irónicamente como les comentaba, no lo que más debería ser automatizado. Cuando se quiere aprender a automatizar se deben considerar ambas capas: API y UI. Siempre que se pueda, apuntar a la API y en menor medida cubrir algunas cosas en UI.

Hace poco me vi envuelto, por esas cosas de la vida, en la parte de recruiting de una empresa. Soy uno de los filtros para candidatos a Ingenieros en Testing. Entre las cosas que se evalúan, está realizar un par de pruebas automatizadas sobre un WebServices. Se sorprenderían de la cantidad de gente que se auto proclama "Automation Tester" y no tiene idea de cómo automatizar WebServices, dado que solo aprendieron Selenium y ahí quedaron.

Mientras estás en tus primeros pasos hacia el mundo de las pruebas automatizadas, podés empezar por uno o el otro. Pero mi recomendación es que ni bien tengas bien aprendido ya sea el automatizar UI o API, vayas al otro para aprenderlo de la misma manera. No conozco proyecto (que haya terminado bien) que solo haya hecho UI para su automatización. Siempre, pero siempre, va a ser requerido automatizar API en un proyecto serio. Y es una cosa que muchos, al iniciarse con Selenium, sienten raro y no manejan con la misma soltura.

Algo que me recordó hablarles del Full Stack Automation Tester fue una de las charlas en TestBash. Ahí se mencionaba realizar chequeos targeted. Esto es...probando específicamente una cosa en cada check. El ejemplo, como cuento en el video, era el de un Login. Entonces se probaba el renderizado de la página pidiendo credenciales a través de la UI, pero ya la siguiente acción, que es enviar el form con usuario y contraseña con un POST Request se hacía en la capa de WebServices. Se validaba la respuesta, el código HTTP y los headers recibidos y ahí tenían otro check. Finalmente, otra validación en UI se encargaba de verificar que la landing page renderizaba bien y se presentaba al usuario como dios manda si la autenticación era exitosa.

Dicho ésto, les recuerdo que en la sección Tutoriales tienen frameworks para API, con todo lo necesario para enviar requests, validar las responses y mucho más, así que no hay excusa para no aprender!



Publicar un comentario

3 Comentarios

  1. Muy bueno el enfoque y mucha claridad en los conceptos. Muchas gracias!

    ResponderBorrar
  2. Cuánto camino tengo por delante, pero voy paso a paso, esto sí es aprender Automation de verdad!

    ResponderBorrar