BDD/TDD contra JAD?

Question

He estado proponiendo que mi lugar de trabajo implemente el desarrollo impulsado por el comportamiento, al escribir especificaciones de alto nivel en un formato de escenario, y de tal manera que uno pueda imaginar escribir una prueba para ello.

Sé que trabajar contra las especificaciones comprobables tiende a increase developer productivity. Y ya puedo pensar en varios ejemplos donde este sería el caso en nuestro propio proyecto.

Sin embargo, es difícil demostrar el valor de esto para el negocio.

Esto se debe a que ya tenemos un proceso de desarrollo de aplicaciones conjuntas (JAD) en el que los desarrolladores, la administración, la experiencia del usuario y los evaluadores se reúnen para acordar un conjunto común de requisitos.

Entonces, se preguntan, ¿por qué los desarrolladores deberían trabajar contra los casos de prueba creados por los evaluadores? Estos son para verificación y se basan en las especificaciones de nivel superior creadas por el equipo de UX, que los desarrolladores actualmente trabajan.

Esto, dicen, es suficiente para los desarrolladores y no es necesario cambiar la forma en que se escriben las especificaciones.

Parecen tener un punto.

¿Cuál es el beneficio real de BDD/TDD, si ya tiene un equipo de prueba cuyos casos de prueba son totalmente compatibles con las especificaciones de alto nivel que actualmente se les dan a los desarrolladores?

Answer 1

Si desea convencerlos de que esto ayudaría, lo más importante que debe hacer es identificar un problema que resolvería.

¿Qué está sucediendo en su situación que usted piensa que esto mejoraría?

El principal beneficio de BDD es mejorar la comunicación entre los interesados ​​y los desarrolladores.

Si está produciendo un código que no supera estas pruebas de verificación, los desarrolladores han entendido su especificación de forma diferente a los probadores, lo que significa que la especificación carece de claridad y BDD definitivamente podría mejorar la situación.

También hay partes del proceso que como desarrollador puede trabajar sin cambiar todo el proceso del equipo. Si te enfocas en el nivel de pruebas unitarias y realizas el desarrollo tradicional basado en pruebas, eso te puede hacer más productivo.

Answer 2

Puede ser útil pensar en BDD en su forma más ligera; como discusiones sobre escenarios particulares.

Tiene sus casos de uso. Usted tiene sus requisitos. Ahora quiere verificar que tiene una muy buena comprensión de esos. Así que alguien, tal vez un desarrollador, tal vez un probador, dice: "Está bien. Solo para verificar que entiendo ... dado que comenzamos con este >, cuando un usuario hace <este> entonces debe ocurrir >. ¿derecho?"

Y el probador dirá: "Sí, así es".

Luego, el UX o el analista dice: "Bueno, es correcto a menos que < este otro contexto exista >".

Al tener discusiones sobre los escenarios, el tiempo necesario para garantizar que todos tengan un entendimiento común se reduce drásticamente. Normalmente pasamos por alto los escenarios obvios y nos centramos en los casos extremos; sobre nuevos términos de dominio, conceptos que difieren entre departamentos, interacciones difíciles con sistemas heredados.

Los desarrolladores realmente no funcionan fuera de los casos de prueba. Trabajan según los requisitos y los criterios de aceptación exactamente de la misma manera que siempre lo hacen. Los casos de prueba simplemente se convierten en un ejemplo del tipo de cosas que podrían esperar; escenarios en los que los usuarios se benefician o transfieren el valor del sistema. La automatización de esos casos de prueba puede ser útil porque el esfuerzo de prueba aumenta aproximadamente de forma proporcional al tamaño del código base.

BDD funciona mejor en proyectos donde hay una gran incertidumbre sobre los requisitos o el dominio, y la comprensión de las personas es muy diferente. Si su proyecto ya funciona, apéguese a él. Tal vez podrías echar un vistazo a dónde está la brecha más grande entre crear ideas e implementarlas, y si BDD te ayuda en ese espacio, úsala; de lo contrario, elige algo más. Lo que haces suena muy similar a los procesos de BDD de todos modos.

Answer 3

Esta es una excelente pregunta, de hecho es la cuestión de "fondo" cuando se trata de BDD. Uno de los mayores desafíos de TDD o prueba de unidad de escritura es que los desarrolladores nunca parecen tener una perspectiva general y empresarial de las cosas. El ejercicio de escribir las especificaciones y las pruebas de unidades generadoras para probar los escenarios reales de "negocios" ayuda a los desarrolladores a superar su "artesanía" y comprender la perspectiva comercial. Echa un vistazo a este post para más detalles,

http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/

Answer 4

simplemente me encontré con esta pregunta y pensé que pesan porque realmente es una pregunta muy interesante.

La metodología solo se rompe si todo el equipo siente que está rota y si el resultado final es un proyecto fallido.

Si el sistema actual funciona bien, entonces realmente debe preguntarse: "¿puedo trabajar así, aunque prefiera BDD/TDD?". Si su respuesta es no, y siente que puede ser infeliz trabajando para cualquier otro sistema, entonces tal vez eso indique que su carrera necesita mudarse a otro lugar. Si es así, abrace el sistema.

En realidad, si fuera yo, aceptaría un nuevo sistema de todos modos. Por un lado, si te da la oportunidad de familiarizarte íntimamente con él, y eso te daría tiempo para emitir un juicio más informado sobre los pros y contras relativos, y con ese conocimiento podrías sugerir posibles mejoras en una fecha posterior si fueron necesarios.

Al final del día, una metodología es tan buena como su resultado final. Software de trabajo, y la satisfacción de todas las partes interesadas.

:-)