¿Qué nivel de detalle para escenarios BDD?

¿Es apropiado que los escenarios de BDD tengan una especificidad de estilo "haga clic aquí"?

He leído muchos ejemplos en los que se establecen escenarios para evitar cualquier interacción de interfaz de usuario en particular, pero herramientas como SpecFlow aparentemente requerirían este nivel de detalle.

¿Es apropiado exigirle al BA que escriba una historia que contenga escenarios de alto nivel y luego los reduzca a un nivel más técnico (y de elementos específicos) durante la fase de los 3 amigos?

Por ejemplo, es esto apropiado:

Given the user is on /search
And the "Jeff" is entered into the field "searchinput"
When the "Search" button is clicked
Then the page displayed is /results/Jeff
And the fields displayed include "Name"
And the second field displayed is "Post Code"

El ejemplo de la historia y el ejemplo de herramientas en esta página parecen ser incompatibles si intentamos pasar de uno a otro (ignorando el hecho de que se encuentran en procesos comerciales muy diferentes): https://en.wikipedia.org/wiki/ Desarrollo impulsado por el comportamiento

Diría que el detalle de los escenarios de BDD debe estar en ese nivel donde el valor comercial se muestre bien y sea comprensible para la gente de negocios. Más profundo que eso puede ser importante para los técnicos. Esta es una abstracción. Pero, si automatiza estos escenarios, debe hacerlos más detallados para poder reutilizar bien los pasos y reducir el costo de mantenimiento.
Gracias. Para los empresarios no técnicos que escriben estas historias y los desarrolladores técnicos que realizan el trabajo, ¿en qué punto, y cómo, se cierra esta brecha?
Yo creo que depende de cada caso. Conozco gente de negocios que se siente cómoda con más detalles y también conozco gente de negocios que no. Necesitamos encontrar el equilibrio adecuado para hacer nuestro trabajo de entrega y mantenerlos felices.

Respuestas (1)

Su nivel de comportamiento es correcto. La mayoría de los profesionales (incluido yo mismo) recomendarían que lo redactes de una manera que sea menos específica para la implementación. Por ejemplo:

Given the user is on the search page 
When the user searches for "Jeff"
Then the results page is displayed
And the "Name" field is displayed with the value "Jeff"
And the "Post Code" field is displayed with the value "80273"

Esto es independiente de la implementación, lo que significa que no necesita conocer la implementación con anticipación y puede abordar múltiples implementaciones (web y móvil, por ejemplo) más fácilmente.

También ajusté la redacción para que sea más fácil de automatizar. Si un PO o alguna otra persona no técnica está escribiendo la prueba, no esperaría que supieran cómo hacer algunos de estos cambios. Espero que los desarrolladores los reconozcan y ayuden allí. Específicamente, las últimas dos líneas ahora tienen el mismo patrón y son más fáciles de automatizar, y todo el escenario podría ejecutarse con muchos valores diferentes conectados para cada uno de esos elementos entre comillas de manera muy limpia.

Finalmente, preguntaste en un comentario cómo cierras la brecha. Mi recomendación es escribir el caso de prueba antes de conocer la implementación. Eso te obliga a usar más este lenguaje independiente de la implementación.

Gracias. Mi preocupación es que estoy escribiendo estas historias en un entorno (bastante) diferente al que solía trabajar. El problema principal es que las personas que conocen los sistemas de adentro hacia afuera son los BA y no son ágiles. Los desarrolladores, que son (en su mayoría) ágiles, no conocen los sistemas. Mi objetivo es usar scrum para ayudar a todos a aprender y ser productivos al respecto. (Los problemas típicos ocurren, como estoy seguro de que puedes imaginar).
¿Qué nivel de detalle para escenarios BDD?
RespuestasAquíPolítica de privacidad1y, 0v