Estoy buscando pruebas de BDD dentro de un escenario de melé y me doy cuenta de que los escenarios de BDD son más similares a las especificaciones que a las pruebas.¿Cuándo deberían escribirse los escenarios de prueba de BDD?
Por lo tanto, ¿deberían escribirse antes de que los desarrolladores inicien la planificación previa para que se haya identificado toda la funcionalidad que permita una mejor estimación, priorización, etc. en esa reunión?
Generalmente, en Scrum desea historias de usuarios que también tengan condiciones de satisfacción para acompañarlas. Es decir, si se cumplen estas condiciones, yo, como Propietario del Producto, estaré satisfecho de que la historia esté completa.
Lo mejor es que el propietario del producto lo escriba y mucho mejor si está escrito en el formato Dado/Cuando/A continuación. De esta forma, el equipo puede crear las pruebas BDD basadas en las condiciones de satisfacción. Cuando las pruebas pasan, la historia está completa.
Debe haber tantas condiciones de satisfacción como el Propietario del producto considere necesario para confirmar que la historia se ha implementado y que estas condiciones deben prepararse a tiempo para la reunión de planificación del sprint. No necesitan ser codificados, pero deben escribirse para que el equipo tenga una idea de lo que se espera que complete la historia.
El equipo puede agregar sus propias pruebas de BDD durante el sprint a medida que surgen las cosas, pero la historia no está completa hasta que pasan las pruebas de BDD iniciales.
Espero que haya mencionado el desarrollo impulsado por el comportamiento. Si estoy en lo cierto, es un proceso de interacción con los desarrolladores, el control de calidad y los participantes no técnicos o comerciales. también es un propósito y beneficio del código de Desarrolladores. Puede iniciar el escenario de scrum mientras planifican previamente.
La estimación y la priorización no forman parte de esta.
si está buscando BDD (también conocido como Desarrollo impulsado por prueba de aceptación), es posible que desee comenzar a escribir Pruebas de aceptación lo suficientemente temprano antes de que se lleve a cabo la Planificación de Sprint. Algunos otros enfoques "más ágiles" tienden a posponer esto hasta el último momento responsable, y he estado entrenando a un par de equipos donde los Criterios de aceptación se refinan con el tiempo también durante el Sprint.
Los "probadores" del equipo de desarrollo trabajan en estrecha colaboración con el propietario del producto durante la preparación de la acumulación para el próximo Sprint (se llama anticipación) y también durante el sprint actual, enriquecen los criterios de aceptación cuando ver ajuste de acuerdo con el PO.
Depende mucho de cómo se ejecutan esas pruebas ... si se puede automatizar, las cosas son mucho más claras :-) Hacemos un uso extensivo de Cucumber o Fitnesse para automatizar las pruebas de aceptación, y como lo haría con TDD (sin la A), trataría de hacer eso antes de que tenga lugar un compromiso, al menos en un nivel básico (no necesita que todos ellos estén definidos, recuerde que no debe parecer un contrato)
El objetivo de BDD es impulsar el desarrollo del software desde una perspectiva de comportamiento, que debería proporcionarle una "manera" bastante clara de cómo y cuándo escribir los criterios de aceptación. Los encontré muy útiles en combinación con la lista de verificación INVEST para User Stories y la definición de Ready for you Backlog.
HTH ANdreaT
Si por el TDC que quiere decir "Desarrollo impulsado por el comportamiento", entonces usted es quizás siendo disparado por poner la palabra 'pruebas' en ese país.
No son pruebas, aunque obtendrá pruebas gratuitas de ellas. Si piensas en ellos como pruebas, los usarás mal.
Son especificaciones. Si te acercas a ellos de esa manera, puedes ver cómo encajan en tu proceso.
Depende de ti, pero obtendrás el mayor beneficio al forzarte a ti mismo de pensar en ellas como pruebas, y en su lugar ser consecuentes al tratarlas como especificaciones. Nada puede impedir que los utilices indebidamente (como pruebas), pero el mal uso de ellos te garantizará que no obtienes el beneficio del enfoque, y es sustancial.
Gracias Bret, así es como ahora me estoy acercando a ellos. –
Gracias Vijay, pero creo que puede haber perdido el sentido de la pregunta que no es que la estimación y la priorización son parte de BDD más que la salida de BDD es útil para la estimación y la priorización. –