¿BDD es realmente escribible por no programadores?

El desarrollo basado en el comportamiento con su emblemática sintaxis de escenarios "dado-cuándo-entonces" últimamente ha sido muy publicitado para sus posibles usos como un objeto límite para la evaluación de la funcionalidad del software.

Definitivamente estoy de acuerdo en que Gherkin , o la secuencia de comandos de definición de características que prefiera, es un DSL legible para el negocio y ya proporciona valor como tal.

Sin embargo, no estoy de acuerdo con que sea escribible por no programadores (como lo hace Martin Fowler ).

¿Alguien tiene cuentas de escenarios escritos por no programadores y luego instrumentados por desarrolladores?

Si efectivamente existe un consenso sobre la falta de capacidad de escritura, ¿vería un problema con una herramienta que, en lugar de comenzar con los escenarios e instrumentarlos, generaría escenarios legibles para el negocio a partir de las pruebas reales?

Actualización: con respecto a la herramienta "generador de escenarios", por supuesto, no adivinaría el lenguaje de negocios mágicamente;) Pero, al igual que actualmente utilizamos los comparadores de expresiones regulares para crear pruebas en un enfoque de arriba hacia abajo (en la dimensión de abstracción), podríamos usar constructores de cadenas para crear escenarios en un enfoque ascendente.

Un ejemplo de "solo dar una idea":

Given I am on page ${test.currentPage.name}
And I click on element ${test.currentAction.element}
…

Lo he visto. No terminó bien.

Creo que el pepino es engorroso (<- lol: D) abstracción por esta razón exacta. Demasiado difícil para las personas no técnicas escribir por sí mismas; demasiado detallado para gente técnica.

Las personas no técnicas simplemente no han aprendido a pensar como programadores. Es nuestro privilegio comprender el conocimiento abstracto, desglosarlo, construirlo de nuevo y aún así poder escapar de la ambigüedad con éxito. Eso es lo que nos pagan.

Si efectivamente existe un consenso sobre la falta de capacidad de escritura, ¿vería un problema con una herramienta que, en lugar de comenzar con los escenarios e instrumentarlos, generaría escenarios legibles para el negocio a partir de las pruebas reales?

La herramienta en sí no podrá generarlos. La computadora no sabe nada sobre el dominio comercial. Al final, el programador sería responsable de dibujar lo que debe generarse de todos modos e incluso entonces, es probable que esos escenarios sean demasiado detallados / crípticos para sus usuarios finales.

Parte de la dificultad en términos de que el cliente redacte un documento de especificaciones es que el cliente a menudo no sabe cómo traducir las cosas que el cliente quiere a un idioma que realmente describa lo que el cliente necesita. Si bien el cliente puede decir que desea que exista un determinado comportamiento en un sistema, generalmente no está tan preocupado por las minucias hasta que haya visto y utilizado y experimentado que el software funciona de una manera que el cliente considera que no coincide con sus necesariamente.

Cuando los clientes describen un proceso de negocios, a menudo dejan fuera mucha información relevante. A menudo, esta información se relaciona con cosas sobre un proceso que comúnmente se entienden dentro del dominio particular del cliente y que, por lo tanto, se da por sentado y a menudo no se transmite al programador. En otras ocasiones, el cliente en realidad no sabe cómo lidiar con todas las condiciones límite dentro de un sistema, y ​​está buscando ayuda del programador. A veces es todo un caso simple de usabilidad, con el cliente pensando que quiere que algo funcione de una manera, pero luego cambia de opinión cuando se hace más claro que las cosas deberían funcionar de manera diferente.

Ok, basta de "relaciones con los clientes 101 para programadores". La pregunta es si todavía hay valor en hacer que el cliente use un DSL legible para el negocio para definir cómo definir una especificación. Creo que con orientación, la respuesta es un "sí" tentativo, y digo tentativo porque la siguiente pregunta que viene a la mente es, ¿por qué un cliente crearía un DSL cuando puede hacer que un programador defina más fácilmente uno que ¿Proporcionar a un cliente un lenguaje simple pero rico para definir cómo debe funcionar un sistema?

Cuando haya proporcionado a un cliente un lenguaje para describir cómo le gustaría que funcione un sistema, terminará con declaraciones que dicen algo como:

"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".

Este tipo de declaración termina describiendo un requisito de una manera muy clara, proporcionando la forma general que el cliente básicamente desea que asuma el sistema, u otra forma de verlo es que el cliente está describiendo qué es el sistema. Si desea que su cliente piense un poco más sobre las cosas, puede pedirles que describan las reglas que la característica debe cumplir utilizando una serie de afirmaciones similares, tal vez a:

"Given 'some system state', When 'some action occurs', Then expect 'some result'

Nuevamente descripciones muy claras, esta vez sobre cómoEl sistema debe comportarse. La cuestión es que esto no reemplazará la necesidad de que un desarrollador de software complete todos los espacios en blanco y descubra más detalles de los que el cliente puede tener conocimiento periférico. Si bien el cliente puede ser 'capacitado' por el programador para describir características y comportamientos en un formato agradable para el programador, el cliente realmente no tendrá las habilidades o el conocimiento para generar casos de prueba significativos, ni para proporcionar la implementación código. Creo que este fue el punto del artículo de Martin Fowler al que se ha referido el OP. Entonces, sí, el software en sí no puede ser escrito por el cliente, pero la descripción del software ciertamente puede, y en mi humilde opinión, debe ser escrita por el cliente. Por lo que vale, no leí el artículo de Fowler diciendo que el cliente no debería

Siento que los programadores a veces podemos olvidar que nuestros clientes son generalmente muy inteligentes en cuanto a su comprensión de sus negocios y procesos comerciales, ciertamente mucho mejor que nosotros. Cuando no tienen un programador que les diga cómo construir un sistema de software, los clientes generalmente recurren a otros medios, quizás menos eficientes, para resolver sus problemas particulares de gestión empresarial. Con esto me refiero a bases de datos simples (piense en Access) u hojas de cálculo, o incluso en libros escritos a mano, y con reglas y procedimientos bien definidos para administrar esos procesos. Lo que a muchos clientes les falta no es un medio para determinar cómo debe funcionar un sistema, sino cómo debe construirse y, lo que es más importante, qué tan eficientemente se describen las reglas de comportamiento de un sistema a las personas queno tienen las habilidades para construir realmente el sistema.

Si efectivamente existe un consenso sobre la falta de capacidad de escritura, ¿vería un problema con una herramienta que, en lugar de comenzar con los escenarios e instrumentarlos, generaría escenarios legibles para el negocio a partir de las pruebas reales?

Creo que esto está analizando el problema al revés. Vería un gran problema con una herramienta que genera documentación a partir de pruebas si esa documentación tuviera la intención de representar una especificación de alguna manera. Para probar un escenario, debe comprenderlo, por lo tanto, el escenario ya debe existir para que ambos definan una prueba para él. Si describe el escenario en una sintaxis BDD, entonces ya lo ha especificado y, por lo tanto, solo puede instrumentar los escenarios después del hecho. Si, por otro lado, tuviera una herramienta que le permitiera al cliente describir un sistema en un buen DSL amigable con la programación, y si esa herramienta pudiera usarse para generar las plantillas de código que se usarían como un conjunto de pruebas, entonces yo ' Yo diría que habría un gran valor en tal herramienta. No vería al cliente sacar a los programadores de la ecuación, y ayudaría a reducir el esfuerzo requerido para cumplir con los deseos del cliente y generar requisitos codificados por prueba de una manera BDD, y tal vez haría que los deseos del cliente se entiendan más fácilmente. Sin embargo, no sería un sustituto de tener a mano un desarrollador de software experimentado para ayudar al cliente a separar las necesidades del cliente de sus deseos.

He visto desarrolladores escribir escenarios; los evaluadores escriben escenarios e incluso el propietario de un producto escribe escenarios. También he tenido conversaciones explícitamente diseñadas para mostrar escenarios: "Dado <este otro contexto>, ¿cuándo debería suceder entonces?" - y anotó las palabras que usa el negocio.

Los mejores resultados que obtuve fueron tener una conversación con el propietario del producto mientras estaba en la oficina, capturarlos en un wiki y luego enviárselos para que pudiera corregirlos y agregar más. Encontró una pareja que habíamos extrañado en nuestras conversaciones. Eso se sacudió.

Los peores escenarios que he visto son los que los desarrolladores escribieron ellos mismos sin ninguna conversación con el negocio. Puedo decirlo porque usan términos como "Cuando realizo una búsqueda" o "Cuando envío el formulario con una fecha de hoy + 3". Por lo general, no son escenarios muy interesantes, muchos de ellos, un nivel de detalle demasiado bajo y, por lo tanto, completamente imposible de mantener. El negocio tampoco lee estos.

Mucho mejor para centrarse en las conversaciones de la OMI. He visto algunos equipos hacer esto ahora por un par de meses con grandes mejoras en la calidad, independientemente de la automatización. Un equipo logró que la automatización funcionara en un entorno muy difícil algunas semanas después, ¡para alegría del probador! Pero en realidad, mientras el equipo tenga conversaciones y use escenarios para dibujar otros escenarios, no creo que importe quién los escriba.

Mi experiencia es que es mejor dejar que el BA (Business Analyst) escriba los GWT ( Given-When-Then ) s (experiencia usando SpecFlow). El BA puede traducir los requisitos del Cliente al GWT y la empresa puede leerlo. Los clientes entienden los sistemas, pero no tienen la tecnología para escribir los requisitos de una manera que podamos usar.

Idealmente, el BA escribiría algo de GWT, yo haría algunas revisiones, el BA revisaría / revisaría repetir hasta que el BA y las empresas tuvieran confianza en la cobertura. Prácticamente la licenciatura me daría un borrador que yo limpiaría y haría el trabajo. El Negocio se encoge de hombros diciendo que está seguro y luego se pregunta por qué no cubrió algunas áreas en las que nadie pensó.