BDD: Una conversación entre el DevTeam y el Negocio

Por: Andrés Rincón Moreno

Cuando se trata de hablar de ambientes colaborativos orientados a la calidad en la construcción de software, nos encontramos en el camino con varios interrogantes sobre cómo generar una dinámica de entendimiento y cooperación entre los involucrados: los que lo construyen y los que lo definen.

Al pasar el tiempo y participar en muchos proyectos para los clientes de la organización siempre he encontrado que hay dos mundos que en la mayoría de ocasiones se sienten muy distantes: el Dev Team y el Negocio, que gracias a metodologías o frameworks de trabajo, por ejemplo scrum, sientan las bases para que funcione como uno solo. Pero, ¿qué tanto estos frameworks aseguran la calidad? y aún más, ¿qué tanto entienden los dos mundos dicho aseguramiento?

El concepto BDD, por sus siglas Behavior Driven Development, es un proceso de desarrollo de software que se presenta como una buena alternativa para que los involucrados en un proyecto piensen, definan y construyan desde el concepto de calidad.

BDD propone que dentro de un proceso de desarrollo, por ejemplo el ágil, las pruebas sean parte fundamental de su evolución, entendiéndola como la comprensión común de los criterios de aceptación y la construcción de los escenarios de pruebas antes del inicio del desarrollo, y que a su vez, estos sean conocidos y aceptados por todo el equipo.

Pero, ¿qué ventajas tiene esta práctica?, veamos un ejemplo básico:
Digamos que tenemos un equipo de desarrollo donde uno de sus miembros tiene skills de testing y es quien a su vez está encargado de plantear, basado en los criterios de aceptación, los escenarios de prueba funcionales. Dentro de su proceso normal desarrolla una Historia de Usuario y a la par está creando los escenarios de prueba que serán ejecutados una vez la historia tenga su desarrollo completo. Para este ejemplo el ejercicio de prueba será :

  1. Desarrollar la Historia de Usuario.
  2. Ejecutar los escenarios de prueba planteados.
  3. Volver sobre el código y corregir aquellos bugs encontrados durante la inspección.
  4. Ejecutar de nuevo las pruebas y comprobar la corrección de los bugs.

Ahora pregunto a los desarrolladores del común: ¿te gustaría saber desde antes de desarrollar, cuales son los escenarios de prueba que se ejecutarán para revisar que la historia implementada cumple con todos los criterios de aceptación? ¡He ahí la ventaja de BDD!

En palabras simples, sería como tener las respuestas a las preguntas de un parcial en la universidad, permitiéndote completar esos flujos que quizás, en tu análisis como desarrollador se pudieron haber escapado. En este caso el ciclo sería:

  1. Definir escenarios de prueba funcionales.
  2. Desarrollar teniendo como base o contemplando dichos escenarios
  3. Ejecutar los escenarios de prueba para comprobar la cobertura de los escenarios.

Si bien no se elimina totalmente la posibilidad de encontrar bugs, con el uso de BDD se reduce en un porcentaje importante ya que estamos cubriendo desde el inicio dichos escenarios.

En este escenario, BDD entendido como framework, brinda la posibilidad de implementar pruebas automatizadas que sean entendidas en un lenguaje natural y lenguaje técnico, lo que permite implementar las pruebas automatizadas, esto da la ventaja de hacer accesible para el negocio la implementación las pruebas.

Como conclusión, podemos ver que las ventajas acá expuestas permiten no solo garantizar la calidad del producto que se quiere desarrollar, si no también articular al equipo de negocio y el equipo técnico, para que todos los involucrados estén alineados con los objetivos.

Share

Share on facebook
Share on twitter
Share on linkedin

Related Posts

¿Quieres recibir más información sobre tendencias en desarrollo de software, DevOps, innovación o productividad?

Últimas entradas

Aplicaciones Reales con Blockchain

Blockchain es una de las tecnologías que más fama ha adquirido en años recientes; en parte por la explosión de las criptomonedas, pero también por la

¿Qué es refactoring?

El objetivo del refactoring es evitar la deuda técnica que se acumula en el código fuente y  generar un código mas limpio y mas fácil