Behavior Driven Development (BDD)

Behavior Driven Development o BDD (Desarrollo Dirigido por Comportamiento) esta técnica es a mi parecer una de las mas importantes en cuanto al desarrollo de software, veamos que es BDD,  BDD es una técnica que nos permite plasmar un requerimiento en código, asegurándonos que lo que se desarrolle va directamente a solucionar un problema muy específico de negocio, pero cómo se logra esto? inicialmente es teniendo pláticas con la gente de negocio, cliente o product owner para entender lo más claro el problema a resolver, esto se deberá de hacer en juntas pequeñas en las que lo ideal es que estén representantes de desarrollo, pruebas y negocio y así de esta forma generar un requerimiento "estable" entre los tres, tratando de en ese momento identificar no solo el problema, sino una posible solución a él y ciertos escenarios que serán el boundary del desarrollo.
Luego de esto lo ideal es plasmar el requerimiento en forma de los escenarios o comporatmiento esperado en alguna herramienta de pruebas funcionales automatizadas como jbehave, robot, gauge o fitnesse en las que se pueden crear los escenarios de pruebas usando un lenguaje apto para la gente no técnica, acá hay que mencionar otra herramienta muy ampliamente aceptada en el medio que es la notación Gherkin en la que los requerimientos se escriben en tres partes siendo éstas Given (dado que cierto prerequisito o estado del sistema), When (cuando una acción específica ocurre sobre ese estado del sistema), Then (que sucede con el estado del sistema), veamos un ejemplo de la notación:
Dado que soy un empleado que tiene derecho a 5 días de vacaciones.
Cuando pido vacaciones por 3 días.
Entonces se me conceden mis días de vacaciones y me quedaré con 2 días por disfrutar.
Usando esta notación no solo es algo que la gente de pruebas, desarrollo y negocio sabe interpretar, sino que define claramente el comportamiento esperado.
Lo que sigue ahora es empezar con el desarrollo, pero ahora la asignación del equipo de desarrollo será hacer pasar los tests creados en la herramienta, volviéndose esta su principal tarea.... espera!!!!!, cuales test? pues las pruebas de aceptación al final de cuentas son tests, es decir, la chamba del equipo de desarrollo es hacer que el "Entonces" suceda cuando el "Cuando" es ejecutado bajo la circunstancia descrita en el "Dado", con esto se logra que el desarrollador tenga un foco muy claro y algo que le define cuando el desarrollo ya está terminado (cuando ya ha hecho pasar todas las pruebas descritas).
Bien, ahora ya tenemos varios tests escritos en una herramienta y código que hace pasar esos tests y que por ende ya resuelven el problema, ahora, que pasa con lo ya desarrollado? pues bien.... yo creo que ya lo podemos pasar a producción no?... lo ideal es que si, es decir, si se tiene una buena cobertura del comportamiento esperado, incluyendo pruebas no funcionales, pues si, ya se puede pasar a producción con la bendición del Yorch sin ningún problema, pero que pasa con nuestros amigos de pruebas? pues bien, ellos ya hicieron su trabajo (y muy bien hecho) al inicio del desarrollo, agregándole calidad al desarrollo creando los escenarios de pruebas necesarias (tratando de dar la mejor cobertura a nivel negocio).
Además de todo esto, ganamos pruebas de regresión automatizadas por lo que ahora ya no hay que dedicar cada vez más a la ejecución manual de las mismas cada vez que se agrega una funcionalidad al sistema, lo cual hace que el tiempo de entrega se acorte casi un 60%, lo cual hace que nuestros clientes sean aún mas felices, lo cual hace que la empresa gane más dinero, lo cual hace que... bueno iba a decir que nos aumenten el sueldo, pero eso casi no pasa jeje.
Además de rapidez en la entrega ganamos documentación a nivel de negocio que nos dice con un nivel de certeza del 100% lo que el sistema hace ya que se puede asegurar que si un test pasa, el sistema lo hacen, si un test no pasa, el sistema no lo hace.
Bueno, muy bonito todo hasta acá, pero no todo es color de rosa ni huele a nalguita de bebé, el problema (y es donde mas hay que luchar) es que hay que cambiar hábitos y formas en la empresa,  tales como el proceso que puede ser anticuado creando casos de uso, o el hecho de que no estén dispuestos a trabajar hombro a hombro con el desarrollador o que la gente de pruebas esté ya en la sinergia de que las pruebas van al último y eso no se puede cambiar, definitivamente esto es lo más difícil, el cambio de mentalidad, pero eso lo abordaremos más adelante... bueno, mejor no, mejor lean al respecto en el blog de mi amiga Rox, ella está más metida en estos asuntos y tiene más autoridad para hablar de eso que yo.