Imagina un equipo que trabaja como reloj suizo: cada línea de código tiene su prueba unitaria, los pipelines disparan en cada push y las user stories vienen acompañadas de Escenarios de Uso y Validación (EUV) listos para correr.
 El software sale sólido, predecible y pegado al negocio.

Pero hay una pregunta que siempre flota:
 ¿Qué diferencia hay entre probar el código y validar el comportamiento?

Ahí está la línea entre TDD (Test-Driven Development) y la validación a través de EUV, que reemplaza el antiguo enfoque de guiones rígidos o sintaxis estructurada.
 Ambas prácticas comparten el mantra Test First, pero miran niveles distintos:

• TDD cuida la salud interna del código.
• EUV asegura que el sistema haga lo que el usuario espera, dentro de un flujo verificable y trazable.

Una sin la otra es coja: código perfecto que no resuelve nada, o un sistema que “funciona” sobre arena movediza.
 Juntas forman la Calidad Fluida, el núcleo de PAREX: Agilidad Pragmática, que Enjisst y Taqtical aplican para que la calidad no sea un checkpoint, sino un flujo constante.

TDD: el jardín interior del software

TDD lo inventó Kent Beck más como disciplina de diseño que de testing.
 Su ciclo Red–Green–Refactor es puro zen:

• Red: escribe una prueba que falle.
• Green: mete el código justo para que pase.
• Refactor: limpia sin romper nada.

No se trata de cazar bugs, sino de guiar el diseño desde la prueba.
 El resultado:

• Módulos pequeños y cohesionados.
• Código que se puede tocar sin miedo.
• Arquitecturas que aguantan el paso del tiempo.

Un dev con TDD no escribe funciones: construye confianza.
 Cada test verde es una pieza que encaja.

De Gherkin a los Escenarios de Uso y Validación: la evolución del comportamiento

DD introdujo una idea poderosa: escribir escenarios que cualquiera pudiera entender.
 Pero la práctica —con Gherkin— se quedó corta.
 La estructura rígida de Given–When–Then, útil en ejemplos simples, se vuelve confusa cuando los flujos crecen.
 ¿Cuándo termina el Given y empieza el When? ¿Dónde encajan los pasos intermedios?
 Además, Gherkin piensa en la validación de una historia aislada, no en el propósito completo del sistema.

Ahí nacen los Escenarios de Uso y Validación (EUV):
 una evolución metodológica que amplía el alcance del BDD y lo conecta con la visión sistémica del software.
 Mientras Gherkin valida fragmentos, los EUV validan propósitos.
 No solo verifican si algo ocurre, sino por qué y para qué ocurre dentro de un flujo coherente con los objetivos del caso de uso.

Un EUV representa un flujo funcional completo y verificable, compuesto por pasos, acciones, validaciones y extracciones que pueden recorrer múltiples componentes (UI, servicios, archivos, base de datos, etc.).

Ejemplo:

Escenario de Uso y Validación: Proceso de compra con tarjeta válida

• El usuario tiene un producto en el carrito.
• Realiza el pago con tarjeta válida.
• El sistema muestra el recibo y confirmación.

Este bloque es tres cosas a la vez:

• Documento vivo.
• Criterio de aceptación.
• Validación automatizable sin código adicional.

Los EUV heredan lo mejor de Gherkin —legibilidad y colaboración—, pero lo llevan más allá:

• Reemplazan la gramática fija por una estructura jerárquica de pasos y sentencias.
• Permiten herencia y reutilización (“Igual Que”) sin duplicar flujos.
• Mantienen trazabilidad sistémica entre historias, casos de uso y validaciones.
• Incorporan verificación multicanal (web, API, archivos, DB).
• Y sobre todo, recuperan el pensamiento sistémico perdido en la atomización del BDD.

La relación simbiótica: TDD + EUV

No son rivales, son compañeros que se cubren las espaldas.

TDD asegura que las piezas encajen.
 EUV garantiza que el puzzle tenga sentido.
 En PAREX, ambos forman un flujo continuo: del requisito al pipeline, sin traducciones intermedias.

Ejemplo práctico: de la función al flujo

Nivel TDD (interno):

# test_calculadora.py

def test_suma():

    assert suma(2, 3) == 5

# calculadora.py

def suma(a, b):

    return a + b

El dev valida el átomo.

Nivel EUV (externo):

Escenario de Uso y Validación: Sumar dos números

1. El usuario ingresa 2 y 3.
2. Presiona “sumar”.
3. El sistema muestra el resultado 5.

El equipo valida la experiencia.
 Mismo cálculo, dos lentes: estructura vs. interacción.
 Coherencia total.

Cuando falta uno

• Solo TDD → Código impecable, pero ¿resuelve algo?
• Solo EUV → Escenarios bonitos, pero ¿aguanta el código?
• TDD + EUV → Sistema sólido, trazable y con valor.

Esa sinergia es el alma del Desarrollo Trenzado: negocio, QA y desarrollo como un solo cerebro.

Del código a la trazabilidad

Incluso en pruebas unitarias, adoptar una mentalidad orientada a escenarios de uso cambia la calidad del resultado:

def test_debe_rechazar_usuario_inactivo():

    # …

El nombre ya cuenta la historia.
 Así, hasta las pruebas técnicas hablan el lenguaje del negocio.

Integración en pipeline moderno

En un flujo ágil con CI/CD:

1. EUV integran la lógica de ATDD, ya que nacen del acuerdo colaborativo de aceptación y lo llevan a un formato estructurado y automatizable.
    En otras palabras, los criterios del ATDD viven dentro de los Escenarios de Uso y Validación, que definen qué se valida, cómo se verifica y con qué trazabilidad.
2. TDD implementa el cómo (módulos probados).
3. CI/CD ejecuta todo en cada commit.

Resultado: calidad automática, validación sistémica y feedback inmediato.

Por qué los EUV superan a Gherkin

En síntesis:
 Gherkin democratizó la escritura de pruebas.
 Los EUV democratizan el pensamiento sistémico y lo hacen verificable.

Beneficios tangibles

• Menos bugs: los errores se detectan antes de propagarse.
• Comunicación clara: los escenarios hablan por todos.
• Código vivo: TDD fuerza diseño limpio.
• Feedback rápido: pipelines que no mienten.
• Confianza total: validación técnica y funcional unidas.

Cierre: dos prácticas, una sola intención

TDD y los Escenarios de Uso y Validación no compiten. Se complementan.
 Uno mantiene el motor afinado. El otro asegura que el coche llegue al destino correcto.

Juntos no son solo técnicas: son una mentalidad de calidad desde el día uno.
 Con PAREX y el respaldo de Enjisst el código y el comportamiento dejan de ser mundos aparte.
 Se convierten en una sola cosa: valor entregado, validado y vivo.

El cargo TDD en el Código, BDD en el Comportamiento: La Relación Armónica entre Pruebas Unitarias y de Sistema e integración apareció primero en Enjisst.

Por qué las “Iteraciones de Pruebas” no son realmente ágiles

En la búsqueda por volverse más ágiles, muchas organizaciones adoptan conceptos como sprints, backlogs o retrospectivas. Sin embargo, al observar más de cerca su dinámica, se descubre una práctica que traiciona la esencia de la agilidad: la famosa Iteración de Pruebas.
 Un ciclo donde primero se desarrolla, y solo después, en una iteración aparte, se prueba.
 A simple vista parece un avance frente a la cascada tradicional… pero en realidad es la misma película, solo que a una velocidad distinta.

Este modelo —conocido como Cascada Inter-Iteración o Scrumbut (“tenemos Scrum, pero…”)— es el ejemplo más común de cómo una organización puede hablar el lenguaje ágil mientras sigue pensando en modo secuencial.

De la cascada a las iteraciones: un origen mal entendido

Las iteraciones nacieron para solucionar las limitaciones del modelo en cascada.
 Su propósito original era dividir el desarrollo en pequeños incrementos que pudieran ser validados tempranamente por el usuario, reduciendo riesgos y acelerando el aprendizaje.
 Cada iteración debía incluir análisis, diseño, desarrollo, pruebas y entrega de valor real.

Pero en muchas empresas, las iteraciones se deformaron: el equipo de desarrollo trabaja durante dos semanas, “termina” el producto y lo pasa a QA para una “iteración de pruebas” posterior.
 Lo que antes era un ciclo continuo se convierte nuevamente en una línea de producción, solo que más corta.
 El problema no es la velocidad del ciclo, sino la falta de integración entre disciplinas.

El costo invisible del bug

En aseguramiento de calidad y consultoría ágil, hay una verdad irrefutable: cuanto más tarde se detecta un error, más caro resulta.
 Corregir un bug en la fase de requerimientos puede costar una unidad de esfuerzo (1X);
 detectar el mismo fallo durante las pruebas puede costar diez veces más (10X);
 y si llega a producción, el costo puede multiplicarse por cien (100X), entre horas de soporte, pérdida de reputación o sanciones contractuales.

Las iteraciones de pruebas ubican los errores justo en el punto más caro de esa curva.
 En lugar de prevenir, detectan tarde.
 Y lo que es peor, hacen que los equipos vean la calidad como una fase final, no como una responsabilidad compartida desde el inicio.

El síndrome Scrumbut: agilidad a medias

El Scrumbut es la enfermedad silenciosa de los equipos que adoptan solo la superficie de Scrum.
 “Tengo sprints, pero QA prueba después.”
 “Hacemos retrospectivas, pero sin cambios reales.”
 “Tenemos definición de listo, pero no incluye validación de calidad.”

Cuando Desarrollo y QA trabajan en fases separadas, el flujo sigue siendo en cascada, aunque se reparta en iteraciones.
 El resultado es el mismo: retrabajo, retrasos y pérdida de confianza.
 La agilidad no se mide por la frecuencia de los sprints, sino por la velocidad con la que el equipo aprende del usuario y mejora el producto.

La verdadera agilidad: calidad en el sprint

En un entorno ágil maduro, la calidad se construye dentro del sprint, no después.
 Esto implica que las pruebas —unitarias, de integración y de aceptación— se automatizan y ejecutan continuamente mientras se desarrolla.
 Cada historia de usuario tiene un conjunto de criterios de aceptación claros, definidos junto con QA y el Product Owner desde el inicio.

A este enfoque se le conoce como Quality In-Sprint:
 el código no se considera “hecho” hasta que ha sido validado técnica y funcionalmente dentro de la misma iteración.
 La Definitionof Done deja de ser una lista superficial y se convierte en un contrato de calidad real:

“La funcionalidad ha pasado todas las pruebas automatizadas, la revisión de código y ha sido validada por el Product Owner.”

Equipos T-Shaped: el antídoto cultural

El cambio no es solo de proceso, sino de mentalidad.
 Los equipos verdaderamente ágiles son cross-funcionales: los desarrolladores piensan en pruebas, y los testers piensan en código.
 Un desarrollador T-Shaped entiende que escribir pruebas unitarias es parte de su trabajo, no una tarea de QA.
 Y un tester T-Shaped domina herramientas de automatización y conoce el negocio lo suficiente para diseñar escenarios de valor.

Esta colaboración elimina las dependencias y convierte la calidad en una competencia compartida.
 El equipo ya no “espera” a QA, sino que entrega valor junto con él.

Conclusión: sin calidad ágil, no hay desarrollo ágil

Las iteraciones de pruebas separadas son una señal de alerta.
 Indican que la organización aún no ha integrado la calidad dentro de su ADN.
 La agilidad no consiste en trabajar más rápido, sino en aprender y validar continuamente.

En el fondo, la frase que debería guiar a todo equipo es simple pero contundente:

“Desarrollo ágil sin calidad ágil no es ágil.”

Transformar esa frase en práctica diaria requiere disciplina, automatización de pruebas, cultura colaborativa y un liderazgo que entienda que la calidad no se inspecciona al final: se diseña desde el principio.

El cargo ¿Agilidad o Cascada Disfrazada? apareció primero en Enjisst.