Iniciemos desde un nivel muy alto, en un proyecto idealizado que corra sobre metodologías Ágil, y con un rol idealizado de testing, un rol que generalmente se cataloga como QA.
El Kick Off
Este es una junta donde se reunen todos los involucrados en el proyecto y pueden estar incluídos representantes de distintos departamentos como marketing o ventas, así como mánagers de proyecto, dueños del producto, desarrolladores, arquitectos, diseñadores de experiencia de usuario y, por supuesto, testers. La razón porque alguien con el rol de tester participe, ya que el objetivo de esta junta es que todos tengan la idea de no sólo lo que harán, sino que compartan la idea del porqué realizarán el proyecto. Se revisan los objetivos del negocio que condujeron a las decisiones que se han tomado respecto al proyecto; una vez que se entienden los objetivos del negocio, se puede tener una idea más clara de que signfica calidad en este proyecto.
Una vez definido el concepto de calidad dentro del proyecto, se puede trabajar en conjunto con el resto del equipo para que Calidad ocurra.
Si este es un proyecto en curso, sería benéfico tener juntas regulares con el mismo propósito de alinear objetivos ya que es esperado que el negocio enfrente cambios a medida que el mercado cambie.
La definición de “Hecho”
Es importante que los equipos definan que aceptarán como Hecho, cuándo es que considerarán una historia como “hecha” o “terminada”, dicha definición deberá ser acordada y aceptada aún antes de que empiecen la construcción de su producto. Sin embargo, esta definición puede ser actualizada si el equipo decide que es necesario. Una definición de hecho(DOD por sus siglas en ingles), se debería basar en los siguientes puntos:
- Todas las solicitudes conjuntas fueron aprobadas por dos desarrolladores antes de hacer el despliegue al ambiente de QA
- Las pruebas unitarias pasaron
- Los criterios de aceptación se alcanzaron
- Las pruebas funcionales se aprobaron
- Los bugs encontrados fueron solucionados(a menos que el dueño del producto hubiera decidido otra acción)
- El dueño del producto aceptó la historia de usuario
Hay muchas y distintas versiones de lo que es una Definición de Hecho, pero lo que considero extremadamente importante es que una historia de usuario no puede considerarse terminada hasta que haya sido probada y los bugs encontrados estén debidamente reportados. Hacer que el equipo esté de acuerdo que la Definición de Hecho incluya sesiones de pruebas y remediación de defectos, significa que el equipo ha aceptado compartir la responsabilidad de crear un producto de calidad.
Planeación de Sprint
Esta debería ser siempre una actividad de equipo, y puede ser complicada para quien tenga el rol de tester. Aquí sucede un cambio de paradigma, los miembros del equipo se enfrentan a la responsabilidad de decir qué actividades realizarán y dejan de lado el sólo recibir instrucciones a realizar; esta transición puede ser complicada para cualquiera.
La definición de hecho debe de incluir las actividades de testing como parte de la estimación de toda la historia de usuario, esto significa QA/Testing necesita ser parte de la conversación. Necesitan preguntar sobre los criterios de aceptación y dar retroalimentación si algo no puede probarse, o si algo parece no ajustarse a las reglas de negocio.
Los desarrolladores tienden a discutir sobre la dificultad de implementar una funcionalidad y eso es algo importante de saber, es necesario tomar notas de estas preocupaciones y hablar con ellos para entender el porqué de su preocupación. Podría significar que será necesario realizar más pruebas o que habrá que hacer mancuerna con los desarrolladores desde las etapas tempranas del proceso para brindar la ayuda necesaria.
Algunas cosas son fáciles de codificar pero difíciles de probar, y viceversa. Es importante que el equipo conozca el nivel de esfuerzo sin perder el propósito de las juntas diarias; será complicado encontrar un balance, más si el tester siente que alguna historia de usuario no tiene tiempo suficiente para probar, sin embargo el resultado será peor si estas inquietudes no quedan resueltas. Los equipos que no estiman esfuerzos de testing, son equipos que generalmente terminan con una deuda técnica ya que dejan pasar historias con bugs, casi siempre por tener presiones de tiempo, o simplemente por no poder completar las historias dentro de los límites del sprint.
Algo que también es recomendable es que los equipos elijan historias que de distintos tamaños a fin de escalonar el avance de las historias hacia testing y dueños de productos. Esto ayuda a mitigar los cuellos de botella al final del sprint, cuando todas las historias necesitan ser probadas y aceptadas, generalmente, un día antes que el sprint termine. Entre mejor trabaje un equipo en conjunto, estarán estimando mejor en conjunto, así que una buena dinámica de equipo y buena comunicación son esenciales para todos los roles.
Durante el Sprint
Seguimiento
Parte de trabajar en equipo es que cada miembro use la misma herramienta con toda la información en un solo lugar, muchas veces Jira o una herramienta similar; también es provechoso usar una pizarra(ya sea en línea o física) que registre los estatus de cada historia de usuario. Las tres columnas básicas serán:
Por Hacer | En Progreso | Hecho
Sin embargo, aunque no es muy generalizado, también puede ser provechoso incluir otras columnas que ayuden a clarificar el estatus de las historias. Además que ayuda a determinar los cuellos de botella que ocurren durante el sprint. La pizarra completa se vería así:
Por Hacer | En Progreso | En Pruebas | Probado y con bugs | Hecho | Aceptado
Por Hacer – Historias que están en el sprint pero que todavía no son trabajadas
En Progreso – Historias que se están trabajando
En Pruebas – Historias que se están probando
Probado y con bugs – Historias que han sido probadas pero que reportaron bugs
Hecho – Historias que han sido probadas y los bugs han sido reportados y asignados
Aceptado – Historias que han sido aprobadas por el dueño del producto y están listas para salir a producción
Los primeros días del Sprint
Sería fácil pensar que los primeros días del sprint son tranquilos para los testers ya que no hay historias completadas que haya que probar. Sin embargo hay varias actividades que un tester puede realizar.
Kick off de las historias(Los tres amigos)
Aunque esta técnica necesita una explicación más detallada, aquí va una versión resumida. Justo antes que el desarrollador empiece a trabajar con su historia, debe reunirse con el tester y el dueño del producto; debe ser una conversación rápida donde se revisen los criterios de aceptación y hablar de los detalles de como debería ser probada. La historia debe de actualizarse con la información obtenida en esta reunión; además el desarrollador debería ya tener una idea de que temas serán probados y ver la manera en que estas pasen mientras desarrolla sus historias.
Revisiones de diseño
Los diseñadores visuales y de experiencia de usuario deberían reunirse a discutir diseños futuros y solicitar retroalimentación. Por supuesto, será necesario que los testers asistan a estas reuniones y enterarse como es que el producto irá evolucionando; además que será una oportunidad para dar sus opiniones basadas en experiencias previas y así ayudar a evitar problemas futuros.
Regresiones manuales priorizadas
Otro tema que merece ser explicado a detalle, pero eso será en otra ocasión. A grandes rasgos; se trata de un crear una lista, y se actualice, dependiendo de como se comporte el producto que se está desarrollando. Enlista una serie de funcionalidades clave que ya estén creadas, prioriza cada una, y al inicio de cada sprint realiza pruebas exploratorias en cada una de estas áreas, ya que al final del sprint será complicado realizarlas.
Preparación de pruebas
Algunas historias requieren de cierta preparación, incluso documentación. Es necesario que los testers revisen las historias de usuario en el sprint y se aseguren de estar preparados una vez que el desarrollo termine.
Actualización de automatización
El objetivo es mantener actualizados los scripts o crear nuevos. También resulta valioso incluir revisiones de ejecuciones y actuar en consecuencia en las falladas.
Historias de testing
Una vez que el desarrollador ha asignado una historia a Testing, se tiene que verificar que los criterios de aceptación se han alcanzado, y será responsabilidad de cada tester averiguar como verificar que se cumplen. En este punto es indispensable entender las necesidades del negocio, además de haber revisado la historia con el dueño del producto y el desarrollador, ellos deberían tener la información necesaria para realizar las pruebas necesarias. Otro punto relevante es que el tester no sólo debe enfocarse en alcanzar los criterios de aceptación, las pruebas exploratorias son esenciales y el equipo debe estar consciente que se reportarán bugs de funcionalidades o procesos que no estén definidas en las historias; habrá algunos errores que serán necesarios discutir primero con el desarrollador, o el dueño del producto, o ambos, antes de de reportar un defecto y así poder discutir el impacto que tendrá en el sprint; o tal vez, simplemente, no sea un error como tal y no haya necesidad de documentarlo; así como también puede ser un error tan pequeño e irrelevante, como un error ortográfico, que pueda ser solucionado al vuelo.
El objetivo de testing no debería ser encontrar y reportar la mayor cantidad de defectos; el objetivo debe ser proveer retroalimentación enfocada al negocio rápidamente, los bugs son sólo una manera de dar esa retroalimentación, o también mantener conversaciones constantes con el resto del equipo. Documentar temas relevantes al proyecto resulta de gran ayuda para clarificar temas que haya acordado el equipo; hasta comentarios agregados a las historias son tan provechosos como reportar defectos, en algunos casos.
Todo bug reportado y documentado debe ser asociado a una historia de usuario de alguna manera u otra, pensemos que la historia es la madre de ese bug, al igual que lo es de comentarios y sub tareas. De esta manera, cada que el resto del equipo voltee a ver la historia, encontrará toda la información asociada con ella.
Si no se encontraron problemas con la historia, es momento de enviarla a Aceptación con el dueño del producto. Los bugs documentados deben ser asignado al desarrollador que trabajó con la historia, una vez arreglados, se reasignan a la persona que lo reportó, así se verificará que el bug se arregló y procederá a cerrarlo; ningún defecto debería ser reabierto más de una vez. Testers y desarrolladores deben trabajar juntos para resolver un bug engañoso en vez de jugar al ping pong con los tickets.
Esto se repite cuantas veces sea necesario.
Software Quality and Testing 