Criterios de aceptación por elemento de trabajo que puedan convertirse en pruebas

Objetivo

Hacer que el «terminado» de un elemento de trabajo individual sea decidible antes de que empiece el trabajo, de modo que quien desarrolla, quien revisa y quien lo solicitó coincidan en los mismos ejemplos.

Requisitos previos

Un elemento de trabajo con un propósito enunciado (quién necesita qué y por qué), acceso a la persona que puede responder preguntas de dominio, y un lugar donde los criterios vivan junto al elemento.

Pasos

1. Escribir la regla en una frase, y después los ejemplos. La referencia de Gherkin describe esta forma: un contexto inicial (Given/Dado), un evento (When/Cuando) y un resultado esperado (Then/Entonces), y recomienda de 3 a 5 pasos por ejemplo para que se mantenga legible como especificación.
2. Cubrir el caso principal, cada límite y las rutas de fallo. Un conjunto de criterios para «limitar las subidas a 10 MB» tiene al menos: exactamente 10 MB aceptados, 10 MB más un byte rechazados con el mensaje especificado, y el rechazo sin dejar ningún archivo parcial.
3. Usar valores concretos, no adjetivos: «el saldo muestra £430» en lugar de «el saldo es correcto». Los propios ejemplos de Gherkin contrastan «hay dinero en mi cuenta» con «mi cuenta tiene un saldo de £430».
4. Mantener la interacción de la persona usuaria fuera del Given/Dado, y mantener los detalles de implementación fuera de todo: los criterios describen el comportamiento visible en el límite que ve la persona usuaria o el cliente.
5. Leer cada criterio y preguntar: ¿podría alguien que probara el sistema sin haber visto nunca el código decidir si pasa o falla solo con este texto? Si no, reescribirlo.
6. Marcar qué queda deliberadamente fuera del alcance de este elemento, de modo que «se te olvidó X» quede respondido por el elemento y no por la memoria.
7. Antes de la implementación, quien desarrolla propone cualquier ejemplo que falte; quien lo solicitó lo confirma. Los desacuerdos que se encuentran aquí son más baratos que en la revisión.
8. Convertir los ejemplos en pruebas automatizadas donde el límite lo permita (API, lógica de dominio), y en una lista de verificación manual donde no (diseño visual). Enlazar la prueba o la lista de verificación desde el elemento.

Resultado esperado

La revisión y la aceptación se convierten en una comparación con los ejemplos enumerados; el alcance que se expande de forma no controlada aparece como un ejemplo nuevo que hay que negociar, en lugar de asumirse.

Límites y base de verificación

Los ejemplos no pueden enumerarlo todo; los requisitos no funcionales (latencia, accesibilidad) necesitan un objetivo medible en lugar de un escenario. Las herramientas de Gherkin son opcionales; la disciplina está en los ejemplos, no en el ejecutor. Método sintetizado a partir de la referencia citada y de la práctica común; no se afirma ningún efecto sobre la tasa de defectos.