Los primeros pasos de nuestro departamento de QA

En Genially siempre nos hemos preocupado mucho por asegurar la calidad de nuestro producto, es algo clave para nosotros y a la vez una obsesión. Sin embargo, esto no es algo trivial debido, entre otras cosas, al aumento natural de la complejidad de nuestra herramienta (y por ende de nuestro código) causado tanto por el desarrollo de nuevas funcionalidades como a la propia complejidad accidental. Por lo que necesitamos invertir cada vez más tiempo y esfuerzo en asegurar que todo funciona, tanto lo nuevo como lo ya existente.

La necesidad de un equipo de QA

Durante todo nuestro proceso de desarrollo, la definición, implementación y ejecución de tests automáticos es algo natural. Estas pruebas van desde tests unitarios, tests de integración con bases de datos y servicios externos, hasta tests end-to-end (o E2E) que permiten verificar que, por ejemplo, nuestra API responde a una petición específica de forma satisfactoria. Estos tests, en general, nos permiten asegurar la calidad del código que escribimos pero hay ciertos aspectos importantes que no quedan cubiertos, como son aquellos relacionados con la usabilidad, visualización o interacción con el usuario. Que todo funcione desde un punto de vista técnico es solo una pieza más del engranaje.

Al final, para garantizar que nuestro producto funciona tenemos que ser capaces de asegurar que nuestros usuarios tienen éxito. Y esto no es más que garantizar que son capaces de crear, de forma intuitiva y sencilla, distintos tipos de contenido, como presentaciones, infografías o un dossier… ¡entre otros muchos! Que son capaces de hacerlo tanto de forma individual como colaborativa. O que son capaces de publicar y compartir sus creaciones, así como visualizar las creaciones de otros usuarios. Todo tal y como nuestro equipo de producto lo concibe.

Como todo en una startup, al principio esta responsabilidad quedaba repartida entre los distintos miembros del equipo, es decir, formaba parte del propio desarrollo el asegurar tanto la calidad del código desarrollado, como que todo funciona adecuadamente desde el punto de vista del usuario. Sin embargo, este último tipo de pruebas requerían un esfuerzo y conocimiento específico para hacerlo de una manera eficaz, lo que nos llevó a crear un equipo especializado y dedicado exclusivamente a este fin. Concretamente, en Genially se empezó con una persona en el departamento de producto, dedicada en exclusiva a realizar QA manual de las distintas funcionalidades que iban saliendo a producción. A su vez, desde el departamento de tecnología empezamos a hacer una serie de pruebas de concepto que permitían automatizar, en un navegador web, las acciones que nuestros usuarios pueden realizar desde la interfaz de usuario y así saber si todo funcionaba correctamente.

Con todo por hacer… ¿por dónde comenzamos?

Desde que empezamos a definir el departamento de QA teníamos claro que queríamos tener una estrategia de pruebas que nos permitiera tanto el ir cubriendo con pruebas automáticas todos los flujos de usuario críticos, como ir mejorando poco a poco la cobertura de cada componente de la aplicación con tests de regresión, tanto manuales como automáticos. Así podemos verificar en cada despliegue que con cada nueva funcionalidad no se rompe nada de lo que ya teníamos desarrollado y, por tanto, nuestros usuarios no se ven afectados y van a poder seguir trabajando sin ningún tipo de problema.

Con esto en mente, los primeros tests que empezamos a definir tenían que ver con aquellos casos de uso que consideramos más importantes y críticos para garantizar el éxito de nuestros usuarios. Por lo que comenzamos con el registro de un usuario nuevo, el iniciar sesión con un usuario ya existente, el crear un genially en blanco, añadir contenido y comprobar que se visualizaba correctamente, y el crear a partir de una plantilla, añadir contenido y comprobar que se visualizaba correctamente.

Así, poco a poco nuestro equipo ha ido creciendo y evolucionando hasta convertirse en el equipo de QA que tenemos hoy en día, un equipo de cinco personas plenamente dedicado a garantizar la calidad de nuestro producto tanto de forma manual como automática. O dicho de otra manera, a asegurar que nuestro producto funciona.

La elección del framework de pruebas automáticas: Cypress

Una vez decidida nuestra estrategia de testing, lo siguiente que necesitábamos eran las herramientas adecuadas para llevarla a cabo. Para ello necesitábamos conocer en detalle cómo funciona por dentro nuestro producto. Genially es una aplicación escrita en JavaScript y TypeScript con React y Node.js y conformada por distintos componentes donde, en mayor medida, frontend y backend son aplicaciones separadas que se comunican mediante llamadas AJAX.

Teniendo todo esto en cuenta, estuvimos barajando varias opciones como, por ejemplo, TestCafé, Selenium y otros frameworks de pruebas que pudieran ayudarnos a implementar nuestra estrategia de testing automático pero, al final, la herramienta que nos daba una mayor potencia, rapidez y que mejor se adaptaba a nuestro stack de desarrollo y a nuestra aplicación era Cypress.

Cypress es un framework JavaScript creado principalmente para realizar pruebas E2E. Está basado en Mocha, se ejecuta en el navegador y es capaz de realizar pruebas asíncronas.

Como dato curioso, su nombre se basa en el hecho de que el equipo de desarrolladores de Cypress piensa que los tests siempre tienen que funcionar y, por tanto, aparecer en verde. Como el ciprés es el árbol más verde que existe, decidieron llamar así a la herramienta.

Con respecto a otros frameworks de pruebas E2E, Cypress nos proporciona una serie de ventajas:

• Realiza capturas de pantalla en cada uno de los pasos (acciones) que el test va realizando, lo que hace realmente sencillo poder ver todos los pasos que ha realizado el test casi en tiempo real.
• No necesitas definir tiempos implícitos o explícitos para esperar a que un elemento aparezca o para interaccionar con él. Por defecto Cypress ya espera de forma automática en cada uno de sus comandos y aserciones.
• Tiene una excelente documentación además de una API muy completa que también puedes consultar en la propia documentación.
• Los errores se muestran de forma bastante simple y sencilla de ver, tanto la salida del error como el error en sí. Esto, ayudado por las capturas de pantalla, hace que sea muy fácil ver los fallos que hemos tenido y poder arreglarlos o reportarlos (en el caso de que sea un error).
• No necesitas definir un scroll automático, Cypress ya se encarga de hacer un scroll al elemento que necesitas interactuar antes de realizar cualquier operación con él.
• Soporta múltiples navegadores como Chrome, Firefox, Electron o Edge.
• Podemos utilizar spies, stubs y clocks para verificar y controlar el comportamiento de las respuestas de nuestro servidor de forma sencilla.

Pero debemos tener en cuenta que no todo es ideal, Cypress también viene con una serie de desventajas que debemos tener en cuenta:

• No se pueden ejecutar dos o más navegadores a la misma vez.
• No soporta los tests multidominio, es decir, si comienzas tu test en genial.ly, tu prueba debe comenzar y terminar en el mismo dominio.
• Únicamente puedes definir las pruebas utilizando Javascript o Typescript… there’s no place for Java development here…
• No soporta navegadores como Safari o Internet Explorer. Aunque pensemos que no son muy usados, os sorprendería la cantidad de personas que aún siguen utilizándolos.
• Hay un soporte limitado para los iframes, de hecho dan bastante dolor de cabeza cuando intentas acceder o interaccionar con un elemento dentro de ellos.

Creando nuestro proyecto de pruebas

Ya conocemos nuestro producto, la estrategia de pruebas y tenemos elegida la herramienta, así que no nos queda más que empezar a desarrollar las pruebas. Lo primero que hicimos fue realizar las pruebas que ya hemos comentado con anterioridad contra nuestro entorno de desarrollo en local.

¿Qué necesitamos para poder realizar estas pruebas? Primero poder tener ejecutado el entorno local con los últimos cambios que están en producción funcionando. A continuación tenemos que añadir data-cy o atributos propios para testing en cada elemento del DOM para seleccionarlo, de forma sencilla y concreta, y poder interaccionar con él.

Un ejemplo de cómo se verían los data-cy en el código.

¿Por qué necesitamos estos atributos especiales data-cy? Porque hemos visto que seleccionar elementos por tag, clase o id es algo que cambia demasiado a menudo (incluso a la hora de compilar nuestra aplicación, el nombre de cada id o clase puede ser auto-generado) y esto hará que nuestros tests se rompan muy a menudo. Un data-cy no va a cambiar y no tiene ningún efecto en el elemento, ni en el comportamiento ni en el estilo, con lo cual podemos dejarlo en el código sin afectar en nada a la aplicación. Para nosotros cada data-cy muestra de forma clara que es un atributo utilizado por las pruebas automáticas, por lo tanto los desarrolladores no lo borrarán y podremos tenerlo siempre disponible para saber a qué elemento nos estamos refiriendo.

Siguientes pasos

Todo esto ya supuso un primer gran avance para el departamento de QA porque fue el primer paso para poder probar nuestra aplicación de forma automática cada vez que quisiéramos, pero… ¿cuándo ejecutamos estos tests?, ¿solamente los podemos lanzar en local? Para dar respuesta a estas preguntas seguiremos con el siguiente paso: hacer los cambios necesarios para poder lanzar nuestro proyecto en un entorno de integración continua. Pero es algo que os detallaremos en su propio post.