La retrospectiva es la ceremonia donde el equipo se detiene a mirar hacia adentro: qué funcionó bien en el sprint, qué no, y qué se puede mejorar. Para el tester, es uno de los espacios más importantes para generar cambios reales en el proceso — y muchas veces, el rol que más tiene para decir.

🔍 El rol del tester en la Retrospectiva

El tester tiene una perspectiva única en la retro: ve el producto desde afuera, interactúa con lo que el equipo produce y detecta patrones que otros no siempre notan. Algunos aportes concretos:

• Visibilizar problemas sistémicos. Si en tres sprints consecutivos los bugs aparecen siempre en el mismo tipo de funcionalidad, eso es información valiosa que el equipo necesita discutir.

• Cuestionar el proceso de entrega. ¿Las historias llegan a testing con la información necesaria? ¿Los criterios de aceptación son claros? ¿Hay deuda técnica que está dificultando el testing? La retro es el lugar para decirlo.

• Proponer mejoras concretas. No alcanza con señalar problemas — el tester puede proponer cambios de proceso: agregar un checklist de Definition of Ready, reservar tiempo para testing exploratorio, mejorar la cobertura de regresión.

• Celebrar lo que funciona. Si algo mejoró respecto al sprint anterior, también vale reconocerlo. La retro no es solo para quejarse.

📚 Para profundizar

• Scrum Guide en español — La definición oficial de la Retrospectiva de Sprint, su propósito y su duración recomendada.

• Agile Retrospectives — Esther Derby & Diana Larsen — El libro de referencia sobre cómo facilitar retrospectivas que generen cambios reales.

🤔 Para reflexionar

• ¿En las retros de tu equipo, el tester tiene voz activa o es más un espectador? ¿Qué cambiaría si participara más?

• ¿Alguna vez saliste de una retrospectiva con un cambio concreto que mejoró tu trabajo como tester? ¿Qué fue?