¿Qué criterios debemos tener en cuenta para elegir una herramienta o tecnología que soporte BDD?

En esta segunda parte hablaremos de cuáles son los criterios que debemos tener en cuenta a la hora de elegir una herramienta que nos ayude a implementar BDD (Para ello debemos entender qué es BDD mencionado en la primera parte aquí).

No entraré en el error que a veces cometemos los equipos en disertar la bondades o inconvenientes de una herramienta particular sin mirar más allá otros factores. Por lo cual se aceptan sugerencias o retroalimentación de los lectores.

Criterios:

  1. De preferencia debe soportar un modelo de Integración continua.
  2. Debe ayudarnos a generar documentación viva con diferentes niveles de detalle de las funcionalidades que se espera que cumpla el software, según lo que le da valor agregado a cada rol del equipo.
  3. Debe brindarme evidencias (con imágenes) de cada funcionalidad esperada y un estado de esa funcionalidad.
  4. Debe describirme las funcionalidades esperadas del software en un lenguaje de alto nivel, que me elimine las ambigüedades del idioma, usando la misma terminología de negocio y me dé claridad al respecto (con ejemplos ).
  5. Elegir las herramientas según el conocimiento del equipo en cuanto al ambiente, sistema operativo o lenguaje de programación soportado por la herramienta BDD.
  6. Elegir las herramientas según la licencia, recursos disponibles y optimización financiera de la compañía.
  7. Elegir una matriz comparativa de beneficios y desventajas basándose en el contexto del proyecto y según el ROI.
  8. Se debe evaluar y elegir las herramientas que soporten BDD sin los siguientes paradigmas:
    1. Dar por echo que una herramienta que se ha venido usando en otros proyectos en un contexto especifico se pueda generalizar aplicándola en los demás proyectos.
    2. Creer que una herramienta  open source no tiene los beneficios que tiene una herramienta privada.
    3. Escoger herramientas CASE que faciliten la realización de automatización de pruebas al equipo de QA con el argumento de que el automatizador se le dificultaría hacer scripting sin tener en cuenta las desventajas que ellas causan.