El papel del analista QA en las ceremonias Scrum
Los analistas de certificación, también conocidos como QA (Quality Analist) somos las personas encargadas de ejecutar todas las actividades que existen dentro del proceso de certificación de un proyecto (software web o apps móviles) y, al contrario de lo que comúnmente se piensa, los QA no solo nos limitamos a detectar fallos (bugs) en los sistemas, sino que nuestra labor va más allá.
El equipo de QA (Certificación) se sitúa entre el cliente y el equipo de desarrollo, ayudando al cliente a definir los requisitos y los objetivos de las pruebas, y al equipo de desarrollo a verificar correctamente el producto antes de que este llegue al usuario final.
Algunas de las actividades generales que realizamos en nuestro trabajo son:
- Realizar plan de pruebas
- Diseño de casos de prueba
- Ejecución de pruebas
- Automatización de pruebas
- Registro y seguimiento de incidencias
- Pruebas de regresión
- Toma de evidencias
- Realizar certificación (Carta formal)
Pero nuestra labor y la de todo el equipo de desarrollo está ligada con la metodología de trabajo que se implemente en cada proyecto u organización, esto hace que tengamos que considerar otras actividades a ejecutar, las cuales nos ayudarán a cumplir el objetivo final.
En este caso hablaremos sobre las actividades que los analistas de certificación podemos realizar dentro de las ceremonias/reuniones de la metodología Scrum.
El analista QA en las ceremonías Scrum
¿Qué es Scrum?
"Scrum es un marco de trabajo por el cual las personas pueden abordar problemas complejos adaptativos, a la vez que entregar productos del máximo valor posible productiva y creativamente.
Scrum ha sido usado para gestionar el trabajo en productos complejos desde principios de los años 90. No es un proceso, una técnica o método definitivo. En lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varios procesos y técnicas.
Este método muestra la eficacia relativa de las técnicas de gestión de producto y las técnicas de trabajo de modo que podamos mejorar continuamente el producto, el equipo y el entorno de trabajo.
El marco de trabajo Scrum consiste en los equipos Scrum y sus roles, eventos, artefactos y reglas asociadas. Cada componente dentro del marco de trabajo sirve a un propósito específico y es esencial para el éxito de Scrum y para su uso." (La guía de Scrum)
Ceremonias Scrum
1. Inception
Este evento se realiza para alinear al equipo, en él se hace uso de diferentes dinámicas para enfocar a todas las personas involucradas en el proyecto hacia un mismo objetivo, disminuyendo muchas dudas y ayudando a descubrir los riesgos más evidentes en el proyecto. Como resultado de esta reunión se puede crear el backlog inicial.
Actividades QA:
- Conocer el negocio y el cliente para el cual se desarrollará el proyecto
- Entender cuál es la necesidad y qué valor se desea generar al usuario final con la implementación del producto
- Conocer cuál es el perfil/tipo de usuario para el cual se desarrollará el producto.
Estas actividades nos ayudarán a entender a profundidad el objetivo que se desea cumplir en el proyecto y nos dará la oportunidad de ponernos en el lugar del usuario final y al momento de ejecutar las pruebas, hacerlas pensando en él.
2. Socialización
Actividades QA:
- Entender las funcionalidades y los flujos que maneja el cliente con su usuario final
- Entender el valor que se desea generar con el desarrollo del proyecto, en la relación cliente-usuario
Si como analistas QA no pudimos estar presente en el Inception, sí debemos de estar al tanto de la información que salga de la Socialización, la cual nos dará la oportunidad de conocer al cliente y a su usuario final; y pensando siempre en ellos, tendremos la oportunidad de hacer sugerencias u observaciones de mejora en el ciclo de desarrollo del proyecto, las cuales vayan en pro de ese valor que se desea generar.
3. Priorización
Actividades QA:
- Conocer el backlog y las funcionalidades que tendrá el producto (portal, app, etc) y estas deben estar priorizadas (MPV)
- Comenzar a validar el DoR (Definition of ready) de las Historias de usuario.
En este punto los analistas de certificación tendremos claro cuál será el mínimo producto viable del proyecto, sabremos qué funcionalidades se desarrollarán y en qué orden según la prioridad que se le haya asignado.
4. Refinamiento
El propósito de esta ceremonia es agregar detalle, estimaciones y orden a los elementos del Product Backlog. Es un proceso continuo en el cual todo el equipo de desarrollo y del cliente colaboran para aclarar los requerimientos y asegurar que esta lista de producto siempre esté preparado/actualizado y sin ambigüedades.
Actividades QA:
- Conocer los flujos de los procesos que se manejarán en el desarrollo del proyecto
- Validar que están listos todos los insumos necesarios para desarrollar cada Hu’s (DoR)
- Validar que el diseño de UX/UI cumpla con lo definido en el proyecto hasta el momento.
En esta ceremonia los analistas de certificación podremos identificar cuáles insumos le hacen falta a todo el equipo para empezar a desarrollar las HU’s, podremos identificar incongruencias entre lo que ya está definido y lo presentado en los diseños de UX/UI, así que se podrán corregir a tiempo y también podremos identificar posibilidades de mejora.
5. Planning
Esta ceremonia se realiza al comienzo de cada Sprint y en ella se reúne todo el equipo de trabajo. El objetivo es inspeccionar el product backlog y seleccionar cuáles items (Historias de usuario) se van a trabajar durante el Sprint, esta selección se hace teniendo en cuenta la prioridad definida anteriormente.
El sprint planning se puede dividir en dos partes, en la primera se trata el qué se va a hacer en el Sprint; y en la segunda parte se discute el cómo.
Actividades QA:
- Participar en la definición detallada de los criterios de aceptación de cada HU’s
- Comentar las dudas que se tengan sobre las HU’s e identificar validaciones que no se hayan tenido en cuenta
- Validar que el diseño presentado por UX/UI finalmente si cumpla con lo definido en las HU’s
- Identificar los tipos de usuario y demás datos que necesitemos para ejecutar los diferentes escenarios de prueba
- Identificar si es necesario generar un documento de consideraciones generales (Diseño, validaciones de campos, caracteres permitidos,etc) para tener en cuenta durante todo el desarrollo
- Generar un caso de prueba por cada HU’s, comentarla como una tarea y socializarla con los desarrolladores
Participar en la votación de puntos para cada HU’s (Estimación)
Al participar en esta ceremonia y ejecutar las actividades mencionadas anteriormente, estaremos agregando gran valor al proyecto y apoyando a todos nuestros compañeros del equipo.
Al final de esta ceremonia, estará claro lo que se va a desarrollar y todo el equipo tendrá listos los insumos necesarios para comentar con el Sprint, por nuestra parte los QA podremos comenzar con el diseño de casos de prueba.
Si en esta reunión no identificamos incongruencias ni validaciones que hagan falta, no significa que no las podamos comentar en el transcurso del sprint.
6. Daily
Es una reunión que se realiza todos los días, con una duración de 15 minutos, en la cual cada integrante del equipo de desarrollo responderá a 3 preguntas: ¿Qué hiciste ayer? ¿En qué trabajarás hoy? y ¿Qué impedimentos tienes?
El objetivo de esta ceremonia es validar el progreso del sprint y conocer los impedimentos que han surgido para gestionarlos oportunamente.
Actividades QA:
- Comentar ¿Qué hice ayer? ¿Qué voy a hacer hoy? Y ¿Qué impedimentos tengo?
- Informar como va la ejecución del proceso de pruebas. (teniendo en cuenta versiones, ambientes, etc).
- Comentar nuevos casos o validaciones que hayamos identificado y que deban ser contempladas en el desarrollo del proyecto.
Con esta pequeña reunión realizada conjuntamente con todo el equipo, estaremos todos alineados y conoceremos día a día nuestro avance con el Sprint, además es la oportunidad de comentar los inconvenientes que surjan para poder solucionarlos lo más rápido posible y no afectar el avance del equipo.
7. Review
Esta ceremonia se realiza al final de cada Sprint y requiere la presencia de todo el equipo de desarrollo y del cliente. En esta reunión el equipo de desarrollo comparte y expone lo que se ha realizado durante el sprint.
El objetivo es revisar el incremento obtenido y recibir retroalimentación del cliente, tomando nota de todas las observaciones que surjan para mejorar el producto y poder trabajar en ello en el siguiente sprint.
Actividades QA:
- Presentar la Review de al menos uno de los sprint del proyecto
- Tomar evidencias de lo desarrollado en el sprint
Socializar los incidentes que se hayan presentado en el sprint (Indicadores) - Socializar la automatización de pruebas que se haya realizado (Si aplica)
- Tomar nota de las observaciones o conclusiones que se presenten en la ceremonia para poder gestionarlas posteriormente.
Es muy importante la presencia y la participación activa del equipo de QA en esta ceremonia, ya que muchas veces el cliente puede tener dudas o confusiones frente a lo que está viendo desarrollado del producto, y nosotros como QA podremos ayudar a resolver esas dudas.
Es importante que tomemos evidencia del producto funcional (Vídeos o imágenes) antes de cada review y las tengamos presentes por si surge algún inconveniente que no permita hacer la demostración del mismo. También es relevante que socialicemos como fue el ciclo de ejecución de pruebas y sus resultados.
8. Retrospectiva
La retrospectiva ocurre al final de cada Sprint, después de la Review y antes del siguiente sprint planning. Esta ceremonia debe contar con la presencia de todo el equipo de desarrollo y del cliente; el objetivo es reflexionar sobre cómo se trabajó en el último sprint e identificar posibles mejoras para el próximo, así todos los miembros del equipo piensan en posibles soluciones para sobrepasar los obstáculos.
Actividades QA:
- Identificar posibilidades de mejora en cuanto a personas, relaciones, procesos y herramientas, para implementar en el próximo sprint.
- Buscar mejores formas de trabajar.
- Hablar sobre la información que salió en la Review si es necesario.
En esta reunión es necesario que todo el equipo comunique de una manera asertiva lo que piensa y siente frente al trabajo de todo el equipo.
Todos deben tener la disposición para comunicar y escuchar cada aporte; también es importante que a la hora de comunicar un ‘punto de fallo’ vayamos directo al hecho y no a la persona, lo que realmente importa es mejorar la forma de trabajo no señalar a las demás personas como culpables.
Comparte
Te puede interesar
Otros artículos de Marketing
Claves a tener en cuenta antes de realizar una prueba performance
¿Cómo hacer pruebas de calidad de software para una app móvil?
¿Qué es una super App?
Suscríbete al
Blog Pragma
Recibirás cada mes nuestra selección de contenido en Transformación digital.