WorksheetsGherkin Certificación
Total questions: 28
Worksheet time: 31mins
¿Por qué se recomienda separar escenarios positivos y negativos?
Garantizar la automatización inmediata
Evitar HU demasiado largas
Facilita la lectura y el análisis de errores.
Reemplazar y reutiliza pasos en contextos afines
¿Qué característica distingue una Historia de Usuario de un requisito funcional tradicional?
Describe beneficios o valor esperado.
Se redacta desde la perspectiva del usuario.
Incluye diagramas UML obligatoriamente.
Está escrita en lenguaje técnico detallado
Al transformar un requisito funcional en historia de usuario, ¿qué riesgo surge si no se incluye el beneficio esperado?
La historia se vuelve demasiado técnica.
Se pierde la justificación de valor para el usuario.
Los escenarios Gherkin no pueden redactarse.
El rol del actor cambia automáticamente.
Al construir escenarios desde HU, ¿qué debe guiar la selección de 3 escenarios por HU?
Los flujos más fáciles de automatizar.
El happy path, un error frecuente y un caso alternativo/límite.
Los procesos que más utiliza el administrador.
Los pasos con menos esfuerzo en Test Points
l convertir “La aplicación debe mostrar un mensaje de error si el usuario ingresa un usuario no registrado” a HU ¿cuál es la mejor redacción?
Como usuario, quiero recibir un mensaje si ingreso un usuario no registrado para saber que debo verificar usuario o crear una cuenta.”
“Como administrador, quiero notificaciones de usuarios no registrados para auditar intentos.”
“Como usuario, quiero que el sistema valide el usuario para evitar accesos no autorizados.”
“Como usuario, quiero ver un error al ingresar usuario inválido.”
Para la siguiente Historia de Usuario:
Yo como comprador de vivienda deseo consultar ofertas en MercadoLibre con filtros de ciudad y precio.
Instrucción: Escriba un escenario positivo y uno negativo aplicando Background.
Para la siguiente Historia de Usuario:
Yo como usuario deseo crear una cuenta en Gmail ingresando datos válidos.
Instrucción: Redacte un escenario con Data Table para los campos de registro.
Enunciado con errores:
Feature: Consultar vuelos
Scenario: Buscar vuelos Given origen BOG y destino MDE
When fecha 10/10/2025
Then resultados ok
, se espera correción:
Enunciado con errores:
Feature: Pagos en plataforma
Background El usuario logueado
Scenario: Pago exitoso
When selecciona servicio "Agua"
Then mensaje Pago Exitoso
,Corregir:
Corregir, enunciado con errores:
Feature: Login usuarios
Background: usuario abre login Scenario
Outline: Accesos Given usuario "<user>" pass "<pass>"
Then acceso ok
Examples:
| user | pass |
| correcto | valido |
| errado | malo |
