Software QA ubicua – ¿el Santo Grial de la SQA?

BDD Behaviour Driven Development ,seguimos persiguiendo establecer un marco de conversación común entre todos los implicados en la fabricación de software con el mismo ahínco con el que los Caballeros de la Mesa Redonda buscaron el Santo Grial.

Partimos de las premisas auspiciadas por el diseño orientado a Dominio, de forma que el valor que queremos aportar lo modelemos mediante dominios de negocio independientes de la tecnología.

Así, inspirados en las buenas prácticas, pautas y patrones establecidos por Eric Evans en su libro sobre Domain-Driven Design (DDD) – el dominio es lo único importante – buscaremos construir modelos que permitan una comunicación efectiva extremo a extremo y nos aplicaremos en preservar la integridad del modelo frente a los cambios.

Las múltiples aventuras de estos valientes caballeros nos conducen hacia el reconocimiento de BDD Behavior Driven Development como un excelente exponente de estos principios. La piedra angular de este puente entre negocio y desarrollo software es la utilización de un lenguaje común, conciso, que nos permita conversar, anticiparnos a los problemas y consolidar el avance: un lenguaje ubicuo.

Este mismo punto lo estuvimos tratando en “BDD Behaviour Driven Development specs features que molan“, charla propuesta por Nestor Salceda durante el pasado #AOS2k14. En concreto:

¿Qué nos ofrece disponer de un lenguaje ubicuo en fabricación software?

• Mediante personalización podemos llegar a hablar todos el mismo lenguaje.
• El foco es establecer una plataforma que pueden entender las áreas de negocio y también los desarrolladores.
• Además, es automatizable.
• Permite separar la especificación de la implementación de los test. Permite no meter negocio en la implementación.
• El gran potencial es que los usuarios de negocio escriban sus requisitos en BDD Behaviour Driven Development (todo un mito ;-).
• Aunque, “es muy puñetero centrarte en qué incluyes en los test, no mezclar negocio con funcionales”.

La propuesta de Nestor pivotó sobre aspectos que le gustaban de diversos marcos tecnológicos para BDD Behaviour Driven Development (como Cucumber, Spock, Jasmine, etc) extendiéndolo incluso a los servidores (Serverspec), la cobertura de las pruebas o la potencial capacidad “asesina” de la interminable refactorización de las pruebas. Fue muy interesante, pero en esta ocasión nos quedaremos solo con sus comentarios sobre lenguaje ubicuo.

 ¿Y cómo seguimos nuestra búsqueda del marco de conversación común como Santo Grial?

Mediante aproximaciones sucesivas, trabajando de forma continua y ágil con los distintos agentes, fomentando conversaciones, escuchando y aprendiendo.

Como indica Adrián M. Paredes en su artículo sobre DDD: Poniendo el Modelo de Dominio a Trabajar

El modelo, el código y el diseño deben evolucionar juntos, de la mano, y de ninguna forma se debe permitir que se desincronicen. Cuando un concepto se actualice en el modelo, se deberá reflejar automáticamente en el código y en el diseño; y lo mismo al revés. 
El conocimiento es un proceso de aprendizaje continuo.

Más referencias interesantes son:

• Domain-Driven Design Quickly, es  un resumen del citado libro de Eric Evans, elaborado por Abel Avram y Floyd Marinescu
• BDD para la mejora de la Calidad Software, de Enrique Sánchez
• El Dominio es la único importante, primer artículo al respecto de Adrían M. Paredes (2008)

Por tanto,
¿Te apuntas a la búsqueda de este Santo Grial?
¡manos a la obra!