QA en tiempos de Scrum

By: Luis José Martín

En tiempos donde la metodología Scrum es casi un “must-have” para cualquier compañía de desarrollo de software, valdría la pena evaluar qué papel juega la labor de QA en la misma.

En una metodología caracterizada por tiempos de desarrollo cortos, uno de los principales retos del área de QA es garantizar que el valor o la calidad del producto no se vea sacrificada por timelines o por la necesidad de realizar delivery continuo de funcionalidades. A su vez, se vuelve una necesidad garantizar no solo que el producto que se está desarrollando se culmine correctamente, sino que el proceso de desarrollo se haga de la misma forma. Por esto se dice que en Scrum el fin mayor de la labor de QA es prevenir defectos por sobre encontrarlos (“Prevent Defects rather than finding defects”).

QA como responsabilidad de todo el equipo

Por todo esto, surge la idea de hacer que la labor de QA sea responsabilidad de todo el equipo, y que esta se tenga en cuenta desde el día 1. Para ello, es importante que no solo “la persona de QA” sino también el equipo de desarrollo y operaciones estén empapados con los requerimientos del cliente desde el inicio.

Por otro lado, si bien el testing como responsabilidad de todos tiene ya algunas prácticas que lo acompañan (como el TDD, por ejemplo), debería ir más allá de solo hacer QC: se debe fomentar también la participación del equipo de desarrollo y operaciones en la concepción del producto, en la bajada de los requerimientos a tareas sprint a sprint, en la documentación del producto y en la comunicación con el cliente.

Beneficios

El mayor beneficio de hacer que el QA sea responsabilidad de todo el equipo radica en que mantiene constantemente el foco de todos en la calidad del producto, y no solo para una única persona al final de los sprints.

Bajo este enfoque, el QA pasa a ser entonces parte de las tareas del día a día de todo el equipo, estimulando la calidad del código mismo desde su escritura. Además, tener un buen conocimiento del producto también le permitirá al equipo de desarrollo y operaciones tomar mejores decisiones en cuanto a arquitectura, seguridad, estrés al que va a ser sometido el producto en producción y muchas otras decisiones para las cuales este equipo es el más indicado en tomar.

Por otra parte, otro beneficio importante de que el equipo entero se enfoque en la calidad del producto, es poder detectar bugs en etapas más tempranas del desarrollo de una funcionalidad, ya que no es necesario esperar al final de un sprint para que el “equipo de QA” tome una funcionalidad y la testee.

Importancia de hacer QA desde etapas tempranas del desarrollo

Hacer QA desde etapas tempranas del desarrollo nos traerá muchos beneficios, entre los cuales tenemos:

• Feedback temprano y consistente: para cada nueva funcionalidad podremos obtener feedback temprano y consistente gracias a que esta habrá pasado por las manos de todo un equipo antes de ser entregada. Para esto, es muy importante también mejorar la comunicación entre las áreas de QA, Dev y Ops, así como la formación técnica de los referentes de QA.
• Disminución de costos: El costo de fixear bugs (en dinero y en tiempo) en las etapas finales del desarrollo o cuando la funcionalidad ya está en producción, superan a los de fixearlos en las etapas iniciales.
• Disminución de potenciales bugs: la corrección tardía de bugs puede llevar a nuevos bugs al tener que modificar código para solucionarlos.

Una mejor primera impresión en el delivery de software: siempre es preferible que los clientes tengan en sus manos productos de calidad desde el primer momento y no solo después de muchas iteraciones de corrección de bugs, ya que esto le da mayor confianza al cliente y al usuario final del producto.

Conclusión

En conclusión, es necesario no dejar aislada la importante labor de aseguramiento de la calidad en tiempos donde esta es una característica imprescindible para diferenciarte del resto de aplicaciones/productos en el mercado. Para lograrlo, más que acercar el rol de QA a los demás roles del equipo, se debe acercar estos al de QA, aumentando su compromiso con la calidad del producto que ellos mismos están desarrollando.

Conectar las áreas de desarrollo, operaciones y testing, y asegurarse de tener un equipo donde todos los miembros sepan al menos un poco de todo y tengan un fin común (la calidad), es lo que permitirá entregar mayor valor al cliente más rápido, lo que, en definitiva, es una de las metas fundamentales de Scrum.

By: Luis José Martín

________________________________________________________________

Ver nuestra última nota → Design Sprint: Cómo trabajar de manera colaborativa

Si te interesa nuestro contenido, y querés saber más, inscribite a nuestro newsletter haciendo click acá.