Cucumber puede ayudar mucho en QA, pero no por tener archivos .feature el equipo está haciendo BDD. Sirve cuando ayuda a discutir comportamiento entre negocio, QA y desarrollo. Si se usa para disfrazar scripts técnicos con frases en Gherkin, empieza a molestar más de lo que aporta.

Uso correcto de Cucumber en QA

Para que Cucumber no se vuelva una carpeta cara de .feature, tiene que hablar de negocio. Los escenarios deberían explicar una regla, una decisión o un flujo crítico; no repetir clicks, selectores ni detalles internos de implementación.

  • Escribir Gherkin en lenguaje de dominio, no en términos técnicos internos.
  • Mantener un objetivo por escenario para que el fallo sea fácil de diagnosticar.
  • Definir criterios de aceptación con ejemplos antes de automatizar.
  • Desacoplar steps de detalles frágiles de UI mediante helpers o page objects.
  • Ejecutar por capas en CI: smoke, regresión crítica y suite completa según riesgo.

Fallos comunes al usar Cucumber

Cuando una suite con Cucumber empieza a perder sentido, casi siempre aparecen estos olores:

  1. Gherkin convertido en script técnico: deja de ser un lenguaje compartido.
  2. Escenarios largos o mezclados: un solo test intenta validar demasiadas cosas.
  3. Steps duplicados o ambiguos: aumenta el mantenimiento y aparecen inconsistencias.
  4. Acoplamiento fuerte a UI: pequeños cambios visuales rompen pruebas de comportamiento.
  5. Datos de prueba inestables: aparecen falsos fallos y re-ejecuciones manuales.
  6. Medir éxito por cantidad de escenarios: se pierde foco en cobertura de riesgo real.

Señales de alerta

  • La suite crece, pero no bajan los defectos en producción.
  • El equipo evita tocar escenarios porque se rompen con cambios menores.
  • Hay mucho flakiness y dependencia de re-runs.
  • Los escenarios solo se entienden leyendo implementación técnica.

Dónde trazo la línea

Cucumber funciona bien cuando documenta y valida comportamiento de negocio con disciplina de mantenimiento. Si ayuda a que el equipo discuta ejemplos reales antes de automatizar, sirve.

Si solo agrega una capa más para escribir lo mismo que ya estaba en el test, no es calidad: es ceremonia. Y la ceremonia, cuando nadie entiende por qué existe, termina siendo deuda técnica con mejor formato.