La automatización de pruebas es la creación de un proceso automático que se encarga de realizar un conjunto de acciones controladas contra el software a probar con el fin de determinar si el funcionamiento del elemento probado se ajusta o no a lo esperado.
En el mercado existen diferentes frameworks y herramientas que simplifican el proceso de definición y ejecución de pruebas automáticas. Para nuestro ejemplo utilizaremos Katalon Studio (en su versión 8.1.0 Build 208).
Nuestro objetivo en este ejemplo es implementar la automatización de las pruebas de un formulario de login estándar de una página Web. El objetivo es comprobar que cuando se introducen unas credenciales correctas, la web me devolverá un mensajes adecuado, mientras que cuando se utilizan credenciales incorrectas, recibamos un mensaje de error.
Para la ejecución automática de las pruebas es necesario poder interactuar con los diferentes elementos de la página web. Para que Katalon pueda interactuar con estos elementos, el primer paso es “capturarlos”, por lo que haremos uso de la funcionalidad SPY Web para este fin:
Una vez activada esta funcionalidad, veamos cual es el proceso para capturar el botón “login” del formulario. Para esto, haremos clic con el botón derecho sobre el botón y seleccionaremos la opción “Capture Object”.
Katalon utiliza este proceso para intentar identificar de forma univoca al elemento seleccionado, pero esto no es un proceso directo, requiere de nuestra interacción para selecciona un mecanismo de identificación adecuado (seleccionar un “Locator”) y confirmar que dicho identificador no está siendo utilizado en alguna otra parte de la página (utilizando la opción “Verify and Highlight”). En este ejemplo, guardaremos la referencia al botón identificado con el nombre “button_login”.
Repetiremos este proceso para el resto de elementos de la página con los que vamos a interactuar durante las pruebas: Username, Password y el mensaje de respuesta de login.
Gherkin es un “pseudo-lenguaje” que nos permite hacer una definición de casos de prueba de forma sencilla y centrada en la parte funcional de dicha prueba, abstrayéndonos de las cuestiones técnicas subyacentes. Este lenguaje permite poner en práctica el BDD o Behavior Driven Development, es decir, definir el funcionamiento de un sistema en base al comportamiento esperado para el mismo.
Cada una de las pruebas particulares que se definen en Gherkin se llaman Scenario, los cuales se agrupan en Features. Para nuestro ejemplo, crearemos una nueva Feature llamada “Login.feature” dentro de “Include/features/” e incluiremos un Scenario con las pruebas que queremos realizar (en la práctica, una Feature es un fichero de texto en el que vamos a ir incluyendo diferentes Scenarios).
Aunque el objetivo de este artículo no es explicar la sintaxis de Gherkin, vamos a revisar la definición del Scenario del ejemplo para así entender mejor el objetivo de las pruebas.
En la nueva Feature se ha introducido un Scenario “parametrizado” (Scenario Outline) denominado “Login validations”. Los Scenarios se componen de varios pasos, denominados Steps, en este caso con el siguiente significado:
Un Scenario Outline se ejecuta tantas veces como conjuntos de valores se han definido en el apartado Examples asociado. En el ejemplo, tenemos dos conjuntos de parámetros, el primero asociado a un proceso de login correcto y el segundo a un proceso de login incorrecto.
Como podrás ver, cada uno de los parámetro identificados anteriormente (títulos de las columnas) tiene un valor asociado para cada ejecución.
Una vez definidos los Scenarios y sus Steps, debemos codificar la prueba a través de los Step definitions. El proceso es el siguiente:
Crearemos una Step Definition llamada “LoginStepDefinition” dentro del Package creado anteriormente (una Step Definition es una clase de tipo Groovy que utiliza Katalon para implementar las pruebas con JAVA) y seleccionaremos que nos autogenere el “esqueleto” del contenido del fichero (samples).
Llegados a este punto tenemos identificados los elementos con los que vamos a interactuar, hemos definido las pruebas que queremos ejecutar y hemos preparado el código necesario para “unir” ambos elementos, es decir, conseguiremos que la acción definida en la prueba se aplique sobre los elementos identificados de la página a probar.
El siguiente paso es dar estructura a la ejecución de las pruebas. En Katalon existen 2 niveles jerárquicos de agrupación:
Con estos elementos tenemos una gran flexibilidad a la hora de generar y ejecutar diferentes planes de pruebas en función de las necesidades particulares de cada momento.
Para este ejemplo, crearemos un Test Case llamado “LoginRunner” asociado a la Feature creada anteriormente.
Posteriormente, asociaremos este Test Case a una Test Suite llamada “Regression”.
Ya está todo preparado para ejecutar nuestras pruebas automáticas. Podemos ejecutar la prueba desde la Test Suite y el resultado será el siguiente:
Como puede ver en el video, Katalon se encarga de ir recorriendo los Steps definidos, ejecutando su código asociado y comprobando los resultados. Para esto, hace uso de un navegador para poder simular el proceso como si se tratase de un usuario real. Una vez termina la ejecución, también se puede configurar que Katalon suba a Azure Devops los resultados de la misma.
El mejor asesoramiento en modernización de aplicaciones para resolver los desafíos de transformación a los que se enfrenta tu negocio.
El mejor asesoramiento en modernización de aplicaciones para resolver los desafíos de transformación a los que se enfrenta tu negocio.
