¿Qué hace un QA? Con palabras frikis
“Tres entregados para los Reyes Clientes bajo el cielo. Siete para los Señores de Sistemas en palacios de normas. Nueve para los Desarrolladores Mortales condenados a picar código. Uno para el Señor PO, sobre el trono oscuro en la Tierra de Commitlandia donde se extienden las líneas de código. Una Planning para gobernarlos a todos. Una Planning para encontrarlos, una Planning para atraerlos a todos y atarlos en las tinieblas en la Tierra de Commitlandia donde se extienden los bugs.”
Así comienza la trilogía y aventura de nuestro protagonista, el QA, que se ve inmerso en una aventura, firmada en contrato por un viejo ser mágico que todo lo puede (pero ya hablaremos de RRHH en otro momento…) y que le llevará a replantearse ideas como la de abandonar su feliz y simple hogar de las pruebas manuales para adentrarse en un mundo lleno de seres monstruosos y extraños, como los Dragoflcitos, serpientes aladas que consumen y vuelve locos a los Desarrolladores Mortales. “Ella” la UX, con sus telarapixeles que te atrapan en el pixelperfect sin posibilidad de escapar. El reino siempre en conflicto de Las Ramas que colinda con la oscura tierra de Commitlandia…. o los susurros de algo aún peor….algo que se escucha al final de la cueva y sale a la superficie en forma de susurro escalofriante….”en mi local funcionaba”….Vale, perdón por la introducción pasada de rosca, pongámonos serios. No voy a contaros de manera técnica las funciones de un QA, ni las herramientas y casos concretos sobre tipos de pruebas, automatizaciones etc. No, hoy vamos a hablar de algo mucho más sencillo, la mera experiencia y punto de vista de este ser incomprendido llamado Quality Assurance (odio éste apellido, que conste).
Como QA, parte de mis funciones es la de asegurarme que cada pequeño desarrollo que se genere, esté lo más libre posible de bugs o de incongruencias (o básicamente, “aquello que no cumpla con la necesidad y requisitos del cliente”). Digo posible, porque como ser humano que soy, a todos se nos pueden escapar algunos detallitos sin importancia (Troya también fue conquistada “insert your excuse here”), que terminen pasando como “HU100 –Bugs_Demo” CORREGIR. Bien, pero ¿a qué te enfrentas cuando hay desarrollos que revisar? Bueno, en primer lugar, hay que tener claro que nada de lo llegue a tus manos va a estar libre de una revisión milimétrica, como, por ejemplo, una simple interfaz gráfica. Incluso aunque sea una pantalla rancia sin colores ni vida con datos mockeados en los que, al pulsar sobre ellos, nos llevan al mundo de fantasía de los 500, los “no data found” y un largo etcétera que personalmente, me saca de quicio (¡leches, si está ahí y pulso sobre él, QUIERO QUE ME ENSEÑE ALGO CON SENTIDO! Respira…respira). ¿Por qué? Por poner un ejemplo rapidísimo con la Interfaz: ”ELLA” siempre teje su red de una manera perfecta a la vista y no va a permitir que exista un hilillo descolgado. Dicho de otra manera, la interfaz también es importantísima, dado que es la cara visible normalmente, y con lo que se va a trabajar día tras día, por lo que un simple título, un marco con demasiado poco, o demasiado mucho espaciado, o incluso un botón algo “feucho” puede tirar por tierra un código perfectamente estructurado y con una lógica de negocio implementada a la perfección (¡UTOPÍA!).
Y seamos sinceros, tiene sentido el “echar atrás” un desarrollo en el que se ve una interfaz con faltas de ortografía, títulos “Con MaS CamBiOs de ForMA” que el Estado del Messenger (benditos recuerdos) o unos espaciados demasiado grandesodemasiadopequeños.
¿Qué hace un QA? Explicado de forma seria.
Cuando hay que definir cuál es el rol de QA en un equipo, me suelo encontrar con las siguientes preguntas: ¿Qué significa QA?, ¿Cuál es el objetivo de un QA?, ¿Qué hace exactamente? Pues voy a intentar explicarlo desde mi experiencia.
- ¿Qué significa?
El significado literal de QA, aunque también dependiendo de las necesidades de la empresa o del proyecto, nos lo podemos encontrar con las siguientes definiciones: Software Tester, Tester Engineer, Quality Control Engineer, Quality Assurance Engineer, Quality Analyst…
En mi caso, dado que trabajo con un equipo de desarrollo de software que trabaja con metodologías ágiles, prefiero llamarlo Quality Assurance.
- El objetivo como parte del equipo.
Uno de los doce principios del Manifiesto Ágil dice: “Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor”.
Partiendo de este principio yo diría que entre los objetivos de un Quality Assurance como parte del equipo de desarrollo son los siguientes:
- Fomentar entre los equipos la revisión y las pruebas de forma continua
- Ayudar a prevenir los defectos compartiendo, por ejemplo, los problemas localizados más comunes
- Fomentar la coordinación para alcanzar los objetivos en las entregas de una manera más ágil y así involucrar a los equipos en el control de calidad de los desarrollos realizados
Cuando el equipo está completamente involucrado en estas prácticas, podemos decir que “la calidad es responsabilidad de todos”, y, ¿por qué digo “la calidad es responsabilidad de todos”? Bueno, de nada sirve realizar desarrollos rápidos, ganando tiempo en las primeras fases, si en los últimos pasos, y antes de la entrega, tenemos que estar volviendo atrás para corregir defectos y errores.
- Entonces, ¿Cuál es la función concreta?
Como QA muchas veces el trabajo va un poco más allá de lo “esperado”, y toca jugar como un pequeño comodín que puede y debe ayudar al equipo en todas las funciones posibles, pues no se trata únicamente de probar y probar.
Las funciones o responsabilidades de un QA las podríamos dividir de la siguiente forma dependiendo de la parte del equipo con los que se trabaje:
Trabajar junto con el Product Owner:
- Mejor comprensión de las necesidades del cliente
- La preparación y revisión de historias/tareas
- La definición de Criterios de Aceptación
- Mejor entendimiento del Área de Negocio
Trabajar junto con los Developers:
- La definición de estrategias de prueba para las historias
- Apoyar en la automatización de pruebas funcionales
- Detectar y notificar bugs
- Entregar el feedback temprano de las historias/tareas
- Sugerir mejoras funcionales y de usabilidad
Por mi parte, como QA trabajo en:
- Preparación de baterías de pruebas para cada desarrollo
- Ejecución de las baterías de pruebas
- Preparación y ejecución de pruebas automatizadas
- Preparación de la estrategia de pruebas del sprint
- Preparación y mantenimiento del Ambiente de Pruebas
- Creación y mantenimiento de datos de prueba
- Validación de “Done” de las Historias en metodologías Agiles
- Registro y notificación de Bugs
Trabajo con otros QAs en:
- Diseñar y preparar las estrategias generales de pruebas
- Identificar los escenarios y flujos de negocio más vitales
- Difundir el Plan de Pruebas, Casos de Pruebas para Integración y los distintos escenarios
- Coordinación del estado de las entregas y pruebas realizadas
- Calidad más allá del Software “Conductas de calidad”
Cuando hablo de Calidad no me refiero solo al software, también es necesaria la calidad en los procesos, en la tecnología y herramientas utilizadas, sin olvidarnos de la calidad en la comunicación y relación entre los miembros del equipo, porque todos estos elementos influyen en el producto final desarrollado.
Cuanto más cuidadosos y cercanos seamos en el proceso de creación y comunicación de un desarrollo, mejor calidad conseguiremos en las entregas finales.
Un punto para tener en cuenta es que normalmente, como bien indican las metodologías Agile, los productos finales suelen tener poco que ver con lo que en un principio se había especificado. Aclararé que esto no es culpa ni del cliente, ni de los equipos de desarrollo, pues es normal e incluso sano que un producto vaya evolucionando a la vez que se va desarrollando. No sólo conseguimos que el cliente tenga un producto mucho mejor adaptado al mercado actual o a la lógica del negocio, sino que además se van corrigiendo y guiando mejoras hacia un producto mucho mejor situado y útil.
A modo de conclusión, quiero hacer hincapié en la importancia que tiene el trato con el equipo, sea cual sea el motivo/momento/problema que se esté atravesando durante el desarrollo. El trato con el equipo siempre va a ayudar en que una situación pueda ir de un punto a otro, tanto en lo bueno como en lo malo.
Como QA, una de las “tareas” que tengo es la de aprovechar mi posición transversal al equipo entero, y ayudar a que todos podamos tener una comunicación fluida y, sobre todo, ayudar a que (y me vais a disculpar la jerga) “el buen rollo” esté siempre presente en todo el equipo, que todos nos sintamos escuchados y valorados. Esto está fuera del rol de QA como tal, pero veo que dado que somos una parte del equipo que está más en contacto directo y constante con todas las partes del grupo, nos es más sencillo mantener este tipo de “conductas de calidad”.