La siguiente discusión se inicio bajo el nombre «Interesante discusión sobre BDD – Que opinas?» en el grupo de discusión en LinkedIn Spain Testing Professionals, por Anko B., y yo la he lanzando dentro de nuestro grupo de discusión TESTING & QA.
Cuerpo del contenido principal
Ya hace unos años James Bach publico una opinion pequeño pero directo sobre BDD y en especial Cucumber. El threat de comentarios y respuestas abajo también es bastante entretenido.
Como veo que se esta creciendo.. es tiempo de discutirlo..
Personalmente veo que en el mundo de desarrollo hay un pensamiento generalizado que con BDD tambien estas haciendo testing y que sea mas rápido, etc etc. Esto suena bien en los oídos de managers de desarrollo, pero como testers debemos parar esto antes que se ponga de moda..
Dejemos ya de tonterias y empezamos a hacer casos de prueba y reportar bugs..
Tanto amigismo entre testers y desarolladores no nos va a llevar a un incremento proyectos fracasado..como ya se esta viendo desde la implementacion de Scrum..
Disparador del debate:
http://www.satisfice.com/blog/archives/638
A continuación, los comentarios que van dejando sus miembros
Comentario 1
Usamos BDD e estamos migrando pra Cucumber aqui na empresa com sucesso… frameworks ágeis, como Scrum e Kanban, são muito flexíveis e você precisa saber adaptar quais pontos são mais adequados a sua empresa e a exigência do seu cliente, o BDD, com seus testes menores e mais simples, focados na funcionalidade, é muito importante quando você tem o processo bem sólido, porém se o processo for frágil e viver sendo quebrado não é culpa do BDD que as coisas não dêem certo!
Comentario 2
Estimado Roberto, te paso la siguiente url con un artículo relacionado
Un fuerte abrazo
Comentario 3
Gustavo, el articulo es una buena explicación, pero no estoy en absoluto de acuerdo con tus conclusiones.
* hace fácil leer y escribir test cases de aceptación por cualquier miembro del equipo*
Al contrario, primeramente porque no son testcases. No prueban nada.
Esto que todo hablan lo mismo es lo que intentaron con Esperanto! No funciona. Limita la creatividad porque obliga a humanos hablar en lenguaje robot.
*se convierte en una herramienta que propone la colaboración y la comunicación
Solo se comunican los que realmente estan comodo en el lenguaje.
El lenguaje añade mas capas de traducción al proceso. El BA tiene que traducir sus requerimientos algo en quasi codigo, para explicarlo a sus clientes lo tiene que traducir de nuevo, el desarollador tiene que traducirlo a codigo. …..
Comentario 4
Anko,
Celebro que generes este debate ya que es enriquecedor para todos, sin lugar a dudas. Te cuento que la intención que tenía, de alguna manera, era justamente ésta, provocar un poco de discusión y cruzar opiniones.
Voy al punto entonces.
En realidad, y para serte franco, esa frase es de una persona técnica (especialista en automation) que hace años que esta trabajando sobre metodologías de automatización de pruebas y herramientas open source como Cucumber, entre otras.
En particular con esta herramienta, se dá que por ejemplo aquí en Argentina y me arriesgaría a decir que en muchos países de Latinoamérica ocurre lo mismo, son pocos las que la conocen y manejan, en todo su alcance y como corresponde.
Son exploraciones que algunos como yo, estamos haciendo desde hace un tiempo para acercar este tipo de software a las áreas que lo requieran.
Pero ciertamente veo muy positivo tu punto de vista ya que indudablemente los mapas mentales de un programador, siguen siendo un tanto diferentes del de un analista funcional, un dueño de producto, un responsable de negocio y hasta incluso del cliente mismo, por más técnico que pudiera ser.
Para ciertos casos, indudablemente el «no-técnico» debe tratar de acercarse al lenguaje que le invita esta herramienta para que se entiendan entre ambos, entonces…
…en tu opinión, ¿De qué manera, a tu entender, podrían acercarse e interactuar con esta herramienta miembros del proyecto o stakeholders que no sean especialistas en automatización de pruebas, para definir las historias y casos de uso en este software?
Comentario 5
Interesante debate Anko,
Leyendo su comentario sobre lo que menciona Gustavo Terrera en el blog, no estoy de acuerdo en algunos puntos de lo que usted afirma. Con el debido respeto, paso a describir esos puntos y mi opinión al respecto en cada uno:
«…Al contrario, primeramente porque no son testcases. No prueban nada…»
Sí son casos de prueba (de aceptación de usuario). Decir que «no prueban nada» me parece extremadamente generalizado. Si prueba o no prueba depende del enfoque y de la implementación de la automatización. No existe LA HERRAMIENTA que resuelva todas las necesidades, depende del proyecto, el equipo de trabajo y la predisposición a su uso por parte de todos los involucrados.
He trabajado con Cucumber en varios proyectos y me ha dado muy buenos resultados. Ojo, esto no implica que sirva para cualquier proyecto ni tampoco que en todos los proyectos hubo una participación total por parte del equipo, pero sí en todos me ha servido para organizar las pruebas, reutilizar código, filtrar escenarios y generar los reportes de ejecución.
«…Esto que todo hablan lo mismo es lo que intentaron con Esperanto! No funciona. Limita la creatividad porque obliga a humanos hablar en lenguaje robot…»
Nunca la forma de escribir una prueba de aceptación de usuario o historia de usuario en el desarrollo de software estuvo tan lejos de escribirse en lenguaje robot. Justamente esta herramienta fué diseñada en el sentido completamente opuesto. Como siempre, depende de la forma en que se redacten o diseñen los escenarios. Se trata de texto plano sin tecnicismos, por lo tanto es todo lo contrario a «hablar en lenguaje robot». Estamos de acuerdo que esta herramienta, como cualquier otra que sirva para la automatización de pruebas, no reemplaza el testing manual, si no mas bien mejora los tiempos de pruebas de humo/regresión necesarias ante cada nuevo deploy con el objeto de asegurar que las nuevas funcionalidades añadidas o arreglos realizados no impacten negativamente en el desempeño de la aplicación.
«El lenguaje añade mas capas de traducción al proceso. El BA tiene que traducir sus requerimientos algo en quasi codigo, para explicarlo a sus clientes lo tiene que traducir de nuevo, el desarollador tiene que traducirlo a codigo.»
Justamente al escribirse en texto plano sin aspectos técnicos (aunque se pueden mencionar si fuese necesario) esta herramienta permite a todos los involucrados entender que es lo que se pretende de la aplicación con lo cual el BA no tiene que traducir en dos direcciones. En cuanto a los desarrolladores, siempre han debido traducir los requerimientos a código, es su tarea en el desarrolo de software. No se trata de magia, no es la bala de plata, pero si es una herramienta que aporta un gran beneficio en cuanto a legibilidad de historias de usuario que sirven de documentación «viva» de la aplicación al ser actualizada permanentemente y como disparadora de tests automatizados con reportes incluidos además de mejorar un aspecto MUY IMPORTANTE de la automatización pruebas que es la reutilización de código mejorando considerablemente la mantenibilidad del desarrollo de la automatización y no caer en una gran frustración por el tiempo invertido en mantener un framework. Por último, creo conveniente mencionar que es open source con todo lo que ello implica, entiéndase comunidad de usuarios, bajo costo y mejoras constantes.
Slds, Roman
….CONTINUARÁ
(no se pierda el próximo programa, por este mismo canal, y a la misma hora)
