Hola mis estimados amigos y amigas de la calidad.
Hoy quiero hablar de un tema que suele generar opiniones encontradas, especialmente entre quienes están empezando en QA, el Behaviour Driven Development, o BDD para los panas. Para algunos es una práctica poderosa que mejora la comunicación del equipo; para otros, una capa innecesaria de texto que nadie lee. La realidad es que ambas posturas pueden ser correctas, dependiendo de cómo y por qué se esté usando.
BDD fue propuesto por Dan North, y originalmente ni siquiera se llamaba así. Su nombre inicial fue Behavioral Specification. La idea no era escribir casos de prueba ni documentar escenarios técnicos, sino describir el comportamiento esperado del sistema en un lenguaje que todos pudieran entender. Con el tiempo, el término evolucionó a Behavior-Driven Development y se popularizó el uso de Gherkin con su estructura Given–When–Then.
El problema es que muchas veces adoptamos Gherkin sin entender el propósito que lo originó.
El objetivo real de BDD
BDD no es una sintaxis.
No es un framework.
Y definitivamente no es una forma elegante de escribir tests automatizados.
BDD es una práctica de conversación.
Su objetivo principal es crear un lenguaje común entre negocio, desarrollo y QA para reducir malentendidos antes de que exista código. Gherkin es solo una herramienta para apoyar esa conversación, no el fin en sí mismo.
Cuando se usa correctamente, Gherkin ayuda a traducir lo técnico a lenguaje natural, permitiendo que personas con distintos perfiles puedan razonar juntas sobre el comportamiento del sistema.
Cuando se usa mal, se convierte en documentación técnica disfrazada de lenguaje de negocio.
Cuándo Gherkin realmente ayuda
Gherkin es útil cuando existe una conversación real detrás del escenario. Es decir, cuando ese escenario nace de una discusión previa donde participaron distintas perspectivas. Un escenario bien escrito no debería ser una sorpresa para nadie del equipo; debería representar algo que ya fue entendido y acordado.
También ayuda cuando se valida comportamiento relevante para el usuario. Un buen escenario describe qué quiere lograr una persona y qué resultado espera, no cómo el sistema lo implementa internamente. Si el escenario podría ser entendido por alguien que no escribe código, probablemente va en la dirección correcta.
Otro punto clave es el lenguaje compartido. Cuando negocio, desarrollo y QA usan los mismos términos para referirse a conceptos del dominio, Gherkin se vuelve una herramienta poderosa. Ayuda a detectar ambigüedades, supuestos incorrectos y diferencias de interpretación antes de que se transformen en bugs o retrabajo.
En estos casos, Gherkin no solo ayuda a QA a probar mejor, sino al equipo completo a pensar mejor.
Cuándo Gherkin empieza a estorbar
El problema aparece cuando se escribe Gherkin solo para “cumplir con BDD”. Escenarios creados porque el proceso lo exige, no porque aporten claridad. En esos casos, el texto suele ser largo, técnico y poco útil para cualquiera que no sea QA.
Empieza a estorbar cuando nadie del negocio lo lee. Si los escenarios viven únicamente en repositorios técnicos y no se usan para conversar o tomar decisiones, dejaron de cumplir su propósito original. Se convierten en un artefacto más que mantener, no en una herramienta de alineación.
También estorba cuando se usa como documentación técnica disfrazada. Escenarios llenos de detalles de implementación, pasos innecesarios o validaciones internas que el usuario nunca percibe. Esto no acerca al equipo; al contrario, aumenta la distancia entre roles.
En estos casos, Gherkin no solo no ayuda, sino que genera una falsa sensación de alineación.
El rol de la reunión de los tres amigos
Una de las prácticas más asociadas a BDD es la reunión de los Three Amigos: negocio, desarrollo y QA. Esta reunión no existe para escribir escenarios, sino para conversar sobre el comportamiento esperado.
Gherkin debería ser el resultado de esa conversación, no el punto de partida. Primero se habla, se hacen preguntas, se aclaran supuestos y se entienden riesgos. Luego, si tiene sentido, se formaliza ese entendimiento en escenarios claros y legibles.
Cuando QA participa activamente en estas conversaciones, deja de ser un rol reactivo que prueba al final y se convierte en un facilitador de entendimiento temprano.
Plantilla práctica: ¿Necesitas realmente Gherkin?
Antes de escribir un escenario, prueba responder estas preguntas:
- ¿Este comportamiento es importante para el usuario?
- ¿Ayuda a aclarar una decisión o reducir un malentendido?
- ¿Alguien fuera de QA podría leerlo y entenderlo?
- ¿Este escenario nace de una conversación real?
Si la mayoría de las respuestas son “no”, probablemente no necesitas Gherkin. Tal vez un checklist, una nota o una conversación directa sea suficiente.
BDD no exige Gherkin para todo. Exige entendimiento compartido.
Para quienes están empezando en QA
Si estás comenzando en QA, no te enfoques en aprender la sintaxis perfecta de Given–When–Then. Enfócate en aprender a hacer mejores preguntas, a entender el dominio y a traducir lo complejo en lenguaje simple.
Gherkin puede ser una excelente herramienta para eso, pero solo si se usa con intención.
Si quieres profundizar más en este tema, en mi canal de YouTube tengo un video llamado “¿Realmente Necesitas Gherkin? Descubre la Verdad en 10 Minutos”, donde explico con ejemplos reales cuándo usarlo y cuándo no.
BDD no trata de escribir más escenarios.
Trata de construir mejor entendimiento.
Y cuando eso se logra, Gherkin deja de estorbar y empieza a aportar valor real.
