Durante los últimos años la “ola ágil” se ha asentado en Latinoamérica, por lo que muchas empresas de tecnología han empezado a aplicar metodologías ágiles en su negocio dejando de lado las tradicionales. Sin embargo, no se debe caer en el error de asumir que ambos modelos son competidores directos, ya que encuentran su nicho en la diversidad, complejidad y las diferentes características que puedan presentar los proyectos en los que se esté trabajando.
En el ámbito de QA, la transición demanda entre otras cosas, una participación más estrecha con la metodología, con el cliente o el proceso y con el equipo multifuncional de trabajo.
El equipo de QA pasa a formar parte activa desde la definición de los requerimientos y durante todo el ciclo de la vida del proyecto. Las actividades del equipo de pruebas ya no se centrarán únicamente en la última etapa del modelo tradicional: pruebas. En esta etapa no solo se escriben y ejecutan casos de prueba o se reportan defectos, sino que se amplía su alcance.
El equipo de QA puede ahora ayudar al “product owner” a escribir criterios de aceptación, participar en la estimación de historias de usuario, ayudar al equipo multifuncional a mantener el objetivo y la visión del Sprint, colaborar con los clientes y desarrolladores, o participar en demos, entre otros.
Iniciando la transición
Las actividades del equipo de pruebas pueden incrementar de manera exponencial, por esta razón si la empresa tiene planeada una transición de un método tradicional a un método ágil es conveniente tener las siguientes consideraciones en cuenta:
· Entrenar al equipo de QA en metodologías ágiles. Uso de las terminologías correctas – Product Backlog, Sprint Backlog,Product Owner,Retrospective Meeting – Lograr conocer los objetivos de cada uno de ellos ayudará al equipo a incorporarse rápido en el proceso y aportar valor agregado en el equipo multifuncional.
· Realizar ejercicios junto con el equipo multifuncional de cómo se lleva la metodología ágil. En pequeñas reuniones de media hora se pueden mostrar con ejercicios prácticos el uso de metodologías ágiles, errores comunes al momento de estimar, consecuencias de no terminar los requerimientos a tiempo o el uso de Burndown Charts.
· Estar listo para adaptarse continuamente por los cambios sugeridos durante el proceso de desarrollo. Esto podría incluir cambios en los requerimientos, ambientes de prueba, criterios de aceptación, alcance de pruebas, entre otros.
· El equipo de QA debe estar preparado para interactuar directamente con el usuario final. En ocasiones el equipo de QA solicitará información adicional referente a los Criterios de Aceptación, definiciones de historias de Usuario o cualquier detalle no claro en las Historias de Usuario.
· Compartir información cara a cara más que mantener solicitudes documentadas. Se afrontará un reto adicional si se trata de un equipo distribuido, por lo que el uso de videoconferencias es recomendable.
· No se acortarán los tiempos de QA. Mientras en las metodologías tradicionales los tiempos de prueba suelen sacrificarse, en ágil, QA participa desde el inicio de cada Sprint.
· Debido a períodos continuos y cortos de desarrollo y pruebas se hará patente la necesidad de ejecutar pruebas de regresión de manera regular. Una suite de regresión automatizada puede ayudarle a verificar la estabilidad del artefacto y a ampliar sus pruebas funcionales basado en el expertise de su equipo de pruebas.
· De darse el caso, las metodologías ágiles le permitirán prescindir de requisitos de baja prioridad antes que tener que degradar la calidad de su producto.
.png)
