Son las 8:00 a.m. Me conecto a la sala de trabajo y doy los buenos días. La primera respuesta que obtengo es: “¿Qué está fallando?” Pienso: “Ni los buenos días puede dar uno”. Mi nombre es Ángel y esto es el día a día de un QA.

Ser Quality Assurance es mucho más que testear, que comprobar qué funciona y qué no. Porque… sí, eso podría hacerlo cualquiera. Hoy quiero contarte todo el trabajo que hacemos y cómo aportamos valor a los proyectos; porque no solo detectamos los errores, si no que encontramos su causa y proponemos una solución. Pero mejor te cuento esto más detalladamente y con algún ejemplo.

¿En qué consiste el trabajo de un QA?

A menudo se nos confunde con el rol del tester, pero nuestro enfoque es muy diferente. Estos perfiles se centran en el producto para detectar defectos y corregirlos, y no tanto en el proceso.
Como Quality Assurance nos aseguramos de que el producto responda a las necesidades del usuario final garantizando su calidad en cada una de las fases.

Y esto no consiste en pulsar botones al azar (como puede pensar alguien que no conozca nuestro trabajo), sino que nos involucramos en los proyectos de principio a fin, desde el momento en que un cliente solicita una solución hasta que la hacemos realidad. Vamos a verlo.

Participamos en la definición del producto

Nuestra participación comienza integrándonos con el scrum team en la fase de inception, para entender bien el proyecto y ver qué estrategia podemos seguir. Después decidimos los acuerdos de trabajo, cómo vamos a trabajar y velamos para que se cumpla en todo el proceso. Empezamos con la visión del producto y el product backlog.

Son dos de los cinco artefactos (tranqui, que no corremos peligro) que componen la metodología scrum y que nos guían para que la información clave sea totalmente transparente y clara para todos. Así, podremos establecer el enfoque con el que mediremos todo el progreso.

• Visión: detallamos minuciosamente las características y el objetivo del producto, las necesidades del usuario y las metas de negocio. Es la base para desarrollar la primera versión del backlog.
• Product backlog: es una lista de todo lo que haremos en el proyecto. La ordenamos por prioridades teniendo en cuenta las necesidades del cliente para tener una perspectiva de todo lo que se requiere.

Establecemos una estrategia de pruebas

Es una de las partes más importantes y a la que muchos equipos QA no dedican el tiempo que merece. 
¡Craso error! Una estrategia de pruebas bien diseñada nos ayudará a tener claros desde el principio aspectos como los siguientes:

• Niveles y tipos de pruebas que vamos a realizar.
• Módulos, componentes y funcionalidades de las pruebas.
• Partes que no entran en la ejecución del proyecto.
• Riesgos y acciones para mitigarlos.
• Aseguramiento de la calidad.

Es importante tanto planificar la estrategia como revisarla. Los acuerdos de pruebas, primeramente los decidimos también con el Product Owner para que sepa cuáles y por qué vamos a realizar. Esto nos permite analizar cuál es el contexto, en qué hemos avanzado, dónde nos hemos detenido y a dónde queremos llegar. 

¿Por dónde empezamos? Primero definimos y planificamos cada una de las pruebas en función de la tecnología, estado, criticidad y urgencia. Como QA, diseñamos el entorno donde se realizarán. El reto está en adecuarlo para que los Developers trabajen con datos reales que aún no influyan en la parte de producción. 
 
Después examinamos los requerimientos implantados por el Product Owner mediante pruebas funcionales para comprobar que el sistema se esté comportando correctamente. Y más tarde realizamos las pruebas no funcionales, relacionadas con características que no se especifican en los requisitos pero igual de importantes, como la usabilidad, rendimiento o compatibilidad. Debemos hacer un seguimiento y monitorización durante todo el proceso para encontrar defectos en fases tempranas y eliminar inconsistencias.

Proponemos soluciones

Más de una vez hemos encontrado un defecto echando raíces en un backlog porque nadie sabía reproducirlo ni solventarlo. En cuanto nuestro radar QA los detecta, los analizamos y estudiamos para ofrecer una la solución a los Developers y puedan resolverlos. Después verificamos y validamos su corrección. 
Como responsables del control de calidad en todas las fases, nos encargamos de:

• Revisar las especificaciones del producto para predecir futuros errores. 
• Plantear soluciones y proponer mejoras asegurándonos de que el producto responda a las necesidades del cliente. 

 Además de estas funciones principales, nuestro día a día incluye otras muchas tareas. Por ejemplo, desarrollamos automatizaciones de test para la comprobación de funcionalidades. Y por otro lado, generamos reportes de los test plan para informar al cliente de qué pruebas se han pasado, qué fallos hemos encontrado, qué errores hemos solucionado, etc. 

Como verás, siempre estamos presentes, independientemente de la fase en que se encuentre el proyecto. En el siguiente apartado te cuento cómo trabajamos durante el desarrollo de un producto para que te metas de lleno en nuestras daily tasks, así contextualizarás todas estas funciones mucho mejor.

¿Cómo interviene el rol QA en el desarrollo de un proyecto?

Como cualquier equipo que trabaja con las metodologías ágiles, organizamos nuestras tareas en sprints, ya sabes, cada uno de los ciclos que vamos a tener en un proyecto scrum. Aquí es donde las ideas se convierten en valor, donde QA, Developers, Product Owner y cliente nos reunimos para determinar qué solución se va a aplicar y cómo. Vamos a ver paso a paso cuál es la misión QA en cada etapa.

Historias de usuario y criterios de aceptación

Junto al Scrum Master, revisamos que las historias de usuario estén bien redactadas. Esto nos ayudarán a especificar los requerimientos del Product Owner. Son tarjetas con frases sencillas que describen una necesidad concreta del usuario y para qué utilizará el producto. Por ejemplo, “Yo, como usuario, quiero que el asistente me pida la fecha de expiración de mi tarjeta para poder seguir validando mi reserva”.

En el reverso están los criterios de aceptación, los cuales validamos y donde se detalla cómo debe comportarse la solución para que una acción se pueda llevar a cabo. Siguiendo el caso anterior, serían, por ejemplo: “El asistente solo puede entender el teclado o un mínimo de 3 cifras y un máximo de; o que la combinación de mes y año no puede ser inferior al mes actual".

Si no invertimos en el refinamiento, meteremos historias mal hechas y perderemos muchísimo tiempo. Cuando ya se han establecido los requisitos, los repasamos para comprobar que tanto su objetivo, características y tiempo de implementación estén bien definidos.  Ahora asignamos las tareas y … ¡empezamos!

Test cases y ¿automatización?

Después de desplegar las historias de usuario junto al resto del equipo, las ejecutamos en el entorno QA para probar las funcionalidades aisladas de las demás. Esta fase es crucial para desarrollar productos de calidad y libres de errores. Para ello, escribimos los test cases (casos de prueba). Son las condiciones que determinarán si una característica o comportamiento de la solución es aceptable o no. 

Te lo explico con el ejemplo más clásico, el login: probamos que usuario correcto y contraseña correcta permitan el acceso; que usuario incorrecto y contraseña correcta indique error; y que usuario correcto y contraseña incorrecta tampoco funcione. Así clasificamos cada caso de prueba en su estado correspondiente: pasado (correcto), fallado (erróneo) o bloqueado (cuando un test case bloquea las funciones del siguiente).

Pero la eterna duda del QA es: ¿escribimos los test cases a mano o los automatizamos simulando lo que haría el usuario final? A menudo se piensa que los manuales nos sacarán más rápido del apuro. Pero estos test habrán de repetirse varias veces y si se hacen de forma manual al final se habrá perdido mucho más tiempo. Por eso siempre hay que automatizar, porque, aunque requiera ingentes dosis de paciencia, la automatización nos garantiza:

• Llegar a resultados más fiables y eficientes. 
• Mejorar el rendimiento del sistema.
• Estimaciones más fiables y efectivas.
• Y, lo que tenemos que meternos en la cabeza: Menos tiempo para escribir y ejecutar los casos de prueba.

Un momento crucial: la demo

Una parte esencial de cada sprint es cuando se muestra la demo al cliente. Para garantizar que todo está correcto antes de ese momento, ejecutamos los test de regresión. Esta es una de las piezas esenciales de nuestro trabajo, puesto que garantiza que el producto funcione correctamente después de cualquier cambio en el sistema.

Pero también es una de las tareas más temidas, porque si algo antes iba como la seda, ahora fallará por todos lados, incluso cuando aún no ha sufrido cambios. Esto ocurre cuando no categorizamos los errores en función de su causa, y no podemos saber cuáles derivan de una regresión y cuáles vienen de antes.

Aquí es donde suele darse una de las situaciones más recurrentes, esas frases que dan para meme: "Pues en mi local funciona". Pero está visto que no siempre funciona…

¿Por qué necesitas un QA?

Ahora que te he contado todo esto, ya debes saber por qué necesitas un QA. Pero, por si aún tienes dudas, voy a darte tres razones de peso que te ayudarán a decidirte, porque en ellas reside nuestro verdadero valor:

• Ponemos el foco en la prevención de errores y no en su corrección. Tenemos la habilidad de ir un paso por delante prediciendo posibles fallos y ahorrando tiempo y trabajo desde el principio. Esta es la clave. 
• Al ser partícipes durante todo el proceso, nos relacionamos con todas las personas involucradas. Así sabemos de primera mano qué dificultades están surgiendo y podemos evitar errores que no resultan tan evidentes para otros perfiles. 
• Garantizamos la calidad del producto y el cumplimiento de los requisitos en todas sus fases, impidiendo retrasos en las entregas, sobrecostes económicos y el descontento del cliente.

En eºmergya el 100% del equipo Quality Assurance está formado por profesionales con conocimientos técnicos. Aunque parece evidente, esto no ocurre en todas las empresas. En efecto, hay dos perfiles QA: funcionales y técnicos. Un rol QA funcional está orientado a la ejecución de pruebas, pero es incapaz de reconocer el origen de los fallos. 

Por su parte, el perfil QA técnico tiene la habilidad de ir más allá de lo que se aprecia a simple vista. Y este es el tipo de perfil que compone nuestro equipo. Por eso:

• Prevemos situaciones de forma que evitamos errores.
• Proponemos soluciones al instante, ahorrando tiempo y garantizando la calidad del producto.

Espero que toda esta información haya aclarado tus dudas sobre los equipos Quality Assurance. Seguro que ahora no escatimarás en perfiles QA para tu proyecto –y si es técnico mucho mejor–. Obtendrás una solución de calidad y tu producto multiplicará su valor.