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.

Resumen

Durante décadas, los casos de uso han servido como un lenguaje común para comprender qué hace el software y por qué lo hace. Sin embargo, las prácticas contemporáneas de desarrollo, dominadas por historias de usuario y scripts BDD, han reducido esa visión sistémica a narrativas fragmentadas. Este documento propone los Escenarios de Uso y Validación (EUV) como una evolución metodológica que restaura el pensamiento sistémico en la descripción y validación del software, extendiendo los principios de los Casos de Uso 3.0 hacia una trazabilidad operativa entre intención, comportamiento y verificación.

1. La necesidad de recuperar el pensamiento sistémico

Las metodologías ágiles han promovido una dinámica más humana y adaptable en el desarrollo de software. Sin embargo, en su afán por acelerar la entrega, han atomizado la comprensión del sistema. Las historias de usuario expresan necesidades locales; las pruebas automatizadas validan comportamientos aislados; pero entre ambas se ha perdido el hilo conductor que permite entender cómo cada pieza contribuye al propósito general del sistema.
 
 El pensamiento sistémico —entender el software como un conjunto de comportamientos interrelacionados que satisfacen objetivos de negocio— debe ser restaurado como principio rector. Los Escenarios de Uso y Validación surgen como ese puente entre la intención y la comprobación, permitiendo describir el comportamiento del sistema de forma coherente, verificable y trazable.

2. Estructura conceptual del sistema

En una arquitectura conceptual moderna, el conocimiento del sistema se organiza jerárquicamente:
 
 1. Estructura conceptual: Agrupa los casos de uso dentro de paquetes alineados con servicios de negocio o actores relevantes.
 2. Caso de uso: Describe un objetivo completo que el sistema debe permitir alcanzar, desde la perspectiva de un actor.
 3. Escenarios de Uso y Validación (EUV): Son las realizaciones ejecutables del comportamiento del caso de uso.
 4. Composición: Define un flujo de negocio de extremo a extremo que involucra varios EUV y casos de uso, para validar el comportamiento integral del sistema.

3. Qué son los Escenarios de Uso y Validación

Un Escenario de Uso y Validación es una representación estructurada y ejecutable de un flujo funcional, donde la narrativa y la validación convergen. A diferencia de los guiones de prueba tradicionales, los EUV describen la interacción completa necesaria para lograr un objetivo de negocio, sin perder la semántica del caso de uso al que pertenecen.

3.1 Jerarquía interna

Cada EUV está compuesto por una jerarquía clara que facilita su comprensión y reutilización:
 1. Nombre del escenario: describe la finalidad del flujo.
 2. Pasos titulados: agrupan secciones lógicas del escenario.
 3. Sentencias: acciones atómicas que expresan lo que el usuario o el sistema realizan o verifican.
    – Acciones: interacciones en pantalla, manipulación de archivos, ejecución de servicios, inclusión de precondiciones o secciones reutilizables.
    – Validaciones: comprobaciones en pantalla, archivos, correos o bases de datos.
    – Extracciones: recuperación de datos para reutilización posterior dentro del escenario.
    – Sincronizaciones: esperas o verificaciones de estado que sincronizan la ejecución con las respuestas del sistema.

4. Evolución metodológica: de las tajadas de casos de uso a la validación ejecutable

En los Casos de Uso 3.0, introduje el concepto de slice o tajada: una pequeña unidad funcional del sistema que puede ser diseñada, implementada y probada de manera incremental. Los EUV representan la materialización de esas tajadas en el plano de validación. Cada slice tiene uno o varios EUV que lo realizan y verifican, y cada historia de usuario se vincula a esos elementos, formando una red de trazabilidad viva:
 
 Historia de Usuario → Caso de Uso → Tajada → Escenario de Uso y Validación
 
 De este modo, la descripción conceptual, la ejecución funcional y la verificación automatizada quedan unidas en un solo hilo metodológico.

5. Características metodológicas distintivas

Los Escenarios de Uso y Validación poseen propiedades que los diferencian de cualquier otro enfoque de validación basada en texto estructurado:
 1. Progresividad.
 2. Reutilización estructural (Igual Que).
 3. Modularidad (Usar sección reutilizable, Incluir acciones de caso de prueba).
 4. Trazabilidad sistémica.
 5. Interacción multicomponente.
 6. Colaboración interdisciplinaria.

6. Comparación metodológica con Gherkin

El formato Given–When–Then de Gherkin aportó una valiosa idea: acercar el lenguaje natural a la automatización. Sin embargo, su enfoque se centra en validar una historia de usuario aislada, lo que fragmenta la visión sistémica del software. Además, la estructura fija tiende a generar confusión en escenarios extensos, donde la distinción entre Given y When se diluye.

6.1 Diferencias de propósito

Los EUV entienden que el software no se valida por fragmentos, sino por comportamientos coherentes que logran propósitos compartidos.

6.2 Diferencias estructurales

EUV introduce un lenguaje más natural, donde la secuencia se organiza por significado y no por gramática.

6.3 Diferencias operativas

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

7. De la descripción a la validación continua

La verdadera innovación de los EUV no reside en su sintaxis, sino en su papel metodológico. Convierten la validación en una extensión natural del modelado. Cada escenario expresa simultáneamente la intención funcional, el comportamiento esperado y la evidencia verificable de cumplimiento. Esto permite integrar la validación dentro del flujo continuo de desarrollo, sin depender de traducciones o intermediarios técnicos.

8. Conclusión

Los Escenarios de Uso y Validación representan una evolución del paradigma orientado a casos de uso hacia un enfoque sistémico, trazable y colaborativo de la validación del software. Restablecen la unidad entre lo que se desea, cómo se realiza y cómo se comprueba, permitiendo a los equipos construir y validar sistemas con propósito compartido y comprensión común.

El cargo Escenarios de Uso y Validación: Una evolución sistémica del pensamiento orientado a casos de uso apareció primero en Enjisst.

Cuando la calidad llega con el café frío

En la mayoría de los equipos que conozco, “calidad” es la palabra que se susurra al final, como quien pide la cuenta después de una cena larga. El código ya está escrito, integrado, casi listo para producción… y de pronto aparece el equipo de QA con una hoja de Excel que parece un parte de guerra. El lanzamiento se congela, los devs defienden cada línea como si fuera un hijo, el negocio tamborilea los dedos y el tester termina siendo el malo de la película.

¿Por qué pasa esto? Porque seguimos pensando la calidad como un tapón al final del tubo: algo que se verifica, no algo que se construye. Pero los proyectos realmente exitosos no funcionan así. Con ágil, CI/CD y clientes que quieren valor cada dos semanas, necesitamos que la calidad sea un río que corre desde la primera idea hasta el último deploy.

Llevamos años ayudando a equipos a convertir ese tapón en corriente. No vendemos más pruebas ni herramientas mágicas; acompañamos el cambio cultural para que la calidad deje de ser un departamento y se vuelva el pulso mismo del trabajo.

Del guardia de frontera al compañero de ruta

El modelo clásico es una cadena de montaje: diseño → desarrollo → pruebas. Cada etapa entrega a la siguiente como si fueran países distintos. QA hace de aduana: revisa el pasaporte y decide si el producto cruza o vuelve a la fábrica.

El problema no es el control; es el momento. Cuando el defecto se detecta tarde:

1. Sale caro: arreglar algo integrado cuesta 10, 50, 100 veces más que pillarlo en la primera línea.
2. Pierde sentido: QA valida sintaxis, pero no siempre entiende si eso resuelve el dolor del cliente.
3. Crea trincheras: devs vs. testers, negocio vs. técnicos. Todos apuntan culpas en vez de soluciones.

La Calidad Fluida (la llamamos así en el marco PAREX) propone lo contrario: borrar las rayas en el mapa. El analista de negocio, el dev y el tester hablan el mismo idioma desde el día uno. La especificación no es un documento que viaja; es una conversación que se convierte en pruebas automatizadas antes de que se escriba la primera función.

Dalia Trujillo, una de las cabezas detrás de PAREX, lo resume así: “El salto real ocurre cuando la necesidad del cliente se traduce en un escenario ejecutable que el código respeta y el negocio puede leer”. Trazabilidad viva, no papel muerto.

Los cuatro pilares que sostienen el río

1. Responsabilidad compartida (o “todos remamos”)

La calidad no es “cosa de QA”. Es como la seguridad en un barco: todos revisan que no haya agujeros, no solo el capitán.

• El ProductOwner define qué vale y cuándo está listo.
• El dev escribe código que se prueba solo (TDD).
• El tester facilita criterios claros desde la primera reunión y automatiza lo repetible.

En lugar de “yo construyo, tú rompes”, surge “construimos juntos, verificamos juntos”. Inspirado en Use-Case 3.0, cada historia lleva su hilo conductor desde el objetivo de negocio hasta la última línea de log.

2. Shift-Left: probar antes de construir

Llevar la prueba “a la izquierda” significa validar mientras se diseña, no después de levantar la casa.

• Criterios de aceptación escritos en la misma pizarra donde se dibuja el flujo.
• Escenarios BDD que se convierten en pruebas vivas antes del primer git push.
• Pipelines que fallan en segundos, no en noches.

Con nuestros partners montamos estos pipelines en pocas semanas; el ROI aparece en el primer sprint: menos sorpresas, más confianza.

3. Feedback en gotas, no en baldes

Un reporte de 40 bugs el día del release es un balde de agua fría. Micro-alertas cada commit son gotas que refrescan.

• Pruebas unitarias → 2 segundos.
• Pruebas de contrato → 10 segundos.
• Métricas de producción → en tiempo real.

La observabilidad deja de ser “mirar logs cuando algo explota” y pasa a ser la brújula diaria del equipo.

4. La metáfora del agua (porque a veces hace falta poesía)

Si la calidad es un filtro al final, cualquier piedrecita lo atasca. Si es un sistema de cañerías con sensores, válvulas y limpieza automática, el agua llega cristalina a cada grifo.

Cada etapa tiene su válvula:

• Ideación: ¿esto resuelve un dolor real?
• Código: ¿se puede probar solo?
• Integración: ¿rompe algo que ya funcionaba?
• Producción: ¿el usuario lo usa y sonríe?

Nada de agua estancada. Todo fluye o se drena.

Cómo empezar mañana mismo

1. Un idioma común: usa ejemplos concretos en lugar de requisitos abstractos (BDD te da la gramática).
2. Calidad desde el café de las 9: incluye al tester en la refinamiento; que traiga café y criterios.
3. Automatiza lo aburrido: unitarias, BDD, smoke tests en pipeline.
4. Mide lo que duele: lead time, % de historias con aceptación, MTTR.
5. Celebra los errores: retros cortas, blameless, con cerveza si hace falta.

Enjisst aplica esto con PAREX en auditorías y acompañamientos; Taqtical lo materializa en pipelines y dashboards.

Métricas que cuentan la historia

Métrica	Qué dice	Meta realista
Tiempo de detección de defectos	¿Cuándo duele?	< 24 h
Historias con criterios claros	¿Todos hablamos lo mismo?	> 90 %
Regresiones por sprint	¿Rompemos lo que ya andava?	< 10 %
MTTR	¿Corrimos rápido?	< 1 día
Satisfacción Dev/QA	¿Nos queremos?

Un caso real: fintech que dejó de ahogarse

Una fintech mediana en Latinoamérica entregaba cada release con 40 % de retrabajo. QA encontraba errores funcionales la víspera del lanzamiento; los despliegues se posponían tres semanas. El clima era de trinchera.

Logró:

• Sesiones de “tres amigos” (PO + Dev + QA) por historia.
• BDD con Enjisstatado a GitLab CI.
• Dashboard compartido con negocio (lead time visible para todos).

Resultados:

• Defectos críticos ↓ 60 %.
• Lead time de 12 → 7 días.
• El negocio empezó a preguntar “¿cuándo sale lo próximo?” en vez de “¿seguro que no falla?”.

Cierre: la calidad se vive, no se firma

La Calidad Fluida no es otra metodología para colgar en la pared. Es cambiar la pregunta:

Antes: “¿Ya lo probaste?” Ahora: “¿Cómo sabemos que está funcionando bien ahora mismo?”

Cuando la calidad fluye, el software deja de ser una caja negra que se abre al final y se convierte en un río que todos ven, tocan y mejoran cada día.

¿Listo para soltar el tapón y abrir las compuertas? Hablemos.

El cargo La calidad no es un sello, es un río: cómo hacer que fluya de verdad apareció primero en Enjisst.