Historias de usuario de seguridad y criterios de aceptación

Un criterio de aceptación es una condición que, al cumplirse, hace que una historia se dé por terminada. Para una historia de seguridad, un buen criterio es binario (da pasa o falla), observable (se ve en una respuesta, un registro o un estado) y repetible (otra persona obtiene el mismo resultado). Suele escribirse como «dado un contexto, cuando ocurre algo, entonces se observa esto».

Un criterio como «la aplicación es segura» no cumple ninguna de las tres cosas: nadie puede mostrarlo en una demostración del sprint.

Abre backlog/historias.txt y lee los criterios de cada historia. Una de ellas tiene un criterio que nadie podría demostrar y que, en la práctica, se cerraría por cansancio del equipo o por decisión de quien presiona más.

El tablero backlog/sprint-12.txt marca el tipo de cada historia y su número de criterios. Una carga de seguridad que no se ve en el sprint tiende a desaparecer cuando el calendario aprieta. Suma los criterios de aceptación de las historias de tipo seguridad.

Una historia de seguridad debería poder rastrearse hasta el requisito del que nace; si no, nadie sabrá por qué existe ni cuándo se puede retirar. Mira el campo de origen de la historia en la que la persona quiere ver solo sus propias citas.

La historia HS-23 está escrita desde el punto de vista de quien quiere abusar: «como atacante quiero probar contraseñas sin límite». Se llama caso de abuso. No pide construir esa capacidad: describe lo que debe quedar impedido, y de ahí salen los criterios, como el límite de intentos o el registro de cada fallo. Todo se lee y se redacta; no se ejecuta nada.