Yerkin: redactar casos automatizables

Curso de Fundamentos de Pruebas de Software

Contenido del curso

Introducción

1
Fundamentos de testing moderno para mejorar software
01:19 min

Principios de las pruebas

Testing

Gestión, monitoreo y control

Gestión de bugs

Depuración

Bases de la automatización de pruebas

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:006:31

Yerkin: redactar casos automatizables

Curso de Fundamentos de Pruebas de Software

Clase 28 de 29

Clase 28 / 29

Recursos

La eficiencia en testing empieza con el negocio y termina evitando retrabajo. Aquí verás cómo Yerkin, un lenguaje de texto plano con estructura, acelera la transición de casos manuales a automatización, estandariza la redacción y mejora la colaboración del equipo. Con keywords simples y pasos claros, ahorrarás tiempo de diseño y mantenimiento sin perder contexto.

¿Por qué el testing debe enfocarse al negocio y reducir retrabajo?

Priorizar el valor de negocio guía qué validar y cómo hacerlo. Además, limitar el retrabajo es clave para mantener calendarios y calidad. El retrabajo surge por malas prácticas y por no seguir procesos: flojera, desconocimiento o distracciones. Todo esto encarece el mantenimiento, dificulta el entendimiento de los casos y retrasa la automatización.

Enfoque al negocio para validar lo importante primero.
Procesos claros para evitar errores repetidos.
Redacción estandarizada para que cualquiera entienda los casos.
Transición fluida a automatización sin reinterpretar requisitos.

¿Qué es Yerkin y cómo estandariza los casos de prueba?

Yerkin es un lenguaje de pseudocódigo en texto plano que describe qué hacer en cada caso de uso. Es fácil de aprender y entender por todos, por lo que comunica mejor entre testers y quienes automatizan. Sus ventajas: simpleza, uso de palabras clave, estandarización de casos y reducción del tiempo de diseño.

Lenguaje de texto plano con estructura para legibilidad y consistencia.
Comentarios con hashtag que se omiten en la ejecución.
Casos modulares y reutilizables para mantenimiento sencillo.

¿Qué keywords se usan en Yerkin?

Las palabras clave guían la lectura y la ejecución:

future: describe de qué trata el caso de prueba.
escenario: define el contexto inicial.
given, when, then, and, but: especifican los pasos y resultados esperados.

¿Cómo se escribe un caso con Yerkin?

Ejemplo inspirado en la redacción propuesta:

future: el usuario abre una puerta de perilla para salir
# puedes documentar detalles sin que se interpreten
escenario: el usuario tiene una puerta de perilla cerrada
given: girando la perilla
when: la puerta abre hacia afuera
then: la puerta queda abierta
and: el usuario puede salir

future presenta el objetivo del caso.
escenario fija el estado inicial.
given/when/then ordenan acciones y resultados.
Los comentarios con hashtag documentan sin afectar la ejecución.

¿Cómo usar variables y modularidad para mantener y automatizar?

Cuando el software está estable, es buen momento para automatizar. Pero si el equipo no entiende los pasos, todo se vuelve conflicto. Yerkin ayuda a que todas las áreas compartan el mismo entendimiento y a que el mantenimiento sea mínimo.

Usa variables para probar diferentes cantidades o datos. Por ejemplo, cambiar “una” por una variable para abrir 2, 3 o 10 puertas.
Cambia términos como “perilla” por una variable si el mecanismo es similar. Si el mecanismo cambia (eléctrica, botón, jaladera, empujar), los pasos quizá ya no apliquen.
La modularidad evita scripts enormes y facilita actualizar un solo script o palabra para ajustar miles de pruebas.
Diseña pasos reutilizables como si fueran código, para acelerar la automatización y reducir errores.

¿Tú cómo redactas tus casos de prueba para que sean claros y automatizables? Comparte tus ejemplos y dudas en los comentarios.

Francisco Antonio Hernandez Sabatino

Hace un año

🥒 <u>Automatización de Casos de Prueba con Gherkin</u>

Gherkin es un lenguaje diseñado para cerrar la brecha de comunicación entre los miembros técnicos y no técnicos de un equipo de desarrollo. No es un lenguaje de programación, sino un lenguaje de dominio específico (DSL) que utiliza texto plano con una estructura definida para describir el comportamiento de una aplicación de forma clara y legible para cualquier persona.

Al usar palabras clave en un formato similar al pseudocódigo, permite que analistas de negocio, Product Owners, testers y desarrolladores colaboren en la definición de los casos de prueba, asegurando que todos tengan un entendimiento compartido de lo que el software debe hacer.

✅ Ventajas de Usar Gherkin

Simple y Legible: Está diseñado para ser fácil de aprender y ser entendido por todos, eliminando la ambigüedad en los requerimientos.
Estandariza los Casos de Prueba: Proporciona una estructura coherente para documentar el comportamiento esperado del sistema, lo que facilita la creación y el mantenimiento de los tests.
Fomenta la Colaboración: Actúa como un "lenguaje común" que permite a perfiles de negocio y técnicos trabajar juntos en la definición de los criterios de aceptación.
Reduce el Tiempo de Diseño: Al tener requerimientos claros y ejemplos concretos desde el principio, se agiliza tanto el desarrollo como la creación de pruebas.
Base para la Automatización: Aunque es legible para humanos, su estructura permite que herramientas como Cucumber o SpecFlow lo interpreten y lo conviertan en pruebas automatizadas ejecutables.

⚠️ ¿Desventajas o Desafíos?

Aunque Gherkin ofrece múltiples beneficios, su implementación puede presentar desafíos:

Mantenimiento: Si los escenarios en Gherkin no se mantienen actualizados junto con la aplicación, rápidamente se convierten en documentación obsoleta y poco fiable.
Exceso de Detalle: Existe el riesgo de escribir escenarios demasiado técnicos o detallados, perdiendo el enfoque en el comportamiento del negocio y dificultando su lectura para perfiles no técnicos.
Curva de Aprendizaje en la Redacción: Aunque el lenguaje es simple, aprender a escribir escenarios de comportamiento efectivos (qué probar, y no cómo probarlo) requiere práctica y un cambio de mentalidad.

📜 Estructura y Palabras Clave de Gherkin

Gherkin organiza el comportamiento del software utilizando una jerarquía de palabras clave. Cada una tiene un propósito específico para dar contexto y estructura a los escenarios de prueba.

A continuación se desglosa el ejemplo proporcionado:

Feature: Proceso de compra en la tienda en línea

Feature (Característica): Es la descripción de más alto nivel de una funcionalidad del software. Agrupa un conjunto de escenarios relacionados.

Scenario: Compra exitosa de un producto

Scenario (Escenario): Describe un ejemplo concreto de cómo debería comportarse la funcionalidad. Es una secuencia de pasos que ilustra una regla de negocio.

Given el usuario ha iniciado sesión en la tienda

Given (Dado que): Establece el contexto o las precondiciones iniciales. Pone al sistema en un estado conocido antes de que ocurra la acción principal.

And tiene productos en su carrito

And (Y): Permite añadir más condiciones a un paso anterior (Given, When o Then) sin tener que repetir la palabra clave, haciendo el escenario más legible.

When el usuario procede al pago

When (Cuando): Describe la acción principal o el evento que realiza el usuario o el sistema, y que desencadena el comportamiento que se está probando.

And ingresa sus datos de tarjeta correctamente

Aquí, And se usa de nuevo para añadir una segunda acción al paso When.

Then la compra debe ser procesada exitosamente

Then (Entonces): Describe el resultado esperado. Es la verificación o la consecuencia que se debe cumplir después de ejecutar la acción del When.

And debe recibir un correo de confirmación

And se usa para añadir una segunda verificación al resultado esperado.

But si el correo es inválido, no debe enviarse la confirmación

But (Pero): Funciona de manera similar a And, pero se usa para añadir una condición negativa o una excepción al paso anterior, mejorando la legibilidad del escenario.

Comentarios (50)50 comentarios

Daniela Muñoz Jiménez

Hace 7 años

Iván Mora Mallqui

María Inés Santander Arrazola

Hace 6 años

Natalia Opazo González

Hace 5 años

Nelly Alejandra Reina Buitrago

Nicolás Kryvenki

Antonio Rafael González Ferrer

Gustavo Adolfo Escobar y Escobar

Hace 3 años

Alexis Anthony Roman Santibañez

Cristian Blandon

Irving Juárez

Juan José Rodríguez Duque

Alfredo Moya

Daniel Mauricio Riaño Pedraza

Hace 4 años

Mauricio Enrique Fernandez Lopez

Sergio Guzmán Segovia

Camilo Leon Castillo

Ginna Chacon

Mauro Arteaga Acosta

Carlos Uriel de Jesus Sánchez González

Hace 8 años

Diego Adrián Sánchez Gutiérrez

Martín Leyva

Carmen Álvarez M.

Andres Velasquez

Sandra Castro Ballesteros

Rodolfo Manuel Arroyo Morelo

Luis Enrique Aguirre

JUAN FELIPE CONTRERAS DELGADO

Freddy Humberto Mendoza Muñoz

Introducción

Fundamentos de testing moderno para mejorar software

Principios de las pruebas

Por qué el testing moderno previene errores

Pruebas de software en cada etapa del desarrollo

Pruebas en el Ciclo de Vida del Software: Mejora y Optimización

Anomalía vs defecto vs fallo vs error

Los siete principios del testing moderno

Roles de testing especializados y tu path de crecimiento

Testing

Testing en cada fase del desarrollo

Mapas mentales para estrategias de testing

Testing vs checking en automatización de pruebas

Testing ágil: todo el equipo prueba

Niveles de pruebas: componentes a sistema

Tipos de pruebas de software explicados

Pruebas estáticas vs dinámicas en testing

Cómo diseñar casos de prueba efectivos

Gestión, monitoreo y control

Pruebas de caja negra, blanca y gris

Control y monitoreo de pruebas paso a paso

Cuatro roles clave en equipos de QA

Roles y Responsabilidades en el Testing de Software

Gestión de bugs

Responsabilidades de roles en equipos de pruebas

Métricas y dashboards para control de testing

Gestión de defectos sin sobrecostos

Defectos vs sugerencias: cómo reportar bien

Depuración

Diferencia entre testing y debugging

Pruebas de verificación sin reusar datos

De debugging reactivo a logs preventivos

Bases de la automatización de pruebas

Cuándo automatizar pruebas y cómo prepararse

Yerkin: redactar casos automatizables

Responsabilidades del tester en proyectos

Yerkin: redactar casos automatizables