Lista de verificación de decisiones para formularios con Gherkin
Escribe escenarios Gherkin BDD en los que stakeholders y desarrolladores acuerden el comportamiento antes de programar, usando un formulario de perfil de arquitecto cloud como proyecto de ejemplo realista.
nota: Lo siguiente es un ejemplo; hay varias formas válidas de implementar el formulario. La clave es usar Gherkin para fijar el comportamiento esperado antes de escribir cualquier código de componente.
Mantén un nivel de detalle equilibrado en los escenarios: suficiente para especificar el comportamiento esperado sin dictar la implementación exacta.
Los escenarios deben ser legibles para stakeholders no técnicos y, al mismo tiempo, ofrecer una guía clara para los desarrolladores.
¿Por qué Gherkin antes del código?
Los escenarios Gherkin son especificaciones ejecutables escritas en lenguaje claro (Given/When/Then). Cierran la brecha entre los requisitos de negocio y el código de prueba:
- Stakeholders los leen como criterios de aceptación
- Desarrolladores los implementan como pruebas automatizadas
- QA los usa como plan de pruebas fuente de verdad
- Todos acuerdan el comportamiento antes de escribir una sola línea de código de componente
El proyecto de ejemplo: formulario de perfil de arquitecto cloud
Un formulario de varios pasos en el que los arquitectos cloud introducen su perfil profesional:
| Paso | Campos | Tipos |
|---|---|---|
| 1. Info personal | Nombre completo, email, teléfono, URL de LinkedIn | text, email, tel, url |
| 2. Experiencia | Años de experiencia, rol actual, certificaciones (selección múltiple), bio | number, select, checkbox, textarea |
| 3. Historial laboral | Nombre de empresa, rol, fechas de inicio/fin, descripción (grupo repetible) | text, select, date, textarea |
| 4. Habilidades | Plataformas cloud (AWS/Azure/GCP), especialidades (selección múltiple), nivel de competencia | checkbox, select, radio |
| 5. Cargas | Foto de perfil, diagramas de arquitectura, capturas del sitio | file (image), file (multiple) |
| 6. Revisión y envío | Resumen de todos los pasos, enlaces de edición, envío final | read-only, button |
Stack tecnológico: Next.js 15, TypeScript, react-hook-form, zod, shadcn/ui, Tailwind CSS v4
Lista de verificación de decisiones con escenarios Gherkin
Cada decisión a continuación se responde para el formulario de perfil de arquitecto cloud, seguida de los escenarios Gherkin que fijan el comportamiento esperado.
1. ¿Cuál es el propósito del formulario?
Decisión: Creación de perfil profesional para arquitectos cloud: captura identidad, experiencia, historial laboral, habilidades y cargas de portfolio para una plataforma de talento.
Por qué importa para Gherkin: El propósito determina qué campos son obligatorios, qué validación es crítica y cómo es el flujo posterior al envío.
Feature: Cloud Architect Profile Creation
Background:
Given the architect is logged in
And they navigate to "/profile/create"
Scenario: New architect sees empty profile form
Then they should see a multi-step form with 6 steps
And step 1 "Personal Info" should be active
And a progress indicator should show "Step 1 of 6"
Scenario: Completed profile is visible on the platform
Given the architect has submitted a valid profile
When a recruiter searches for "AWS Solutions Architect"
Then the architect's profile should appear in resultsEnfoque sugerido: Personaliza campos, validación y flujo posterior al envío para que coincidan exactamente con el caso de uso. Así el formulario resuelve la necesidad comercial real en lugar de construir campos genéricos que podrían requerir una remodelación pesada más adelante.
2. ¿Cuántos campos y qué tipos se necesitan?
Decisión: Más de 20 campos repartidos en 6 pasos: text, email, tel, url, number, select, selección múltiple (grupo de checkbox), radio, date, textarea y carga de archivos.
Feature: Field Types and Input Behavior
Scenario: Personal Info step has correct field types
Given the architect is on step 1 "Personal Info"
Then the "Full Name" field should be a text input
And the "Email" field should be an email input
And the "Phone" field should be a tel input
And the "LinkedIn URL" field should be a url input
Scenario: Experience step supports multi-select certifications
Given the architect is on step 2 "Experience"
When they check "AWS Solutions Architect Professional"
And they check "Google Cloud Professional Architect"
Then both certifications should be selected
And the selected count should show "2 selected"
Scenario: Job History supports repeatable entries
Given the architect is on step 3 "Job History"
When they click "Add Another Position"
Then a new empty job entry group should appear
And they should be able to add up to 10 positions
Scenario: Skills step uses radio buttons for proficiency
Given the architect is on step 4 "Skills"
When they select "Expert" for AWS proficiency
Then "Expert" should be selected
And "Intermediate" and "Beginner" should not be selectedEnfoque sugerido: Usa react-hook-form (no controlado bajo el capó) para este formulario complejo con arrays de campos dinámicos. Prefiere useFieldArray para las entradas repetibles de Historial laboral.
3. ¿Formulario de una página o de varios pasos?
Decisión: Varios pasos con 6 etapas. Más de 20 campos abrumarían a los usuarios en una sola página.
Feature: Multi-Step Navigation
Scenario: Architect progresses through steps
Given the architect is on step 1 "Personal Info"
And they have filled in all required fields
When they click "Next"
Then step 2 "Experience" should be active
And the progress indicator should show "Step 2 of 6"
Scenario: Architect navigates back without losing data
Given the architect is on step 3 "Job History"
And they have entered "Acme Corp" as company name
When they click "Back"
And they click "Next"
Then the company name field should still contain "Acme Corp"
Scenario: Architect cannot skip ahead past invalid steps
Given the architect is on step 1 "Personal Info"
And the "Full Name" field is empty
When they click step 3 in the progress indicator
Then step 1 should remain active
And a validation error should appear on the "Full Name" field
Scenario: Architect can click completed steps to edit
Given the architect has completed steps 1 through 4
And they are on step 5 "Uploads"
When they click step 2 in the progress indicator
Then step 2 "Experience" should be active
And all previously entered data should be preserved
Scenario: Progress indicator shows completion status
Given the architect has completed steps 1 and 2
And they are on step 3
Then step 1 should show a checkmark icon
And step 2 should show a checkmark icon
And step 3 should show as "current"
And steps 4 through 6 should show as "upcoming"Enfoque sugerido: Usa varios pasos con un componente stepper y react-hook-form. Los formularios de varios pasos reducen la carga cognitiva y mejoran las tasas de finalización. Usa una sola instancia de useForm en todos los pasos para conservar el state.
4. ¿Qué reglas de validación se requieren?
Decisión: Validación basada en esquema con zod: campos obligatorios, validación de formato, reglas condicionales y validación entre campos.
Feature: Form Validation
Scenario: Required fields show errors when empty
Given the architect is on step 1 "Personal Info"
And they have not filled in any fields
When they click "Next"
Then they should see "Full name is required"
And they should see "Email is required"
And the form should not advance to step 2
Scenario: Email format is validated
Given the architect is on step 1 "Personal Info"
When they type "not-an-email" in the "Email" field
And they click "Next"
Then they should see "Please enter a valid email address"
Scenario: LinkedIn URL must be a valid LinkedIn profile
Given the architect is on step 1 "Personal Info"
When they type "https://twitter.com/someone" in the "LinkedIn URL" field
And they click "Next"
Then they should see "Please enter a valid LinkedIn profile URL"
Scenario: Years of experience must be a positive number
Given the architect is on step 2 "Experience"
When they type "-3" in the "Years of Experience" field
And they click "Next"
Then they should see "Years of experience must be 0 or greater"
Scenario: At least one cloud platform must be selected
Given the architect is on step 4 "Skills"
And no cloud platforms are checked
When they click "Next"
Then they should see "Select at least one cloud platform"
Scenario: Job history dates must be logically valid
Given the architect is on step 3 "Job History"
When they set start date to "2025-06-01"
And they set end date to "2024-01-01"
And they click "Next"
Then they should see "End date must be after start date"
Scenario: Bio has a maximum character limit
Given the architect is on step 2 "Experience"
When they type 1001 characters in the "Bio" field
Then they should see "Bio must be 1000 characters or fewer"
And a character counter should show "1001 / 1000"
Scenario: Real-time validation feedback on email
Given the architect is on step 1 "Personal Info"
When they type "alice@" in the "Email" field
And they move focus to the next field
Then they should see "Please enter a valid email address"
When they go back and type "alice@example.com"
Then the error message should disappearEnfoque sugerido: Usa react-hook-form con zod para validación basada en esquema. Usa mode: "onBlur" para retroalimentación en tiempo real al perder el foco. Define un esquema zod por paso y un esquema combinado para el envío final.
5. ¿Dónde deben ir los datos al enviar?
Decisión: Server Action con useActionState: el formulario se envía al backend propio de la plataforma.
Feature: Form Submission
Scenario: Successful profile submission
Given the architect has completed all 6 steps with valid data
When they click "Submit Profile" on the review step
Then a loading spinner should appear on the submit button
And the button should be disabled
And after submission completes they should see "Profile created successfully!"
And they should be redirected to "/profile/me"
Scenario: Server returns validation errors
Given the architect submits a profile with a duplicate email
When the server responds with an error
Then they should see "This email is already registered"
And the form should navigate back to step 1
And the "Email" field should be highlighted
Scenario: Network failure during submission
Given the architect clicks "Submit Profile"
And the network request fails
Then they should see "Something went wrong. Please try again."
And the submit button should be re-enabled
And no data should be lost
Scenario: Form data is sent as multipart/form-data
Given the architect has uploaded a profile photo
And they have filled all required fields
When they submit the form
Then the request should include the photo as a file upload
And all text fields should be included in the payloadEnfoque sugerido: Usa server actions con useActionState para el backend propio. Maneja state pendiente, errores y mejora progresiva listos para usar. Usa FormData para cargas de archivos.
6. ¿Hay requisitos especiales de UI/UX o estilos?
Decisión: shadcn/ui con Tailwind CSS v4, soporte de modo oscuro y transiciones animadas entre pasos.
Feature: UI/UX Requirements
Scenario: Form renders with shadcn/ui components
Given the architect opens the profile form
Then all inputs should use shadcn/ui styled components
And buttons should follow the design system
And the form should have consistent spacing and typography
Scenario: Dark mode support
Given the system is in dark mode
When the architect opens the profile form
Then all form elements should render with dark theme colors
And contrast ratios should meet WCAG AA standards
Scenario: Step transitions are animated
Given the architect is on step 1
When they click "Next"
Then step 1 should slide out to the left
And step 2 should slide in from the right
And the transition should complete within 300ms
Scenario: Form is visually organized with sections
Given the architect is on step 2 "Experience"
Then the certifications should be grouped in a card
And the bio field should span the full width
And help text should appear below complex fieldsEnfoque sugerido: Usa shadcn/ui con Tailwind como la opción más accesible. shadcn/ui ofrece componentes totalmente personalizables y accesibles sin la sobrecarga de tamaño de bundle de bibliotecas de UI más grandes.
7. ¿Requisitos de accesibilidad y móvil?
Decisión: Cumplimiento completo de WCAG 2.1 AA, navegación por teclado, soporte de lector de pantalla y diseño responsivo.
Feature: Accessibility
Scenario: All fields have accessible labels
Given the architect is on any form step
Then every input should have an associated label element
And every required field should have aria-required="true"
Scenario: Keyboard navigation through form
Given the architect is on step 1
When they press Tab
Then focus should move to the first input field
And they should be able to Tab through all fields in order
And they should be able to submit using Enter
Scenario: Screen reader announces validation errors
Given the architect submits step 1 with empty required fields
Then each error message should have role="alert"
And the screen reader should announce the first error
Scenario: Screen reader announces step changes
Given the architect completes step 1 and moves to step 2
Then the screen reader should announce "Step 2 of 6: Experience"
Scenario: Mobile responsive layout
Given the architect is using a mobile device (viewport 375px)
Then the form should stack fields vertically
And the progress indicator should be compact
And touch targets should be at least 44x44 pixels
And the "Next" and "Back" buttons should be full-widthEnfoque sugerido: Usa HTML semántico, la accesibilidad integrada de react-hook-form y clases responsivas de Tailwind. Una accesibilidad adecuada desde el inicio evita correcciones costosas más adelante y asegura el cumplimiento de WCAG.
8. ¿Debería el formulario soportar cargas de archivos?
Decisión: Sí: foto de perfil (imagen única), diagramas de arquitectura (varias imágenes) y capturas del sitio (varias imágenes).
Feature: File Uploads
Scenario: Architect uploads a profile photo
Given the architect is on step 5 "Uploads"
When they select a JPEG file under 5MB for "Profile Photo"
Then a thumbnail preview should appear
And the file name and size should be displayed
Scenario: Profile photo validates file type
Given the architect is on step 5 "Uploads"
When they select a .exe file for "Profile Photo"
Then they should see "Only JPEG, PNG, and WebP files are accepted"
And the file should not be uploaded
Scenario: Profile photo validates file size
Given the architect is on step 5 "Uploads"
When they select a 15MB image for "Profile Photo"
Then they should see "File must be under 5MB"
Scenario: Architect uploads multiple architecture diagrams
Given the architect is on step 5 "Uploads"
When they select 3 PNG files for "Architecture Diagrams"
Then 3 thumbnail previews should appear
And each should show a remove button
And the upload count should show "3 files selected"
Scenario: Architect removes an uploaded file
Given the architect has uploaded 3 architecture diagrams
When they click the remove button on the second diagram
Then only 2 thumbnails should remain
And the removed file should no longer be in the form data
Scenario: Drag and drop file upload
Given the architect is on step 5 "Uploads"
When they drag a PNG file into the "Architecture Diagrams" drop zone
Then the drop zone should highlight
And when they drop the file a thumbnail preview should appear
Scenario: Maximum file count is enforced
Given the architect has uploaded 10 architecture diagrams
When they try to add another file
Then they should see "Maximum 10 files allowed"
And the file input should be disabledEnfoque sugerido: Usa input type="file" con react-hook-form y manéjalo con FormData para la API. Usa URL.createObjectURL para vistas previas en el cliente. Valida tipo y tamaño en el cliente antes de subir.
9. ¿Prefieres TypeScript o JavaScript? ¿Alguna preferencia de gestión de state?
Decisión: TypeScript con react-hook-form y zod. El state del formulario vive en react-hook-form; no hace falta un gestor de state externo.
Feature: Type Safety and State Management
Scenario: Form schema is defined with zod
Given the developer creates the form schema
Then each step should have its own zod schema
And a combined schema should validate the full profile
And TypeScript types should be inferred from the schema
Scenario: Form state persists across steps
Given the architect fills in step 1 and moves to step 3
When they navigate back to step 1
Then all fields should retain their values
And no external state store should be required
Scenario: Type errors are caught at compile time
Given the developer passes incorrect field types
Then the TypeScript compiler should report an error
And the build should fail before runtimeEnfoque sugerido: TypeScript con react-hook-form y zod es el valor predeterminado muy recomendado. TypeScript detecta errores pronto y zod ofrece validación en runtime que coincide con los tipos en tiempo de compilación.
10. ¿Hay restricciones de stack tecnológico o bibliotecas preferidas?
Decisión: Next.js 15 con App Router, TypeScript, react-hook-form, zod, shadcn/ui y Tailwind CSS v4.
Feature: Tech Stack Integration
Scenario: Form works with App Router server actions
Given the form component is a Client Component
When the architect submits the form
Then data should be processed by a Server Action
And the page should not require a full reload
Scenario: Form works without JavaScript (progressive enhancement)
Given JavaScript is disabled in the browser
When the architect submits the form
Then the form should still submit via native HTML form submission
And server-side validation should catch any errors
Scenario: Form loads performantly
Given the architect navigates to the profile form
Then the initial bundle should not exceed 50KB gzipped for the form
And code splitting should load step components lazily
And the Largest Contentful Paint should be under 2.5 secondsEnfoque sugerido: Usa Next.js 15 con App Router, TypeScript, react-hook-form, zod y shadcn/ui salvo que se indique lo contrario. Este stack moderno ofrece gran rendimiento, beneficios de SEO y una experiencia de desarrollo fluida.
Juntándolo todo: la suite Gherkin completa
Una vez tomadas las 10 decisiones, los archivos feature Gherkin completos se convierten en el contrato entre stakeholders y desarrolladores:
features/
profile-form/
01-purpose.feature # Qué hace el formulario
02-field-types.feature # Tipos de entrada y comportamiento
03-multi-step.feature # Navegación y progreso
04-validation.feature # Todas las reglas de validación
05-submission.feature # Flujo de envío y manejo de errores
06-ui-ux.feature # Estilos e interacciones
07-accessibility.feature # Cumplimiento WCAG
08-file-uploads.feature # Comportamiento de cargas
09-type-safety.feature # Garantías de TypeScript/esquema
10-tech-stack.feature # Rendimiento e integración
Ejecutar Gherkins como pruebas automatizadas
Estos escenarios Gherkin se traducen directamente en pruebas Playwright + Cucumber:
// features/step-definitions/multi-step.steps.ts
import { Given, When, Then } from "@cucumber/cucumber";
import { expect } from "@playwright/test";
Given("el arquitecto está en el paso {int} {string}", async function (step, name) {
await this.page.goto("/profile/create");
for (let i = 1; i < step; i++) {
await fillStepWithValidData(this.page, i);
await this.page.getByRole("button", { name: "Siguiente" }).click();
}
await expect(this.page.getByText(`Paso ${step} de 6`)).toBeVisible();
});
When("hace clic en {string}", async function (buttonText) {
await this.page.getByRole("button", { name: buttonText }).click();
});
Then("el paso {int} {string} debería estar activo", async function (step, name) {
await expect(this.page.getByRole("heading", { name })).toBeVisible();
await expect(this.page.getByText(`Paso ${step} de 6`)).toBeVisible();
});Receta
Tarjeta de referencia rápida — lista para copiar y pegar.
# Template: Gherkin scenario for any form decision
Feature: [Decision Area] -- [Form Name]
Background:
Given the user is logged in
And they navigate to "[form URL]"
Scenario: Happy path -- [what should happen]
Given [precondition]
When [user action]
Then [expected outcome]
Scenario: Validation -- [what should be rejected]
Given [precondition]
When [invalid action]
Then [error message or blocked behavior]
Scenario: Edge case -- [boundary condition]
Given [precondition]
When [edge case action]
Then [expected handling]Cuándo usarlo: Antes de escribir cualquier código de componente de formulario. Recorre la lista de verificación de 10 preguntas con los stakeholders, escribe los escenarios Gherkin, consigue la aprobación y luego implementa.
Errores comunes
-
Escribir Gherkins después del código — anula el propósito. Escríbelos primero para que los stakeholders puedan revisar el comportamiento antes de que empiece la implementación.
-
Demasiado detalle de implementación en los escenarios — Gherkin debe describir qué ocurre, no cómo. Escribe
Then debería ver "El email es obligatorio"y noThen el esquema zod debería devolver un objeto de error con path email. -
Omitir el bloque Background — los pasos Given repetidos inflan cada escenario. Extrae las precondiciones comunes en Background.
-
Un único archivo feature gigante — divídelo por área de decisión (validación, navegación, cargas) para que distintos miembros del equipo puedan ser dueños de distintos archivos.
-
No mapear escenarios a código de prueba — los Gherkins sin automatización se convierten en documentación obsoleta. Usa Playwright + Cucumber o similar para mantenerlos ejecutables.
Alternativas
| Alternativa | Úsala cuando | No la uses cuando |
|---|---|---|
| Solo user stories | Formularios simples con pocos stakeholders | Formularios complejos que necesitan especificaciones de comportamiento precisas |
| Criterios de aceptación en Jira/Linear | El equipo prefiere trackers de issues en lugar de archivos feature | Quieres especificaciones ejecutables |
| Pruebas de interacción en Storybook | La prioridad es la prueba visual | Necesitas especificaciones legibles para stakeholders |
| Pruebas Playwright simples | El equipo de desarrollo escribe pruebas sin revisión de stakeholders | Negocio y desarrollo necesitan un lenguaje compartido |
Relacionado
- Pruebas de formularios -- pruebas unitarias de componentes de formulario con Testing Library
- Configuración de Playwright -- configurar Playwright para pruebas E2E
- Patrones de Playwright -- patrones comunes de pruebas con Playwright
- Sección Formularios y validación -- construir formularios con react-hook-form y zod