Las historias de usuario no son solo territorio del desarrollador — son la materia prima del tester. Antes de que exista código, antes de que haya algo que ejecutar, ya hay trabajo de testing que hacer. Esta clase explica exactamente cuál es ese trabajo y por qué hacerlo bien cambia todo lo que viene después.

🔍 El trabajo del tester con una historia de usuario

Cuando llega una historia de usuario, el tester no debería esperar a que el desarrollo termine para involucrarse. Lo que debería hacer desde el momento en que la historia aparece en el backlog:

• Leer los criterios de aceptación con ojo crítico. ¿Son verificables? ¿Cubren solo el happy path o también los escenarios alternativos y de error? ¿Hay ambigüedades que podrían interpretarse de más de una forma?

• Hacer preguntas antes de que sea tarde. Si algo no está claro en el refinement, preguntarlo ahí cuesta minutos. Descubrirlo durante el testing cuesta horas — o peor, llega a producción.

• Identificar los escenarios de prueba desde temprano. No hace falta esperar al desarrollo para empezar a pensar en qué habría que probar. Anticipar los casos de prueba en base a la historia permite detectar huecos en los criterios de aceptación antes de que el código esté escrito.

• Usar la historia como oráculo durante el testing. Cuando algo no está claro en el sistema, la historia de usuario es la primera referencia para determinar si el comportamiento observado es correcto o es un defecto.

📚 Para profundizar

• User Stories Applied — Mike Cohn — El libro de referencia sobre historias de usuario, cómo escribirlas bien y cómo usarlas como herramienta de comunicación en el equipo.

• INVEST in Good Stories — Bill Wake — Un artículo clásico sobre los criterios que debería cumplir una buena historia de usuario. Muy útil para saber qué buscar cuando las revisás como tester.

🤔 Para reflexionar

• ¿Cuándo fue la última vez que encontraste un bug que podría haberse evitado si la historia de usuario hubiera estado mejor escrita?

• ¿Tu equipo trata las historias de usuario como un contrato fijo o como una conversación abierta? ¿Qué diferencia hace eso en tu trabajo como tester?