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:
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.
"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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
No Comments Yet
Let us know what you think