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.

En el mundo del desarrollo de software, los peores líos no salen del código en sí, sino de cómo lo entendemos todos.
Lo que para el equipo de negocio es “una función rápida” puede significar para un dev “optimizar el backend”, y para QA “que responda en menos de 2 segundos”. Tres visiones de lo mismo, y al final, tres cabreos.

El problema no es técnico: es de comunicación pura y dura.
 Ahí entra el concepto de los Escenarios de Uso y Validación (EUV), una evolución metodológica que resuelve una duda clave:
 ¿cómo hacemos que negocio, desarrollo y pruebas hablen el mismo idioma y validen lo mismo?

Los EUV transforman la vaguedad en evidencia verificable. No son otro documento más: son contratos vivos entre intención, comportamiento y validación, una herramienta clave en los servicios de automatización de pruebas y consultoría en calidad que ofrece Enjisst para conectar la estrategia del negocio con lo que realmente se construye.

Escenarios de Uso y Validación: cuando el requisito se convierte en evidencia

Un Escenario de Uso y Validación no es código ni un texto decorativo: es una forma estructurada de narrar cómo debe comportarse el sistema para cumplir un propósito de negocio, y al mismo tiempo verificarlo de forma ejecutable.

Ejemplo:

Escenario de Uso y Validación: Transferencia bancaria
 Propósito: garantizar que el sistema gestione correctamente una transferencia.
 Pasos:

1. El usuario tiene $50 disponibles en su cuenta.
2. Intenta transferir $100.
3. El sistema muestra un mensaje: “Saldo insuficiente”.

Este pequeño flujo logra tres cosas:

• Documenta el requisito de forma clara y funcional.
• Define el comportamiento observable del sistema.
• Se convierte en una validación automatizable que refleja el cumplimiento del objetivo de negocio.

En el enfoque PAREX de Agilidad Pragmática, los EUV hacen que el modelado funcional deje de ser teoría para convertirse en un instrumento de validación continua, base de la calidad operativa en los proyectos de Enjisst y Taqtical.

El problema de los requisitos ambiguos

La escena es clásica: escribes una user story, la desarrollas, la pruebas… y el usuario suelta: “Eso no era lo que yo quería.”
 Esa frase ha costado miles de horas en rework.

El modelado funcional tradicional suele fallar porque describe funciones aisladas, no comportamientos verificables.
 Los EUV corrigen ese vacío al mantener la semántica del caso de uso y su validación real.
 Cada escenario no solo dice qué se quiere, sino cómo se comprobará que realmente ocurre.

En consultorías de calidad como las de Enjisst, esta trazabilidad es oro: cada historia se vuelve un escenario ejecutable, y cada validación, una prueba viva del valor entregado.

La anatomía de un Escenario de Uso y Validación

A diferencia de los antiguos scripts rígidos, un EUV se estructura jerárquicamente para mantener claridad y trazabilidad:

1. Nombre del escenario: expresa la finalidad o propósito.
2. Pasos titulados: agrupan fases lógicas del flujo.
3. Sentencias: describen acciones y validaciones.

• Acciones: lo que el usuario o el sistema hacen.
• Validaciones: lo que se espera comprobar.
• Extracciones y sincronizaciones: aseguran continuidad y reutilización dentro del flujo.

Esta estructura permite que tanto negocio como QA o desarrollo entiendan qué se valida, por qué y con qué propósito, restaurando la conexión entre diseño funcional y evidencia técnica.

Los EUV como contrato que une negocio y sistema

En el modelado funcional moderno, toda funcionalidad debe rastrearse hasta un objetivo de negocio.
 Los Escenarios de Uso y Validación lo hacen posible:

En nuestros partners y clientes, esta alineación se traduce en proyectos donde los requisitos son medibles, trazables y verificables de extremo a extremo.
 Nada se queda en la interpretación: todo tiene evidencia funcional.

Del documento estático a la especificación viva

Antes, los requisitos terminaban en PDFs inmóviles que se quedaban viejos al primer cambio.
 Con los EUV, la documentación se vuelve dinámica y validable:
 si la ejecución pasa, el comportamiento sigue vigente; si falla, hay una desviación trazable.

Por eso decimos que los Escenarios de Uso y Validación convierten la documentación en evidencia viva, elemento clave en las auditorías de calidad que Enjisst realiza para garantizar trazabilidad entre necesidad, ejecución y verificación.

Cómo redactar Escenarios de Uso y Validación que comuniquen

Un buen escenario narra el propósito y el resultado esperado desde el usuario, no la lógica interna.

Mal ejemplo:
 “Ejecutar POST a /api/v1/login con payload {…} debe retornar código 200.”

Buen ejemplo:
 “El usuario ingresa sus credenciales correctas y accede exitosamente a su cuenta.”

Reglas prácticas:

• Habla desde el valor, no desde la implementación.
• Usa lenguaje natural y presente.
• Un objetivo por escenario.
• Cada validación debe ser medible y verificable.

Estos principios se enseñan en los programas de capacitación de Enjisst para fortalecer la comunicación entre negocio y desarrollo.

Pensar en escenarios: una práctica sistémica

En PAREX, se promueve pensar en escenarios múltiples: no solo el “camino feliz”, sino excepciones y condiciones frontera.
 Los EUV lo hacen natural y escalable.

Ejemplo:

Escenario de Uso y Validación: Agregar producto al carrito

• Producto disponible → agregado correctamente.
• Producto agotado → mensaje de error.
• Límite máximo → advertencia y rechazo.

Este pensamiento por escenarios ofrece cobertura real, evitando huecos lógicos y reforzando la validación continua en los pipelines de calidad que Taqtical implementa.

Herramientas que dan vida a los EUV

Los Escenarios de Uso y Validación no dependen de una herramienta específica; pueden integrarse con motores de automatización o frameworks personalizados.
 Su valor no está en la sintaxis, sino en el modelo conceptual que conecta intención, comportamiento y evidencia.

Estas implementaciones fortalecen el flujo de Calidad Fluida, donde el conocimiento del negocio fluye hasta la verificación técnica sin rupturas.

Beneficios tangibles de los Escenarios de Uso y Validación

• Elimina ambigüedades entre negocio y tecnología.
• Genera documentación viva y validable.
• Asegura trazabilidad completa entre intención y cumplimiento.
• Reduce rework y errores conceptuales.
• Aumenta la confianza y la transparencia en cada entrega.

Como plantea Tangled Development, los EUV llevan a QA a un nuevo rol: de auditar a diseñar valor, colaborando en la construcción de calidad desde el inicio.

Conclusión: del documento a la conversación viva

Los Escenarios de Uso y Validación más que una forma de documentar ejecutable; son una forma de pensar y validar en equipo.
 Transforman el contrato del negocio en una conversación viva, donde cada funcionalidad tiene propósito, comportamiento y evidencia.

En la era de la Calidad Fluida, los EUV no son un artefacto técnico:
 son la unión tangible entre lo que el negocio imagina y lo que el sistema demuestra.
 Y en Enjisst, esa unión se convierte en el núcleo del valor entregado.

El cargo El Contrato del Negocio: Escribiendo Especificaciones Ejecutables con Escenarios de Uso y Validación apareció primero en Enjisst.

En el mundo del desarrollo de software, una verdad es ineludible: no se puede probar todo.

Cada nueva funcionalidad, cambio o integración genera un conjunto casi infinito de posibles escenarios. Y aunque la tentación de “probarlo todo” es grande, la realidad de los tiempos, recursos y prioridades del negocio obliga a hacer elecciones.
 Ahí es donde entra en juego la planeación de pruebas basada en riesgos —un enfoque que pone la inteligencia antes que la exhaustividad.

La esencia del enfoque basado en riesgos

La planeación de pruebas tradicional suele distribuir los esfuerzos de forma uniforme: se prueban todas las áreas con el mismo nivel de detalle, como si todas tuvieran la misma relevancia.
 El enfoque de gestión de riesgos en QA rompe con esa idea.
 Propone algo mucho más estratégico: concentrar la energía del equipo donde el impacto de un error sería realmente costoso.

El concepto tiene raíces en la ingeniería, particularmente en el Análisis Modal de Fallos y Efectos (FMEA, por sus siglas en inglés), un método clásico que prioriza riesgos según la severidad y probabilidad de cada fallo.
 Aplicado al software, esta metodología se traduce en una fórmula simple pero poderosa:

Prioridad de Riesgo = Impacto × Probabilidad

Donde cada factor se evalúa en una escala de 1 a 5.
 Así, un riesgo con Impacto = 5 (por ejemplo, un error en el proceso de pago) y Probabilidad = 5 (tecnología nueva o compleja) obtiene una prioridad de 25 —el máximo nivel de atención.

El riesgo es bipolar: impacto y probabilidad

Todo riesgo tiene dos caras.
 Por un lado está el impacto, que mide el daño potencial al negocio si la funcionalidad falla: pérdida de ingresos, daño reputacional, incumplimiento normativo.
 Por el otro, la probabilidad, que refleja cuán factible es que ocurra un fallo: complejidad del código, falta de experiencia del equipo, dependencia de terceros, o baja cobertura de aseguramiento de calidad.

Un bug en la generación de facturas tiene un impacto alto y debe priorizarse.
 En cambio, un error menor en la visualización del historial de búsqueda puede tener bajo impacto, aunque su probabilidad sea alta.
 El secreto está en equilibrar ambos factores para decidir dónde invertir las pruebas y con qué profundidad.

Más allá de lo funcional: riesgos que no se ven

La planeación de pruebas basada en riesgos no se limita a las funcionalidades visibles del sistema.
 También debe considerar los riesgos no funcionales, aquellos que suelen pasar desapercibidos hasta que ya es demasiado tarde:

• Desempeño: no se trata solo de la velocidad, sino también del uso de recursos (memoria, CPU, consumo de red). Un sistema que consume demasiado puede incrementar los costos de cloudcomputing o afectar la escalabilidad.
• Seguridad: más allá de la autenticación, la autorización y la auditoría son esenciales. ¿Quién puede hacer qué? ¿Y queda registro de ello? Estos factores determinan la conformidad legal y la confianza del usuario.
• Confiabilidad: qué tan bien maneja el sistema los errores, qué tan resiliente es ante fallos.
• Usabilidad y soporte: una interfaz confusa o un flujo de soporte deficiente también son riesgos, porque impactan la experiencia del usuario y el tiempo de respuesta del equipo.

Al incluir todos estos aspectos, el QA deja de ser un filtro técnico para convertirse en una herramienta de mitigación de riesgos empresariales.

La matriz de riesgos: una mirada visual y estratégica

Una forma práctica de aplicar este enfoque es construir una matriz de riesgos 5×5, donde el eje horizontal representa la probabilidad y el vertical el impacto.
 Los elementos en la esquina superior derecha (Alta Probabilidad / Alto Impacto) deben recibir prioridad absoluta en las pruebas automatizadas, de integración y aceptación.
 Aquellos con impacto medio o bajo pueden probarse de manera exploratoria o programarse en ciclos posteriores.

Esta matriz no es un documento para archivar, sino una guía viva que se revisa y ajusta conforme el producto evoluciona.
 En equipos ágiles, su actualización puede formar parte del refinamiento del backlog o del sprint planning.

El documento no es lo importante: la conversación sí

En metodologías ágiles, la planeación basada en riesgos no requiere un documento extenso ni formal.
 Lo esencial es que el equipo —Product Owner, QA y desarrollo— realice el ejercicio mental de identificar, discutir y priorizar los riesgos antes de construir.
 Esa conversación crea un entendimiento común de qué debe protegerse primero y por qué.

Al final, la trazabilidad de la calidad no se logra solo con herramientas, sino con claridad colectiva: todos entienden qué se está protegiendo y cuál es el costo de no hacerlo.

Conclusión: probar con propósito

La planeación de pruebas basada en riesgos es más que una técnica: es una mentalidad.
 Permite que el aseguramiento de calidad sea estratégico, priorizando aquello que realmente sostiene el valor del negocio.
 En lugar de medir el éxito por la cantidad de pruebas ejecutadas, los equipos ágiles lo miden por la calidad de las decisiones tomadas.

Probar con propósito significa invertir esfuerzo donde más retorno genera, reducir desperdicio y fortalecer la confianza en cada entrega.
 Porque en última instancia, la calidad no consiste en probar más, sino en probar mejor.

El cargo Impacto y Probabilidad: Diseñando la Planificación de Pruebas Basada en Riesgos 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.

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.

Introducción:

Las pruebas de software han evolucionado desde el modelo cascada al iterativo, del iterativo al ágil y de la ágil a DevOps. Cada uno más avanzado y exigente que el anterior.

Las metodologías iterativas nos concientizan de la necesidad de probar “por partes” dado que el proyecto que se realizan en “mini-cascadas”. Estas “mini-cascadas” ayudan a que las validaciones no queden al final dando la posibilidad de detectar errores de forma más pronta. También nos enseña que es necesario que los tiempos de ejecutar las pruebas de regresión sean menores, y por eso impulsan la automatización cuando el software que ya está desarrollado “y estable”.

Retos de la Agilidad:

Agilidad nos trae unos retos diferentes en pruebas, más allá de ejecutar varias veces las pruebas. Lo voy a resumir en dos retos principales:

El primer reto es la cross-funcionalidad que significa la colaboración entre los diferentes roles para poder ejecutar las pruebas no solamente al final de la iteración sino en medio de la iteración, incluso en los primeros días de la iteración. Ese es el reto que se tiene en pruebas, cuando estamos hablando de agilidad: Las iteraciones que dejan las pruebas al final no son agiles; las pruebas que se dejan para después de la iteración, mucho menos.

Las pruebas continuas a lo largo del sprint es un gran diferencial que hay entre la agilidad y el manejo iterativo.

Y el segundo reto que trae la agilidad es que se prevengan los errores por medio del TDD (desarrollo dirigido por pruebas). TDD nos invita a que al momento de definir el requerimiento se identifiquen los escenarios de prueba que deben ser cubiertos por el desarrollo que vamos a hacer, así se pueden prevenir los errores que se generan cuando un desarrollador no tiene claridad de todos los “caminos de uso” que debe cubrir su código. Y el reto más interesante es que nos invita a automatizar los escenarios de prueba antes de codificar.

¿Porque es útil este enfoque?

1. Para que haya disponibilidad para el desarrollador un conjunto suficientemente completo de pruebas, que se pueden ejecutar de forma rápida hasta que se valide que todo su desarrollo es correcto.

2. Queda de una vez listo para que se incluya en las pruebas de regresión, que ya sabemos que son fundamentales para demostrar que el software no se ha dañado a lo largo del desarrollo de nuevas funcionalidades.

3. El tercero, consecuencia del anterior y muy necesario cuando hablamos de agilidad, es que nos permite el refactoring. Se llama el refactoring el volver a desarrollar lo que ya estaba desarrollado cambiando su diseño para mejorarlo, o para ampliarlo. El refactoring es una consecuencia propia de la agilidad porque la agilidad está hecha para el cambio continuo del software, incluyendo el cambio de la conceptualización del software y diseño. Por ese motivo debemos prepararnos para el refactoring como algo propio de las metodologías ágiles: el TDD nos prepara para el refactoring.

El TDD nace desde el concepto de la automatización de las pruebas de componentes. Pero Dan North posteriormente cae en cuenta que, aunque este concepto es poderoso, es muy limitado dado que pierde la visión sistémica necesaria del desarrollo de software, y por eso crea el llamado BDD, en donde se pretende que tenga el mismo concepto de desarrollo dirigido por pruebas, pero ya no desde el punto de vista de componente, sino desde el punto de vista de pruebas de sistema, teniendo en cuenta el sistema completo.

¿Y DevOps?

DevOps efectúa la salida a producción continua y la colaboración requerida entre desarrolladores y operadores. La salida a producción continua nos quita el concepto que antes existía que era la fase de estabilización, debido al despliegue continuo.

¿Qué implicaciones tiene en término de pruebas?

Por un lado, la automatización de la validación del software pasa a otro nivel, dado que el objetivo ya no es solo disminuir los tiempos de ejecución, sino que se realice de forma autónoma sin intervención humana, como parte del pipeline del despliegue y con el poder de devolver automáticamente la puesta a producción si existe algún error en el software, todo sin asistencia.

Además, deben existir mecanismos orientados al seguimiento de la calidad en producción operación, para validar de forma automática que el comportamiento es el esperado después del despliegue y a lo largo de su uso, generar las alarmas si esto no llega a pasar, y mecanismos de seguimiento al error que permitan hacer verificación y posterior planeación de la solución de un error cuando se está en producción de forma continua, y corrección de datos si es necesario.

En conclusión, ya no hay fase de prueba, ni mini-fase de prueba, ni micro-fase de prueba. Agilidad y DevOps requieren de continua interacción del equipo alrededor de la calidad y las diferentes actividades de pruebas se realizan todo el tiempo para servicio de todo el equipo y por supuesto, del cliente final.

Bibliografía

• Berg, Craig. DevOps for Beginners. A complete guide to DevOps Best Practices, Including How You Can Create World-Class Agility, Reliability, And Security In Technology Organizations With DevOps, Edición de Kindle.
• Bergstr, Stefan. Adopting the Rational Unified Process: Success with the RUP. Addison Wesley. 2004
• Crispin, Lisa. Agile Testing (Addison-Wesley Signature Series (Cohn)). Pearson Education. 2009. Edición de Kindle.
• Crispin, Lisa. Gregory, Janet. More Agile Testing, Learning Journeys for The Whole Team (Addison-Wesley Signature Series (Cohn)). Pearson Education. 2015. Edición de Kindle.
• J. Humble, C. Read and D. North, “The deployment production line,” AGILE 2006 (AGILE’06), Minneapolis, MN, 2006, pp. 6 pp.-118, doi: 10.1109/AGILE.2006.53.
• Krutchen, Phillippe. The Rational Unified Process: An introduction. Addison Wesley. 2004.
• Smith, Larry. “Shift-Left Testing”, Dr Dobbs, 2001

El cargo Pruebas ágiles, para llevar adecuadamente la agilidad en el desarrollo de software apareció primero en Enjisst.

El tema de pruebas ha tenido evolución dramática a lo largo de los últimos años, según lo he visto y experimentado desde que inicié a trabajar en proyectos de software. Hace 28 años, cuando empecé mi experiencia en proyectos de software, había claridad que la metodología a aplicar era cascada, y se creía que el aspecto clave del éxito del proyecto era que los requerimientos estuvieran muy bien definidos; de forma que lo único que se debía hacer en la etapa de pruebas era validar el correcto cumplimiento de esos requerimientos. Sin embargo, en ese momento pruebas no era rol especial, más bien era una etapa donde se validaban los requerimientos, y no había conciencia de lo extenso y profundo que puede ser la validación del software.

Hace unos 20 años, por lo menos en Colombia, empiezan algunas organizaciones a crear conciencia de la necesidad del rol, y hace 10 años ya se podían encontrar en varias empresas las áreas de Calidad, pruebas, QA o el nombre que fuera más apropiado para la empresa.

Si bien, las técnicas de calidad son mayores en las organizaciones, lo que redunda en principio, en mayor calidad para el software, fue implementado de forma taylorista , por silos,  en donde después de hacer el desarrollo se pasa a una etapa de validación, para “filtrar” los errores y que no pasen a producción.

Al igual que en cualquier aprendizaje, el medio primero aplicó las técnicas básicas para entender los pasos necesarios para producir software con mayor calidad. Se crearon mecanismos para que las personas entendieran esas técnicas, lo que se puede encontrar en los entes certificadores de conocimiento sobre pruebas, y se ve mucha mayor evolución de conciencia en los aspectos y niveles funcionales y no funcionales que debe incluir la correcta y completa validación del software, por medio de pruebas y de aseguramiento de la calidad.

Sin embargo, a pesar de que las propuestas metodológicas han cambiado, y hay mayor enfoque hacia el manejo iterativo, como puede ser Scrum que trabaja por sprints, todavía no se ha comprendido el impacto en lo que significa tanto en la forma de probar como en la interacción entre el equipo.

Voy a explicar mi punto basado en una gráfica de Scaled Agile Framework (SAFe) que lo permite visualizar de forma clara:

En varias empresas he encontrado la forma de trabajo que SAFe llama “cascada entre iteraciones” (primera gráfica). Por eso se refieren a sprints de pruebas, sprints de desarrollo e incluso sprints de diseño. Si bien, puede ser una forma válida de trabajo, es importante aclarar que difiere de los principios ágiles, en donde según refiere el Manifiesto Ágil: “Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible”; es entregar software, no es desarrollar software.

En un número mayor de empresas he encontrado que implementan “cascada dentro de las iteraciones” (segunda gráfica), que era la forma que proponía RUP ( Rational Unified Process), como forma de trabajo. Es una ganancia mayor con respecto a la primera porque al final de cada iteración se puede tener un entregable claro, ejecutable y probado.

Pero es el manejo de “iteraciones de funciones cruzadas” (tercera gráfica) la que permite implementar principios de Scrum tan importantes como es Timeboxing y entrega de valor basada en priorización.

Este manejo implica retos importantes como es el saber dividir las funcionalidades de forma que se pueda desarrollar por requerimientos tan cortos que puedan estar diseñados, desarrollados y probados en pocos días, que la automatización de pruebas esté implícita en el trabajo, porque la ejecución continua y repetitiva de pruebas será parte del día a día, y que el trabajo colaborativo sea la premisa, evitando desgastes entre los roles, que muchas veces se presentan entre desarrolladores y probadores. 

Bibliografía:

• SAFE Reference Guide 4.0. Dean Leffingwell
• The Rational Unified Process, An introduction. Phillippe Krutchen

El cargo Paradigmas de pruebas en las iteraciones apareció primero en Enjisst.

La industria del software es la industria más importante de nuestro tiempo [1], y está muy impactada por el ritmo de vida actual, que cambia cada vez más rápido.

Por ese motivo, requiere de prácticas que permitan producción continua de software, dentro de un ámbito de generación de valor incremental y permanencia de la calidad.

Si no se valida adecuadamente la calidad, pero se sale continuamente a producción, cada versión en lugar de aumentar el valor del activo (que es el software), lo está devaluando (generando deuda técnica).

Se requiere entonces un concepto metodológico de desarrollo que cumpla con la visión completa de la agilidad, como lo muestra Dan Leffinwell [2] en la siguiente gráfica:

“Evita las iteraciones “mini-cascadas”, a través de las iteraciones crossfuncionales.

Este artículo muestra el concepto de “Desarrollo Trenzado” como pilar fundamental de la metodología “Parex”, soportado por la plataforma “Enjisst”. Este concepto se puede aplicar dentro de las iteraciones, o incluso dentro de un flujo continuo Kanban. La aplicación de estos conceptos en diversos proyectos ha demostrado su efectivada para mejorar la calidad en mínimo un 70% y la velocidad de desarrollo en un 50% o más.

II.                 DESCRIPCIÓN

Para esto es necesario cambiar nuestros paradigmas, y dentro de ello modificar nuestro pensamiento de etapas a disciplinas. En desarrollo, la mayoría de equipos todavía piensa en las fases de requerimientos, desarrollo y pruebas, incluso como si fueran “mini-fases” dentro de la iteración.

Mientras mantengamos este paradigma seguiremos pensando en silos. Para explicar el paradigma tradicional pensemos en una carrera de relevos, que se compone de silos. Los silos son los pasos de la posta entre los atletas, en donde terminas los requerimientos para pasar la posta a desarrollo y luego termina la carrera las personas de pruebas.

Para pensar en agilidad es necesario cambiar de deporte: vamos a pasar del atletismo a un deporte de mayor interacción y agilidad como es el baloncesto.

Es de anotar que llamamos acá agilidad, la capacidad del equipo de responder ante el cambio, y de generar resultados de valor, en un deporte donde no se genera un solo valor (ganar la carrera), sino generar varios resultados de valor (anotar cestas).

En el baloncesto vamos a tomar roles: armador (base), aleros y postes (pivot); que utilizan una jugada llamada trenza. La trenza se caracteriza por:

·         Busca rápidamente generar un resultado de valor (trenza)

·         Los jugadores poco mantienen en sus manos el balón.

·         Se hace interacción continua entre los jugadores.

·         Los jugadores buscan recibir el balón en una posición que acerque hacia la cesta.

·         Los jugadores corren detrás de los otros, para no afectar el envío del balón.

·         Cada rol hace pequeñas carreras (dos pasos) pasando el balón a otro rol y recibirlo más adelante para nuevamente pasarlo pronto a otro rol.

En el “Desarrollo Trenzado” cada rol hace algunas actividades y pasa el balón a otro rol. Se hace de manera continua. A diferencia del baloncesto, el desarrollo trenzado es como si se jugara con dos o máximo tres balones.

Así en el momento inicial, el product owner (o rol de requerimientos) define una historia bien refinada y con apoyo de QA define el paquete de ideas y bocetos de escenarios de pruebas de una historia. Los escenarios de pruebas son base para el desarrollo y así el programador cuenta con los escenarios de base para diseñar el requerimiento, y así mismo la forma de ejecutar desde la perspectiva de sistema su desarrollo. Los desarrollos se van completando por escenarios de prueba. El QA recibe los escenarios (por paquetes) que va validando continuamente en ambiente de certificación según criterio. En esta certificación ejecuta pruebas de regresión, haciendo validación por el producto de software completo (no solo las historias). La certificación continua se puede tomar como el encestar, en este caso varios balones al mismo tiempo.

De forma continua el product owner acompañado con usuarios va validando el comportamiento del sistema, también por escenarios que se vayan entregando.

Este proceso es cíclico y continuo hasta que el paquete de historias haya concluido.

Así, el proceso de desarrollo fluye entre los tres roles principales: PO, QA y desarrollador, como una danza alrededor de los escenarios de prueba que están diseñados para evaluar el impacto de las historias de usuario, pero no para validarlas.

III.              CONDICIONES

Una de las condiciones fundamentales en este manejo de escenarios es el pensamiento sistémico del producto de software, orientado a los escenarios completos de uso y validación del software para bajar el riesgo inherente al desarrollo. Se quiere ver reflejado un conjunto de escenarios básicos de uso y validación y todas sus variantes, la nueva forma de interactuar una vez se haya implementado la historia de usuario.

La segunda condición es contar con un mecanismo para automatizar pruebas rápidamente que siga el ritmo de “la jugada”.

Adicionalmente, la automatización en lenguaje de usuario permite que el equipo se pueda comunicar alrededor de las pruebas. Porque si el product owner, desarrollador o usuario tienen conflictos para el entendimiento de las pruebas automatizadas, no es posible llevar el “Desarrollo Trenzado” en la velocidad y fluidez requeridos para que este concepto lleve a la agilidad.

Por último, tener en el equipo el concepto de pruebas ágiles, en donde QA tiene como misiones “criticar el producto” y también “ser soporte al desarrollo”, como se ve en los cuadrantes de pruebas [3].

En esa medida, QA es un rol de colaboración, en donde sus habilidades de criticidad, visión de producto, identificación de riesgos entre otros, se ponen al servicio del equipo para la aplicación de las prácticas tanto de calidad como de agilidad.

IV.               CONCLUSIÓN

El desarrollo trenzado que propone “PAREX”, apoyado con la plataforma “Enjisst” para la automatización rápida de pruebas en lenguaje de usuario y por perfiles no especializados, incluye los siguientes conceptos de calidad:

1.       Definición de criterios de aceptación de requerimientos, basado en la definición de escenarios de pruebas.

2.       Walkthrough con usuarios para la revisión informal de los requerimientos.

3.       Shift-left-testing [4] como mecanismo para ejecutar pruebas funcionales y no funcionales en momentos muy tempranos del proceso de desarrollo

Unidos con conceptos de calidad como:

·         Crossfuncionalidad que consiste en la habilidad del equipo que combina las ideas desde las diferentes disciplinas

·         Roles T dado el aumento de capacidad del equipo de automatizar e interpretar las pruebas

·         BDD: [5] y [6] Desarrollo dirigido por pruebas de comportamiento que lleva a la compresión del equipo a través de la definición del comportamiento por escenarios de validación

·         ATDD: complementando la anterior definición, incluye la definición de las pruebas de aceptación

·         Y la entrega continua de software funcionando

Por los motivos anteriormente expuestos, la combinación PAREX-Enjisst ha demostrado resultados impactantes que hicieron merecedores a los galardones: premio ingenio al caso de éxito de servicio y el premio al ingenio y la innovación.

V.                 REFERENCIAS

[1] D. Leffingwell, Scaling Software Agility: Best Practices for Large Enterprises, Kindle Edition ed., A. S. D. Series, Ed., Pearson Education.

[2] D. Leffingwell, SAFe® 4.0 Reference Guide: Scaled Agile Framework® for Lean Software and Systems Engineering., Edición de Kindle. ed., Pearson Education..

[3] C. Lisa y G. Janet., Agile Testing. A practical guide for testing and agile teams, Edición de Kindle ed., A. S. Series, Ed., Pearson Education..

[4] L. Smith, Shift-left Testing, Dr. Dobb’s Journal, vol. 26, no. 9, pp. 56–ff, 2001.

[5] N. S. A. S. A. &. C. R. Nascimento, «Behavior-Driven Development: An Expert Panel to evaluate benefits and challenges,» de SBES ’20, Natal, Brazil, 2020.

[6] A. Stellman y J. Greene, Learning Agile: Understanding Scrum, XP, Lean, and Kanban, O’Reilly Media, 2014.

El cargo Desarrollo Trenzado…un deporte de equipo apareció primero en Enjisst.