Continuando con lo que hemos conversado acerca de Gherkin, saber escribir criterios de aceptación en este formato, no solo mejora la comunicación, sino que también facilita la validación y automatización de pruebas. Sin embargo, muchas veces los equipos caen en errores que terminan generando más confusión.
Veamos cómo escribir criterios efectivos con ejemplos concretos.
🟢 Estructura correcta de un criterio de aceptación
Un buen criterio de aceptación debe:
✅ Ser claro y sin ambigüedades.
✅ Describir un solo escenario por criterio.
✅ Evitar referencias a elementos de UI o implementación técnica.
🔹 Ejemplo de un criterio bien escrito:
Scenario: Compra de un producto de belleza en una tienda online con cálculo de IVA y validación de dirección de envío
Given un usuario con productos de belleza en su carrito, con un valor total de USD 1500
And el usuario ha iniciado sesión con una cuenta activa
And el país de envío seleccionado es México
When el usuario procede a hacer checkout
Then el sistema debe calcular el total de la compra como USD 1650 (incluyendo 10% de IVA)
And se debe solicitar una dirección de envío válida dentro de México
And el usuario debe poder ver el resumen detallado de la compra (subtotal, IVA y total final)
¿Cuáles aspectos se toman en cuenta?
1. Detalle del producto y valor total inicial: Ahora se especifica “productos de belleza” y el valor exacto de USD 1500, para dar contexto.
2. Condición del usuario: Se aclara que el usuario está logueado con cuenta activa (evita asumir estados del usuario).
3. País de envío: Se incluye que el país de envío es México, ya que afecta el IVA y la validez de la dirección.
4. Cálculo de IVA detallado: Se especifica el porcentaje y se detalla cómo se llega a USD 1650.
5. Validación de dirección: Se solicita dirección válida específica para México, eliminando ambigüedades.
6. Resumen final claro para el usuario: Se asegura que el usuario vea el desglose (subtotal, IVA, total).
🔹 Ejemplo de un criterio mal escrito:
Scenario: Compra de productos
Given un usuario con productos en el carrito
When da clic en “Pagar”
Then si tiene dirección guardada, se usa esa, de lo contrario debe ingresar una nueva.
🚨 ¿Cuál es el problema?
👉 No se define claramente qué sucede en cada caso.
👉 Se validan dos escenarios en un solo criterio.
👉 Se menciona un botón específico de la UI (“Pagar”), lo que acopla la prueba a la interfaz gráfica.
🟢 Buenas prácticas al escribir criterios de aceptación
1️⃣ Divide los escenarios complejos. Si hay múltiples condiciones, usa varios escenarios en lugar de mezclar lógica en un solo criterio.
2️⃣ Evita lenguaje técnico. No menciones variables, código ni detalles de implementación.
3️⃣ Hazlo atómico. Cada escenario debe validar un solo caso específico.
🟢 Conclusión
Aplicar estas buenas prácticas hará que los criterios sean más efectivos y fáciles de validar. Pero, ¿qué pasa cuando se cometen errores comunes al definirlos?
En el siguiente artículo hablaremos de los problemas más frecuentes y cómo evitarlos. 👀
