Según tengo entendido , el formato Dado/Cuando/Entonces se usa cuando el proyecto va a seguir BDD (Desarrollo Impulsado por el Comportamiento). Así, los criterios de aceptación se utilizarán para las pruebas automatizadas , mientras que las listas de verificación están destinadas a las pruebas manuales . La pregunta es: "¿Cuándo debemos usar el formato de lista de verificación para describir los criterios de aceptación de Historias de usuario y cuándo debemos usar el formato Gherkin ?"
Depende, ¿ayuda al equipo a usarlos mejor como requisitos y mejora la comunicación con las partes interesadas? Entonces sí. Simplemente hable con el equipo sobre cuál cree que le da más valor al proyecto.
GTW agrega un poco de trabajo extra. También puede hacer que sea más difícil de leer y comprender en lugar de un criterio de aceptación de alto nivel de una línea , ya que ahora necesita leer tres o más oraciones.
Si usa BDD o los automatiza después de todos modos, entonces parece mejor comenzar con GWT desde el comienzo de una tarea. Personalmente, creo que GWT se trata de comunicación entre desarrolladores y partes interesadas no técnicas. Si no lo usa de esta manera, será una sobrecarga, tal vez use TDD en su lugar.
Usaría INVEST y verificaría que los requisitos y los criterios de aceptación sean lo suficientemente claros para el equipo durante la estimación de las unidades de trabajo.
El objetivo principal de las pruebas manuales (también conocidas como pruebas exploratorias (también llamadas solo pruebas, ya que ninguna máquina realmente prueba )) es generar nueva información sobre el producto; además de los errores, esta técnica plantea preguntas sobre requisitos no funcionales, oportunidades de mejora de UX, etc. .
Esta nueva información crea nuevos criterios de aceptación, que deberían incluirse en los escenarios Dado/Cuándo/Entonces, incluso a posteriori (recordando el valor ágil 'Responder al cambio sobre seguir un plan').
Agregar, los escenarios Dado/Cuándo/Entonces no tiene nada que ver con las pruebas. Son los requisitos de la característica. Toda la información sobre el comportamiento de la función debe incluirse como un escenario Dado/Cuándo/Entonces (directa o indirectamente, mediante enlaces a sitios/archivos (que deberían ser muy raros)), para permitir que todos los miembros del equipo entiendan cómo debe funcionar el sistema. comportarse.
Si un escenario se puede verificar automáticamente, genial; pero incluso si no puede ser verificado por una máquina, debe incluirse en el archivo .feature.
João Farias