Te va a interesar!

6/recent/ticker-posts

Automation: UI vs WebServices



Debate: mitos y verdades sobre la automatización de servicios y la UI

Hoy les quiero hablar de la teoría de cómo y qué se debe automatizar vs qué pasa en la realidad.

Estoy seguro que más de uno de uds habrá visto la famosa pirámide de Automation, como así también el cono de helado frutal de Automation. Que no? Bueno, se los presento!




Esto es una representación de la teoría de lo que debería ser automatizado, representada por la pirámide, y la realidad de lo que se hace usualmente en la forma del cono de helado frutal.

Como notarán, la automatización del front end, alias la GUI o UI, es lo que menos foco debería tener. Hay buenos motivos para ésto:
  • La interfaz generalmente no es muy estable en un ambiente de pruebas 
  • Los locators cambian a menudo 
  • La performance es dispar 

Lo que ven en el medio, los tests de Integration, son lo que debería ser el verdadero foco de un Automation Engineer. Y me imagino a varios de uds preguntándose qué son esos test de integración o si el concepto que tienen es el mismo del que voy a hablar. Para eso les voy a pasar a contar a qué nos referimos con este tipo de tests.

Integration Tests: con qué se comen?

Los tests de integración son aquellos en los cuales se prueba cómo dos componentes de un sistema interactúan, sin necesariamente estar probando el sistema en su totalidad.

Digamos que tengo un proxy que se comunica con un directorio para validar que un usuario tiene X valor en uno de sus campos. Desde la UI, esto pasa detrás de escena al momento de enviar nuestras credenciales en el login. Durante el desarrollo, posiblemente el login esté roto o directamente ni exista para probarlo, por lo que una buena manera de adelantarse es hacer tests de integración a través de un Test Harness (más de ésto en particular en otro post!) que solamente pruebe la comunicación entre el proxy y el directorio. Para ésto usualmente vamos a necesitar saber qué protocolo se usa para la comunicación y crear el código acorde a ésto, inyectando por ejemplo las credenciales para la autenticación y una query para buscar y validar lo que necesitamos del directorio.

Son un tipo de tests muy diferentes a lo que es Selenium, donde vamos a estar enviando requests o mensajes y validando la respuesta sin tocar la UI. Pueden ponerse muy técnicos, como el caso que les mencioné del proxy y el directorio, que puede estar usando LDAPS u otros protocolos.

Entre lo más común y menos técnico que van a encontrar, se encuentran las API públicas que tengan disponibles para testear en su aplicación. Para ésto vamos a usar herramientas bien conocidas como la librería Rest Assured, RestSharp, como así también SOAPUI y otros. Acá el panorama va a ser más sencillo, en mi opinión, que automatizar la UI.

Y POR QUE ES PREFERIBLE TESTEAR EN LA CAPA DE SERVICIOS SI EL TEST SE SUPONE QUE TIENE QUE VALIDAR A UN USUARIO?

Pregunta espinosa si las hay! Y con muchas posiciones diferentes...En mi opinión, la lógica detrás de que sea preferible testear en la capa de servicios es que es mucho menos proclive a romperse ante cambios que la UI. Además de probar lo que hace realmente la UI debajo del telón. También les recuerdo que no se habla de eliminar completamente el testeo de la UI con Automation, sino más bien de reducirlo al mínimo indispensable o aceptable para el nivel de cobertura que se desea.

El mantenimiento en los tests de integración es mucho menos costoso que el de la capa UI, lo que también hace a la larga que el retorno de la inversión sea mejor y la deuda técnica baje.

POR QUE TODAS LAS BUSQUEDAS LABORALES PIDEN SELENIUM Y NI MENCIONAN REST ASSURED, SOAPUI O EL TEST DE INTEGRACION?

Puede haber muchos motivos, entre ellos los siguientes:
La aplicación a testear no tiene las API públicas para que los testers las usen por un tema de seguridad o simplemente porque el equipo de desarrollo es de una compañía tercera que no les gusta compartir ese tipo de cosas (son los peores esos...).
Escucharon por ahí que Selenium es lo que se usa para automatizar y en eso se quedaron, sin considerarlo en profundidad.
Por algún extraño motivo ajeno a mi se quieren enfocar completamente en testear la UI y vivir manteniendo scripts de automation para, eventualmente, fracasar miserablemente al ya no estar entregando valor agregado sino deuda técnica y rework.

Dicho todo ésto, les dejo un par de reflexiones. Siempre que tengo un proyecto nuevo pienso lo siguiente:
"Estoy testeando ésto A TRAVES de la UI o estoy testeando la UI?"

Si es a través...debería hacerlo a nivel servicio. Si es la UI en si misma que estoy testeando, está bien usar Selenium o la herramienta de automatización de navegadores de su preferencia.

The Free Range Tester

Publicar un comentario

2 Comentarios

  1. Excelente, quedo con ganas de saber mucho más

    ResponderBorrar
    Respuestas
    1. Te recomiendo ir a los posts sobre API y otros linkeados en este mismo post donde desarrollo temas relacionados!

      Borrar