Criterios de aceptación
Seguí leyendo
Enterate del próximo post
Un mail cuando publico algo nuevo. Sin spam y te podés dar de baja cuando quieras.
Un mail cuando publico algo nuevo. Sin spam y te podés dar de baja cuando quieras.
Los cuatro requisitos de la spec ya tienen forma y número, pero la sección de criterios de aceptación sigue vacía desde el primer post de este bloque. Este post la completa. Un requisito dice qué tiene que cumplir el sistema; un criterio dice cómo se reconocería ese cumplimiento en un caso concreto.
Un criterio de aceptación es un ejemplo con veredicto. Toma un requisito, que es una regla general, y lo baja a una situación puntual con datos reales, una acción y un resultado que se puede observar desde afuera. La forma más difundida para escribirlo es la de BDD, que el post sobre los antecedentes del método ya mencionó como una de las herencias de SDD. Su plantilla original, en inglés, es esta:
Given <context>, when <action>, then <outcome>.Esta es la única vez que la serie la muestra. En adelante se escribe en español, con tres palabras que abren cada línea: Dado para el contexto, Cuando para la acción y Entonces para el resultado, más una Y que agrega otro resultado o otro dato al que la precede.
Tres reglas separan un criterio útil de uno decorativo. La primera es que el resultado sea observable, con la misma pregunta que el sexto post aplicó a los requisitos: qué vería alguien desde afuera si se cumple y qué vería si no. La segunda es que cada criterio tenga una sola acción. Si aparece un segundo Cuando, son dos casos y conviene separarlos, porque cuando uno falle tiene que quedar claro cuál. La tercera es usar datos concretos: https://ejemplo.com/a en lugar de "una URL válida". Con un dato genérico, cada lector imagina el suyo y el criterio vuelve a ser una regla disfrazada.
La cantidad es una decisión de criterio propio. Como punto de partida suelen alcanzar tres casos por requisito: el camino feliz, un borde y un error. No todos los requisitos tienen las tres cosas, y más criterios no significan más cobertura si dos de ellos comprueban lo mismo. La regla práctica es que cada requisito tenga al menos un criterio que podría fallar.
La spec de guardar tiene cuatro requisitos. Para cada uno hay que decidir qué casos concretos lo comprueban, y el resultado es la tabla siguiente, con ocho criterios numerados de A1 a A8. Cada criterio nombra el requisito que verifica.
| Requisito | Casos que lo comprueban | Criterios |
|---|---|---|
R1 guardar una URL nueva | Camino feliz, y dos URL distintas que no se confunden | A1, A3 |
R2 avisar si ya existe | El aviso, y una URL pedida más de una vez | A4, A5 |
R3 guardar título y fecha | Un artículo guardado con su título y su fecha | A2 |
R4 responder en menos de 3 segundos | Artículo nuevo, aviso de duplicado y el borde de los 2 segundos | A6, A7, A8 |
Hay dos casos que la tabla no cubre, y la razón es la parte más instructiva del ejercicio. Falta un criterio para R3 cuando la página no tiene título, y falta uno para R4 cuando la página tarda más de dos segundos. No es un olvido: la spec no responde ninguna de las dos cosas. Son justo las dos preguntas abiertas del documento. Un criterio necesita un resultado esperado, y donde el requisito todavía no lo decide no hay nada que escribir en Entonces.
Solo cambia ## Criterios de aceptación, que deja de estar vacía. El resto de la spec queda igual que en el post anterior.
## Criterios de aceptación
### A1. URL nueva (verifica R1)
Dado que https://ejemplo.com/a no está guardada
Cuando se pide guardarla
Entonces existe un artículo con esa URL
Y el resultado informa que se guardó
### A2. Título y fecha (verifica R3)
Dado que https://ejemplo.com/a no está guardada
Y que la página tiene el título "Guía de ejemplo"
Cuando se pide guardarla
Entonces el artículo guardado tiene el título "Guía de ejemplo"
Y tiene una fecha de guardado
### A3. Dos URL distintas (verifica R1)
Dado que https://ejemplo.com/a ya está guardada
Cuando se pide guardar https://ejemplo.com/b
Entonces existe un artículo para cada una de las dos URL
### A4. URL ya guardada (verifica R2)
Dado que https://ejemplo.com/a ya está guardada
Cuando se pide guardarla otra vez
Entonces el resultado avisa que ya existe
Y no se crea ningún artículo nuevo
### A5. URL pedida varias veces (verifica R2)
Dado que https://ejemplo.com/a no está guardada
Cuando se pide guardarla tres veces seguidas
Entonces existe un solo artículo con esa URL
### A6. Rapidez con una URL nueva (verifica R4)
Dado que https://ejemplo.com/a no está guardada
Y que la página responde en 1 segundo
Cuando se pide guardarla
Entonces el resultado llega en menos de 3 segundos desde el pedido
### A7. Rapidez con una URL repetida (verifica R4)
Dado que https://ejemplo.com/a ya está guardada
Y que la página responde en 1 segundo
Cuando se pide guardarla otra vez
Entonces el aviso llega en menos de 3 segundos desde el pedido
### A8. Borde de los 2 segundos (verifica R4)
Dado que https://ejemplo.com/a no está guardada
Y que la página responde en 1,9 segundos
Cuando se pide guardarla
Entonces el resultado llega en menos de 3 segundos desde el pedidoLa decisión menos obvia está en A8. Un criterio sobre una página que responde en un segundo comprueba R4 en su caso cómodo, y el requisito solo se pone a prueba en el límite de su condición. Con 1,9 segundos de espera, el sistema dispone de apenas 1,1 segundos para el resto, y ahí es donde una implementación descuidada falla. A2 hace la elección opuesta: dice "una fecha de guardado" y no una fecha concreta, por el mismo motivo que el sexto post dio para R3, porque precisar más empujaría una decisión de implementación hacia la spec.
Una aclaración de método: la lista de artículos guardados está fuera del alcance de esta spec, así que "existe un artículo" no se comprueba mirando una pantalla. Se comprueba mirando lo que quedó guardado, y esa es una decisión de cómo observar, no de cómo implementar.
Sin criterios, cada persona que lee un requisito elige sus propios ejemplos. Un agente que implementa R2 prueba con la URL que se le ocurre, y las pruebas que escribe para su propio código son las que ese código ya pasa. Nadie tomó de antemano la decisión de qué caso cuenta como prueba. El criterio la toma por escrito, antes de que exista la implementación y por alguien que no es quien la escribe.
El caso de A5 es el ejemplo más claro. Un sistema puede guardar bien la segunda petición y equivocarse en la tercera, si por ejemplo el aviso de duplicado se apoya en un dato que solo se actualiza una vez. Ningún requisito lo menciona, y ningún ejemplo improvisado lo prueba. Con el criterio escrito, el caso existe y falla o pasa a la vista de todos.
Los criterios también tienen costos. Ocho criterios para cuatro requisitos son ocho textos que mantener cuando un requisito cambie, y un conjunto que solo cubre caminos felices da una confianza que no corresponde: que todos los criterios pasen no prueba que el requisito se cumpla, prueba que se cumplió en esos casos. Y un criterio no arregla un requisito mal escrito: donde la spec es ambigua, el criterio solo mueve la ambigüedad a otro lugar, como pasa con A2 y su "una fecha". Un criterio tampoco es un test, es una frase en prosa que un test puede automatizar más adelante.
Un criterio de aceptación es un caso concreto con datos reales y un resultado observable. Escribirlos muestra qué requisitos ya se pueden comprobar y cuáles todavía no, porque donde falta una decisión no hay nada que poner en
Entonces.
Con la forma del requisito y los casos que lo comprueban, quedan las preguntas abiertas y todo lo que los requisitos no dicen. El próximo post trata la clarificación: cómo buscar esas ambigüedades a propósito, antes de que alguien empiece a implementar.