Especificaciones de Requisitos: Saber Lo Que Intentas Hacer
Cuando se trata de cerrar la brecha entre “lo que quiere el negocio” y “lo que construyen los ingenieros,” la industria ha desarrollado varias sintaxis distintas. Estas van desde estructuras narrativas (Gherkin) hasta restricciones lógicas rígidas (EARS).
Aquí hay una comparación de los estilos de especificación y definición de pruebas más prominentes.
1. Gherkin (Desarrollo Dirigido por Comportamiento)
Gherkin es el lenguaje usado por herramientas como Cucumber. Está diseñado para ser legible por partes interesadas no técnicas mientras permanece ejecutable como pruebas automatizadas.
Estructura: Usa una plantilla Dado-Cuando-Entonces.
- Dado: El contexto inicial (Configuración).
- Cuando: El evento o acción (Disparador).
- Entonces: El resultado esperado (Aserción).
Mejor Para: Validar historias de usuario y lógica de negocio.
Pros: Alta legibilidad; crea “Documentación Viva.”
Contras: Puede volverse verboso; se requiere “código pegamento” para conectar el texto con los scripts de prueba reales.
2. EARS (Enfoque Fácil para Sintaxis de Requisitos)
A diferencia de Gherkin, que se enfoca en probar un comportamiento, EARS es un conjunto de reglas para escribir mejores requisitos para reducir la ambigüedad en sistemas complejos (común en software aeroespacial o médico).
Estructura: Usa patrones específicos basados en el tipo de requisito:
- Ubicuo: “El sistema deberá [acción].”
- Dirigido por Eventos: “Cuando [disparador], el sistema deberá [acción].”
- Dirigido por Estado: “Mientras [estado], el sistema deberá [acción].”
- Característica Opcional: “Donde [característica está incluida], el sistema deberá [acción].”
Mejor Para: Ingeniería de sistemas de alto riesgo e interfaces hardware/software.
Pros: Elimina declaraciones “deberá” vagas y “voz pasiva”; increíblemente riguroso.
Contras: Se siente “rígido” para equipos creativos; no se mapea directamente a marcos de pruebas automatizadas sin traducción.
3. Matriz Comparativa
| Estilo | Objetivo Principal | Audiencia Objetivo | Palabra(s) Clave |
|---|---|---|---|
| Gherkin | Automatización de Pruebas / Comportamiento | POs, QAs, Devs | Given, When, Then |
| EARS | Claridad de Requisitos | Ingenieros de Sistemas | While, Where, Shall |
| TDD (Unidad) | Corrección de Código | Desarrolladores | Assert, Expect, Should |
| Tabular | Lógica Dirigida por Datos | Analistas, Devs | Input, Output, Table |
4. Otros Sistemas Notables
Estilo TDD (Pruebas Unitarias)
Esta es la “Sintaxis del Desarrollador.” Es puramente técnica y usualmente sigue el patrón AAA (Arrange, Act, Assert - Organizar, Actuar, Afirmar).
Ejemplo: expect(user.isAdmin).to.be.true;
Diferencia: Carece de la narrativa “legible por humanos” de Gherkin y se enfoca en la implementación en lugar del requisito.
Tablas Tabulares / de Decisión
A menudo usado en FitNesse o Robot Framework, este estilo usa tablas para definir entradas y salidas esperadas.
Uso: Mejor para reglas de negocio complejas con muchas permutaciones (ej., primas de seguros o cálculos de impuestos).
Diferencia: Ignora completamente la estructura de “oración” de Gherkin y EARS en favor de cuadrículas de datos.
Especificación por Ejemplo (SbE)
Esto es menos una sintaxis y más una metodología a menudo implementada a través de Gherkin. Se enfoca en usar ejemplos concretos (números reales, nombres reales) en lugar de requisitos abstractos para definir cómo debe comportarse un sistema.
Resumen: ¿Cuál usar?
Usa Gherkin si necesitas un lenguaje compartido entre el Propietario del Producto y el Desarrollador para asegurar que se esté construyendo lo correcto.
Usa EARS si estás escribiendo una especificación técnica para un sistema complejo donde un malentendido de una “condición” o “estado” podría llevar a falla del sistema.