¿Qué son los criterios de aceptación? Cómo escribir condiciones que todos acepten

Los criterios de aceptación son las condiciones que un trabajo tiene que cumplir antes de que alguien lo dé por terminado. Se escriben antes de empezar, los redacta quien pide el trabajo y se acuerdan con quienes lo van a construir y a probar.

Su función es adelantar una discusión en el tiempo. Sin ellos, “¿esto está terminado?” se resuelve después del trabajo, y lo resuelve quien lo defienda con más fuerza. Con ellos ya estaba resuelto antes, por gente que estaba tranquila.

Lo que no son

No son una descripción de la función. “El usuario puede filtrar el informe” es un resumen. Un criterio dice qué tiene que ser cierto: qué filtros, qué pasa cuando ninguno coincide, en qué estado queda la pantalla después de recargar.

No son un diseño. Los criterios describen resultados, no maquetación. “Un desplegable arriba a la derecha” decide la solución y se la quita a quien está en mejor posición para elegirla.

No son casos de prueba. Un criterio es una condición; un caso de prueba es un procedimiento para comprobar una. De un solo criterio suelen colgar varios casos, y se escriben más tarde, por alguien que puede no ser la misma persona.

Los dos formatos que se usan

Una lista de comprobación es el más sencillo de los dos, y para la mayoría del trabajo basta.

Terminado cuando:
- Una persona identificada solo ve sus propios pedidos
- Un pedido sin líneas aparece igualmente, con un total de 0,00
- La lista carga en menos de dos segundos para una cuenta con 10.000 pedidos
- La ordenación por fecha se mantiene al pasar de página

Dado, cuando, entonces es más formal, y su ceremonia extra se gana cuando el comportamiento depende del estado.

Dado un cliente con una tarjeta caducada
Cuando envía el formulario de pago
Entonces el pago se rechaza
Y los campos de la tarjeta conservan los valores que introdujo
Y el mensaje dice qué campo hay que corregir

El valor está en el dado. La mayoría de los malentendidos viven en el estado de partida - una cuenta de prueba, un token caducado, una lista vacía - y no en la acción, y el formato obliga a alguien a nombrarlo.

Ninguno de los dos es mejor. Usa la lista de comprobación por defecto y recurre a dado-cuando-entonces donde la misma acción tenga que comportarse de forma distinta según la situación.

Qué separa un criterio bueno de uno malo

La prueba es si dos personas podrían discrepar sobre si se cumple.

Débil

La página debería cargar rápido y mostrar resultados relevantes

Mejor

La primera página de resultados aparece en menos de dos segundos para una cuenta con 10.000 pedidos, y muestra solo los pedidos de esa cuenta

Cuatro costumbres producen casi todos los débiles:

• Adjetivos en lugar de umbrales. Rápido, intuitivo, robusto, fácil de usar. Ninguno se puede comprobar; sobre todos se puede discutir.
• Solo el camino feliz. Los criterios que describen qué pasa cuando todo funciona dejan cada fallo al criterio de alguien a las cuatro de la tarde del día de la entrega.
• Soluciones. “Añadir un diálogo de confirmación” en lugar de “el usuario no puede borrar una factura sin confirmarlo”.
• Todo a la vez. Una historia con diecinueve criterios son varias historias, y estará a medias durante quince días.

Quién los escribe, y cuándo

Los redacta quien pide el trabajo, y se acuerdan antes de que nadie empiece. Esa es la parte que los equipos se saltan, y saltársela es lo que convierte una tarea de dos días en una semana de aclaraciones.

No tiene por qué ser pesado. Un desarrollador que lee el borrador y pregunta “¿qué debería pasar si todavía no tiene ningún pedido?” es el proceso entero funcionando: la pregunta es barata ahora y cara cuando el código ya existe.

Escríbelos donde vive el trabajo, no en un mensaje de chat. Los criterios que solo existen en el recuerdo que alguien tiene de una reunión producen exactamente la discusión que venían a evitar.

Dónde acaban importando

Dos sitios, y son la razón de que merezca la pena el esfuerzo.

La aceptación. Quienes hacen las pruebas de aceptación necesitan algo contra lo que aceptar. Sin criterios, aquello se convierte en una encuesta de opiniones sobre un software que alguien ya ha pagado.

El triaje de errores. La discusión más tediosa del software es si algo es un defecto o una petición de cambio, y la decide lo que se acordó. Un defecto es un comportamiento que contradice un criterio; cualquier otra cosa es una petición nueva, por razonable que sea. Los equipos sin criterios escritos tienen esa discusión una vez por entrega, para siempre.

Por eso mismo el informe de un defecto debería decir qué se esperaba además de qué ocurrió - es la misma frase que el criterio al que contradice.

La guía de informes de error cubre el resto de lo que ese informe necesita, y su plantilla tiene una línea para el comportamiento esperado.

La versión corta

Condiciones, escritas antes del trabajo, acordadas entre quien lo pide y quien lo va a construir, lo bastante concretas como para que dos personas no puedan discrepar sobre si se cumplen. Con una lista de comprobación suele bastar; dado-cuando-entonces cuando el estado de partida decide el resultado. Cubre qué pasa cuando las cosas fallan, no solo cuando funcionan.