Analistas de calidad ágiles son muchas veces conocidos como analistas de calidad (QAs), ingenieros de software en pruebas, Ingenieros de pruebas, líderes QA, entre otras variaciones. Yo he estado trabajando como un QA ágil por un tiempo y me gustaría compartir mi punto de vista sobre cómo un QA trabaja en un equipo ágil. En este artículo usaré el término QA para hacer referencia a QA ágil.
La mayoría de las personas, incluso en equipo ágiles, tratan a los QAs como un papel secundario o un rol separado del equipo. Yo creo que eso está totalmente fuera de moda. La diferencia entre un QA y un desarrollador (también llamado Dev) es apenas la manera de pensar (ó mindset para los que están acostumbrados con el término).
Pero qué distingue a los QAs entre ellos mismos? Los perfiles de los QAs pueden ser clasificados en 3 categorías: Negocio, Técnico y DevOps. Yo llamo a esos 3 "las 3 dimensiones del perfil de QA". QAs pueden tener tanto uno de esos perfiles como combinarlos de acuerdo al nivel de conocimiento que tienen en cada dimensión.
Vamos a explorar más a fondo para entender mejor cada una de estas 3 dimensiones.
Dimensión de negocio
Los QAs en esta dimensión son realmente orientados a negocio. Ellos tienen habilidades que ayudan a su equipo a entender el contexto del negocio dado por el cliente. Ellos tienen buenas habilidades de comunicación que facilitará al equipo enfocarse en los problemas del negocio durante el proyecto entero.
Extraer pruebas de aceptación del cliente es una de sus especialidades y BDD es una de las técnicas que usan para romper barreras entre el contexto del negocio del lado del cliente y el contexto técnico del lado de los ingenieros.
Ellos trabajan en pares con los desarrolladores para alinear los requerimientos con el cliente antes de comenzar a desarrollar las historias. Durante este período ellos guían a su par para escribir pruebas de aceptación para asegurarse de que la historia está probada antes de ser movida para adelante.
Esos QAs generalmente leen libros como:
Specification by Example: How Successful Teams Deliver the Right Software
Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
The Cucumber Book: Behaviour Driven-Development for Testers and Developers
Dimensión técnica
Yo me identifico con esta dimensión porque los QAs aquí son bastante técnicos y tienen buenas habilidades de programación. En un mundo ideal, no debería existir ninguna diferencia entre un QA y un desarrollador. En un equipo ágil, todos son ingenieros y deberían ser tratados como tal.
Los QAs técnicos trabajan en par con desarrolladores para construir la aplicación sin una brecha técnica. Ellos crean código juntos también. Ellos también ayudan a los desarrolladores a hacer TDD, promoviendo las buenas prácticas como código limpio y padrones de desarrollo, garantizando un código de alta calidad.
Ellos tienen bastante conocimiento sobre automatización de pruebas y ayudan al equipo a escoger el mejor framework de pruebas para el proyecto. Ellos también son responsables de garantizar que el equipo tenga una buena estrategia de pruebas.
Los QAs en la dimensión técnica pueden también trabajar con pruebas de performance y seguridad, dependiendo en que tan avanzado sea su conocimiento en pruebas no funcionales.
Para pruebas de performance, ellos trabajan con el cliente para descubrir los SLAs(Service Level Agreement). Dado esas informaciones, ellos crean las pruebas de performance para medir y rastrear las mejoras hechas en la aplicación relacionadas a los SLAs.
Estos QAa también estan involucrados en seguridad. Ellos entienden el contexto del negocio con el cliente y analizan posibles vulnerabilidades. Con eso ellos crean pruebas de seguridad para garantizar que esas posibles vulnerabilidades sean cubiertas por algún mecanismo de seguridad.
QAs de esta dimensión generalmente leen libros como:
Test Driven Development: By Example
Clean Code: A Handbook of Agile Software Craftsmanship
Selenium Testing Tools Cookbook
The Art of Application Performance Testing: Help For Programmers and Quality Assurance
Dimensión de DevOps
¿Cómo DevOps está relacionado a pruebas? Existen varias cosas que QAs pueden hacer para ayudar sus equipos con su conocimiento en DevOps.
Ellos introducen la práctica de entrega continua y ayudan al equipo a crear un pipeline de integración continua para recibir feedback más rápido después de cada commit. Esto ayuda al equipo a hacer deploy a producción más a menudo. En algunos casos, cada commit va directamente a producción después de pasar por el pipeline con éxito. Este pipeline también ejecutará la construcción y generación de la aplicación, herramientas de calidad de código, pruebas unitarias, de componentes y funcionales.
Los QAs DevOps configuran scripts para que su equipo pueda ejecutar fácilmente las pruebas en sus máquinas locales. En algunos casos, máquinas virtuales son requeridas y aquí los tests son configurados para ser ejecutados en paralelo.
Ellos usan task runners para que el equipo ejecute tareas repetitivas más fácil, tales como auto watches para ejecutar las pruebas automáticamente después de cada vez que los desarrolladores guarden el código. Eso disminuye el tiempo de feedback durante el desarrollo.
Este QA generalmente lee libros como:
Continuous Integration: Improving Software Quality and Reducing Risk
Continuous Delivery: Reliable Software Releases through Build, Test and Deployment Automation
Las mejores referencias en portugués son:
DevOps na prática: entrega de software confiável e automatizada
Entrega Contínua: Como Entregar Software de Forma Rápida e Confiável
¿Qué es común para todos estos QAs?
QAs en estas 3 dimensiones mantienen al equipo enfocado en entregar el valor correcto al cliente durante cada ciclo de desarrollo. Al mismo tiempo, se preocupan por la calidad del producto que está siendo entregado.
Aparte de compartir la responsabilidad de las pruebas con el resto del equipo, ellos comparten su conocimiento sobre esas pruebas. A través de este enfoque, cada miembro del equipo piensa sobre las pruebas independiente de cual su rol sea. QAs usan muchos sombreros, pero su foco principal debería ser de ayudar al equipo a entregar valor de negocio frecuentemente y con calidad.
Libros que todos los QAs ágiles deberían leer( que es la actual biblia de Agile Testing)
Agile Testing: A Practical guide for Testers and Agile Teams
¿Y tú? ¿Dónde estás en estas tres dimensiones?¿En cuál tienes interés de mejorar?
… y vamos a comenzar!
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.