Icono del sitio Alexander Andrade

El papel de QA en la Sprint Planning

La Sprint Planning (o Ceremonia de Planificación del Sprint) es algo que hacen la mayoría de los equipos ágiles. Pero cuando cada equipo tiene necesidades diferentes, no siempre existe un enfoque de «talla única». Como resultado, no siempre está claro cuál debería ser la función de QA (Quality Assurance: Aseguramiento de calidad de software). ¿Debería QA ser una parte integral del proceso de planificación del Sprint? ¿O simplemente se debería decir a los testers que miren el tablero del proyecto (en Jira u otros) y se guíe por los plazos? Sigue leyendo para descubrir cómo el rol de QA puede (y debe) encajar en el proceso de planificación del Sprint.

Primero lo primero. ¿QA tiene un papel en la planificación de Sprint? Después de todo, la respuesta diaria en muchas empresas puede ser «no». Pero para tener el mejor desarrollo de software y el mejor proceso ágil posible, debería ser «¡sí!»

QA solo tiene una cantidad finita de tiempo de prueba por sprint. Por lo tanto, es una buena idea asegurarse de que los testers (Ingenieros de pruebas, Analistas de Calidad o QAs) puedan proporcionar una cobertura de prueba completa para todos los tickets (PBI, historias técnicas o de usuarios u otros nombres) en la línea de tiempo.

Algunos tickets en el sprint también requerirán una planificación avanzada por parte de QA. Por ejemplo, es posible que necesiten escribir casos de prueba, revisar archivos de diseño o hacer preguntas de seguimiento. QA estará más preparado si saben qué tickets están en un sprint desde el principio, en lugar de cerca del final.

Las 5 razones principales para involucrar al QA en la planificación de sprint

Estimaciones

Las estimaciones no son solo para los desarrolladores, o al menos no deberían serlo. Después de todo, por cada ticket que un ingeniero necesita para terminar en un sprint, QA también debe tener tiempo para probarlo. Al proporcionar estimaciones de tickets en cada sprint, los testers pueden ayudar a evaluar qué funciones o correcciones de errores pueden caber en la línea de tiempo.

Criterios de aceptación

Como la mayoría de los testers han experimentado, los tickets de “nueva función” suelen ser bastante básicos. A veces, un ticket solo tendrá un título y un resumen muy breve. Esto puede ser suficiente para tener una idea general de cuál es la función. Sin embargo, por lo general no es suficiente información para realizar pruebas realmente exhaustivas.

Por ejemplo, imagine un ticket titulado «Agregar reproductor embebido de multimedia». El resumen podría decir algo como «Agregar un reproductor de multimedia a las pantallas que tienen clips de audio». Esa información podría ser lo suficientemente clara para otros roles, como los gerentes de proyectos. Pero los testers generalmente necesitan criterios de aceptación más detallados para asegurarse de que la función se implemente realmente según lo previsto.

Si no está familiarizado con los criterios de aceptación, básicamente se trata de una lista de características u otros detalles que debería tener la función. Algunas de las informaciones que los testers podrían necesitar en el escenario anterior podrían incluir:

Cuando QA está involucrado en la Sprint Planning, los testers pueden identificar rápidamente qué ticketsnecesitan más criterios de aceptación. Cuando esto se hace desde el principio, los gerentes de producto tendrán tiempo para agregar los detalles adicionales. Si QA no está al tanto de la información que falta hasta que el ticket esté listo para probarse, el despliegue en sí podría retrasarse.

Casos de prueba

Dado el ritmo de desarrollo de software ágil, no siempre hay tiempo para que QA escriba casos de prueba para cada nueva función. Incluso con QA involucrado en la Sprint Planning, ese podría ser el caso. Pero cuando los testers pueden tener tiempo para familiarizarse con todos los tickets en un sprint desde el principio, es mucho más probable que puedan escribir al menos algún tipo de caso de prueba. Este puede ser el caso incluso cuando, como se detallaba anteriormente, faltan los criterios de aceptación.

Cobertura por dispositivo o navegador

Una gran parte de las aplicaciones de prueba de QA y los sitios web es determinar qué navegadores o dispositivos deben probarse. Esto puede variar según la función específica o el ajuste de errores que se esté probando. Por ejemplo, si hay una nueva función dirigida a personas menores de 30 años, es menos probable que se utilice en IE 11 (Internet Explorer). Por otro lado, casi definitivamente se usará en un iPhone.

Cuando QA tiene un rol en la Sprint Planning, pueden abogar y planificar una cobertura por dispositivo o navegador específico para cada ticket en el Sprint.

Priorización

Es una realidad que incluso con una planificación excelente, a veces un equipo no puede cumplir con la fecha límite original del Sprint. Dado que QA es el último paso para completar cada ticket, a menudo es el tiempo de prueba el que se corta al final. La Sprint Planning se puede utilizar para priorizar tickets y hacer planes de respaldo en caso de que no todo se complete a tiempo. Es importante que los testers sepan qué tickets son los más y los menos importantes.

Conclusión

Los anteriores son solo algunos de los muchos motivos por los que es beneficioso asignar un papel al QA en la Sprint Planning. Pero cada motivo es significativo, incluso por sí solo, ¡y mucho menos cuando se combina con el resto! Hay muchas formas de que QA desempeñe un papel en la planificación de Sprint. Cada equipo puede encontrar la forma que mejor se adapte a sus necesidades. Pero idealmente, QA siempre debería desempeñar algún papel en la planificación del Sprint, o se puede terminar con un Sprint que no está realmente planeado de forma correcta.

Fuentes

Traducción libre de The Role of QA in Sprint Planning por Wes Silverstein

Foto por Leon en Unsplash

Author: Alexander Andrade

Ingeniero de Sistemas, MBA y Especialista en Gerencia de Proyectos Tel: +57-317-241-5118
Salir de la versión móvil