Quality Assurance

¿Ser QA Manual o QA Automatizador?

He allí el dilema…

Testing de Software

A menudo los testers manuales piensan para sus dentros que pasar a ser automatizadores es una pérdida de tiempo, que programar conlleva mucho esfuerzo, que entender lo que hacen los programadores no tiene sentido porque siempre hay errores entonces debe ser muy complicado o carecer de sentido dado que uno ya está acostumbrado a testear esto o aquello, que es siempre igual y se acostumbra a la rutina.

La respuesta es que tienen razón, es un garrón aprender automatización cuando no se tiene la menor idea de nada, hay muchísimos lenguajes de programación allí fuera e infinita cantidad de tecnología para probar y utilizar. No sólo eso, sino que a fin de cuentas, hay un alto grado de prueba y error que conlleva aprender a automatizar que no necesariamente existe en el mundo del desarrollo de software. Pero aún así, vale la pena. Es una cuestión de energía, uno puede testear manualmente las cosas y acostumbrarse a hacerlo en una rutina, pero a la larga se agota y ahí la decisión es o pasar a Leader y aburrirse para siempre en reuniones y hacer muy poco, o trabajar de otra cosa.

Los invito a que aprendan a programar por la simple razón de que programar una vez se adquieren los conocimientos básicos es mil veces más divertido que testear manualmente algo y si además uno pasa a ser automatizador, podrá aplicar sus conocimientos de testing en los scripts que realice para garantizar la efectividad de las pruebas, lo que hace de este camino, Manual a Automation, el camino preferido de los reclutadores de personal para seleccionar nuevos automatizadores dado que los desarrolladores, como bien sabemos todos, olvidan muchas veces los conceptos básicos de usabilidad que debe tener el software y por lo tanto sus pruebas suelen omitir varios casos de uso quizas fuera de la lógica de software pero muy dentro de la lógica del usuario que vale la pena preveer 100%.

Los blogs o videos sobre automatización están en google y varían todo el tiempo. De acuerdo a la tecnología que deseen utilizar, las actualizaciones del Stack que utilicen será constante a lo largo de sus vidas por lo que no sirve de mucho dejar referencias. Esa información va a estar siempre en Internet (eso parece, al menos).

Las buenas prácticas, sin embargo, no. Son pequeños tips que son difíciles de adquirir porque al intentar hacer automatización hay muchas maneras distintas de hacerlo y encarar el proyecto.

La verdad sigue siendo la misma en todo el mundo: hay gente más inteligente que otra. Por lo que hay patrones de diseño estándar que podemos aplicar, pero hay proyectos que sólo pueden admitir no sólo a un Ingeniero de Software recibido para encarar el trabajo, sino además un tipo de un alto coeficiente intelectual.

Por esta razón, no se desanimen nunca si no los eligen para determinados proyectos y una vez entiendan de estas cosas, sabrán a qué postularse y a qué no.

En los tutoriales allí afuera, verán ejemplos de selenium webdriver o appium por ejemplo, herramientas con las que yo trabajo diariamente, que al seguirlos les permitirán correr un ejemplo en sus locales. Pero… ¿después qué? ¿Cómo sigue el asunto?

Yo programo hace años con Java, por lo que uso un lenguaje orientados a objetos. Esto significa, que todo mi trabajo de código estará desarrollado en «Objetos» que en su totalidad y por cómo se relacionan entre sí, constituirán mi Framework.

El patrón de diseño Page Object es el patrón más común para encarar un framework que interactúe con una página web o una app mobile. Básicamente, propone agrupar nuestro Framework en 3 carpetas base y de ahí customizar lo que querramos, obviamente, de tal forma que en una guardemos los page object, en otra los test object y en otra los resources (casi todo lo demás).

Page Object

Siguiendo la tradición, los page object son clases, una por archivo, que representarán una página o vista de la aplicación a testear, a veces incluso un sólo módulo o sección, que tendrá declaradas en variables los elementos interactuables de la página, asignándole una manera de interactuar con él. Luego de desglosar en variables todos los elementos, se pasa a los métodos, es decir, las funciones que interactuarán con los elementos del page object.

Test Object

Siguiendo a los gurús, los test object son clases, que engloban varios tests (métodos de tipo test) representando cada uno de tus casos de prueba, por lo que una clase puede tener 1 a 10 o 30 tests, dependiendo como organices tu framework. Aquí se desarrollarán los tests, o métodos de tipo Test, que iniciaran el navegador o la app y correrán correctamente desglosados todos los tests de acuerdo a la ejecución.

Resources Object

Aquí irán todas las librerías o helpers que necesitemos, incluidos las clases de configuración que nos permitirán interactuar con el proceso automático de la librería que estemos utilizando, ya sea Cucumber, TestNG, Mocha, Protractor, o el que sea, y tomar decisiones de lógica interna para la ejecución.

Lo ideal en programación es no acumular mucho código en ningún archivo, para que después no sea ilegible para otros o para uno mismo, así que es conveniente desglosar el esfuerzo de automatizacion en dos ópticas distintas: desde la visión del testing (Test Suite, Test Type, Test Cases Parent Group, Test case) y la programática (Test Class Group, Page Class Group, Resources Class Group). Mientras que en el primer grupo estaríamos hablando en lenguaje de testing, ejemplo: «Test Suite Sección Marketing, Regression Test, Barra de búsqueda, Tests», en el segundo estaríamos hablando de lenguaje de programación, si tiene mucha complejidad o código para testear, ejemplo: «Clases de Test de la Barra de búsqueda, Clases de Página de la Barra de búsqueda, Clases de Recursos, por ejemplo, funciones para esperar visibilidad o funcionalidad antes de continuar pero sólo de una sección específica, o funciones genéricas para interactuar con Android y no con iOS. Siendo este segundo grupo una necesidad a tener en cuenta si la aplicación es grande o seguirá creciendo. Es importante aclarar, tanto en desarrollo como en automatización de pruebas, los frameworks deben estar diseñados para aceptar todo tipo de crecimiento y flexibilidad, de hecho, son cada vez más las tendencias a trabajar en términos de ir hacia adelante y hacia atrás, por lo que un buen sistema para deprecar y restaurar objetos es recomendable de tener anticipado en la mente una vez arrancado a trabajar.

Otra cosa útil en programación es comentar brevemente qué hace cada método que se escribe y describir cualquier detalle que pueda ser conveniente tener a mano, sin embargo, es mala práctica dejar datos de prueba, credenciales o cualquier otra información sensible dentro del código. Para este tipo de cosas, se suele abstraer la lógica para que en 1 solo archivo cada uno pueda poner sus datos y credenciales de manera local y nunca alterar con esto nada que esté en el repositorio, que no debe tener nunca datos de prueba o credenciales de ninguno de los testers.

Otro tip es hacer que cada nombre de método o clase cuente y sea descriptivo por sí mismo, así como lo más corto posible, cuestión de que cualquier colaborador sólo tenga que gastar unos segundos de su tiempo en comprender qué hace esa clase y qué hace ese método una vez ya entienda los estándares de la lógica del Framework.

Otro tip es también es mantener toda la información posible en el Readme del proyecto, como si se tratara de una libreria de software, puesto que lo es, así esta información no se pierde con el tiempo.

Otro tip es armarse dos proyectos al iniciar uno, y dejar uno para correr pruebas, donde probar implementaciones de cosas que uno no conoce hasta hacerlas funcionar correctamente en un caso sencillo antes de empezar a trabajar con el proyecto en sí, a menudo las librerias o helpers de herramientas de automatizacion, o extensiones, suelen tener poca información y lleva mucho tiempo descubrir si son una buena elección para nuestro proyecto o no si intentamos directamente aplicarlo antes de conocerlo en su totalidad.

ScreenPlay

La ventaja de este patrón es que ofrece una manera sencilla de tratar la abstracción del tipo de usuario que utiliza la aplicación cuando la misma posee muchos tipos distintos, llamándolos «actors», que tienen reglas distintas dentro de la misma, además que acierta en la abstracción de las llamadas «acciones» dado que en el testing automatizado los tests suelen realizar dos tipos de acciones «assertions» (true/false) o «interactions» (click, scroll, swipe, etc…) pero ambas cosas pueden aplicarse a un framework page object y se dará también de forma natural a medida que vaya pasando el tiempo.

El framework Serenity, permite interactuar con el modelo Cucumber, es decir, con casos de prueba en formato Gherkin. Utiliza este patrón de diseño y si bien es popular por cómo resuelve toda la estructura, algunas librerías o dependencias están medio desactualizadas y puede traer problemas, quizás, lo mejor, es implementarlo de cero sin utilizar Serenity de ser posible.