O que é o Gherkin Builder

O Gherkin Builder ajuda a escrever cenários de teste no padrão Gherkin, usado em BDD, sem precisar decorar a sintaxe. ^[1] Você preenche os passos, e o arquivo .feature sai pronto ao lado. É um único arquivo HTML, que funciona no navegador, sem instalação nem conta.

Abrir o Gherkin Builder →

Por que escrever em Gherkin? Porque o mesmo texto serve para quem pede, quem desenvolve e quem testa, e ainda pode virar teste automatizado. Para entender o BDD em si, veja o tutorial de BDD. ^[2]

O app não executa testes: ele produz o arquivo. Para executar, é preciso uma ferramenta como o Cucumber e o código de cada passo.

Como o app trata os seus dados

• Nada sai do seu computador. O arquivo bloqueia conexões de rede.
• O projeto fica no navegador. Ele é guardado automaticamente e reaparece ao reabrir o app. Para ter uma cópia própria, salve em JSON.

Gherkin em cinco minutos

Gherkin usa palavras-chave para dar estrutura a especificações executáveis. ^[3] Cada cenário é um exemplo concreto de uma regra do negócio.

As palavras-chave existem em dezenas de idiomas, e a primeira linha do arquivo, # language: pt, diz qual está em uso. Sem ela, vale o inglês. ^{[3] [5]} O app sempre escreve essa linha.

Seu primeiro arquivo: um cupom de desconto

Em cerca de 10 minutos, você vai especificar um cupom de desconto em uma loja virtual. Se o app abrir com outro projeto, use Arquivo ▾ → Novo projeto.

1. Dê um nome e escreva o primeiro cenário

Só com o teclado:

1. No campo inicial, digite Cupom de desconto e pressione Enter.
2. No título, digite Aplicar cupom válido e pressione Enter.
3. Digite que tenho o cupom "BEMVINDO10" de 10% e pressione Shift+Enter. O passo seguinte já vira a ação.
4. Digite aplico o cupom e pressione Shift+Enter. O passo seguinte já vira o resultado.
5. Digite o total passa a ser R$ 180.

2. Teste vários cupons de uma vez

1. Pressione Ctrl+Enter para criar outro cenário, digite Recusar cupom inválido e pressione Enter.
2. Digite quando aplico o cupom "<cupom>" e pressione Enter. Escrever a palavra no começo troca a palavra-chave, e <cupom> faz a tabela de exemplos aparecer.
3. Digite então vejo a mensagem "<mensagem>" e pressione Enter.
4. Digite o total continua R$ 200.
5. Copie o bloco abaixo, clique na primeira célula de Exemplos e cole. O mesmo funciona com células copiadas de uma planilha.

VENCIDO	Cupom vencido
USADO	Cupom já usado
NAOEXISTE	Cupom não encontrado

3. Peça uma sugestão

1. Clique em Sugerir cenários…, marque Falha em serviço externo e clique em Adicionar selecionados.
2. O primeiro trecho entre colchetes já vem selecionado. Digite o sistema de cupons e pressione Enter: o app vai ao trecho seguinte.
3. Digite aplico o cupom, pressione Enter e digite Tente mais tarde.

4. Complete a funcionalidade

1. Clique no nome da funcionalidade, na lista à esquerda.
2. Em História do usuário (opcional), preencha com cliente da loja, usar um cupom na compra e eu pague menos.
3. Em Contexto comum (opcional), clique em + Dado e digite que tenho R$ 200 em produtos no carrinho. Esse passo agora vale para todos os cenários.
4. Clique no primeiro cenário na lista e, em Tags, digite smoke e pressione Enter.

5. Verifique e leve o arquivo

Abra a aba Verificar. Deve aparecer Nenhum problema encontrado. Volte à aba Gherkin e use Copiar ou Baixar .feature. O resultado é este:

# language: pt
Funcionalidade: Cupom de desconto
  Como cliente da loja
  Eu quero usar um cupom na compra
  Para que eu pague menos

  Contexto:
    Dado que tenho R$ 200 em produtos no carrinho

  @smoke
  Cenário: Aplicar cupom válido
    Dado que tenho o cupom "BEMVINDO10" de 10%
    Quando aplico o cupom
    Então o total passa a ser R$ 180

  Esquema do Cenário: Recusar cupom inválido
    Quando aplico o cupom "<cupom>"
    Então vejo a mensagem "<mensagem>"
    E o total continua R$ 200

    Exemplos:
      | cupom     | mensagem             |
      | VENCIDO   | Cupom vencido        |
      | USADO     | Cupom já usado       |
      | NAOEXISTE | Cupom não encontrado |

  Cenário: Falha em serviço externo
    Dado que o sistema de cupons está fora do ar
    Quando aplico o cupom
    Então vejo a mensagem "Tente mais tarde"
    E meus dados não são perdidos

Conferimos esse arquivo com o parser oficial do Cucumber: ele é aceito e gera 5 execuções, 1 de cada cenário comum e 3 do esquema, todas com o passo do contexto. ^[9]

A interface

O idioma da interface e o do Gherkin são independentes. Dá para usar a tela em português e gerar o arquivo em inglês: as palavras-chave mudam, mas o texto que você escreveu não é traduzido.

Escrever passos rápido

• Enter e Shift+Enter: Enter cria um passo que continua o anterior. Shift+Enter passa para a próxima fase: situação, ação e resultado.
• Digite a palavra: começar o passo com a palavra-chave e um espaço, como quando , troca o tipo do passo.
• Cole uma lista: cada linha vira um passo. Marcadores como - e 1. são removidos, e a palavra-chave no começo da linha é reconhecida.
• Autocompletar: o campo sugere passos já usados no projeto. Reaproveitar a mesma frase evita ter dois textos para a mesma coisa.
• Trechos entre colchetes: ao entrar no passo, o trecho fica selecionado, e Enter vai ao próximo.

Passos vazios não saem no Gherkin, então não é preciso apagá-los antes de copiar. O botão ⋯ de cada passo abre os anexos.

Mesmo teste com vários dados

Se dois cenários só mudam nos valores, una os dois. Escreva <nome> em um passo ou no título: o cenário passa a ser Esquema do Cenário, e a tabela de Exemplos aparece com uma coluna para cada variável. ^[3]

• Colar de uma planilha preenche várias linhas e colunas. Com a tabela cheia, Enter na última linha cria outra.
• Uma célula vazia é válida, como em um teste de senha em branco. O app só aponta erro se a coluna inteira estiver vazia.
• Renomear a variável no passo cria uma coluna nova, e os valores da antiga não passam para ela.

Para escolher os valores, pense em classes de equivalência e em valores limite: um representante de cada grupo de dados que o sistema trata igual, e os valores logo abaixo, nos limites e logo acima deles. ^{[7] [8]}

Tabelas de dados e textos longos

Alguns passos precisam de mais dados do que cabe em uma frase. No botão ⋯ do passo:

Anexar tabela de dados

Para listas de valores no próprio passo, como os itens de um carrinho. Use + Linha e + Coluna.

Anexar texto longo

Para um trecho maior, como o corpo de um e-mail. ^[3]

Tabela de dados pertence a um passo, enquanto a tabela de exemplos repete o cenário inteiro. Os caracteres especiais, como | e \, são tratados pelo app.

História, contexto e tags

História do usuário (opcional)

Quem, o quê e para quê. Entra como descrição da funcionalidade, e dá o porquê dos cenários.

Contexto comum (opcional)

Passos repetidos em todos os cenários. A documentação oficial recomenda mantê-lo curto; acima de 4 linhas, vale reunir os detalhes em passos de nível mais alto. ^[3]

Tags

Digite e pressione Enter, vírgula ou espaço. O app acrescenta o @ e troca espaços por hífen. A busca da lista aceita tags, como @smoke.

Sugerir cenários

Sugerir cenários… traz oito modelos. Eles não leem o seu sistema: são pontos de partida, com trechos entre colchetes para completar.

Os modelos entram no idioma do Gherkin do projeto. Enquanto houver colchetes, a aba Verificar avisa.

Verificar

A aba Verificar revisa o projeto enquanto você escreve, e clicar em um item abre o cenário. Os apontamentos do cenário aberto vêm primeiro.

A verificação olha a forma do texto, não o sentido: uma regra errada, bem escrita, passa sem aviso. As listas de palavras vagas e de detalhes de tela são curtas e servem de lembrete.

Árvore de decisão

A aba Árvore mostra os cenários da funcionalidade como caminhos, da situação ao resultado. Passos com o mesmo texto viram um caminho só, e onde os cenários se separam há um ponto de decisão, marcado com um losango.

• Para ver o que falta: um ramo que só tem o caminho normal, sem nenhum caso de erro, costuma indicar um cenário esquecido.
• Avisos: a aba aponta o mesmo caminho com resultados diferentes (losango preenchido), cenários com os mesmos passos e caminhos sem resultado.
• Ordem: Situação → ação → resultado agrupa por situação inicial, e Ação → situação → resultado agrupa por ação. A segunda ajuda a ver, para uma mesma ação, o que muda conforme a situação.
• Exemplos: Abrir as linhas de exemplos mostra cada linha como um ramo, com os valores no lugar das variáveis.
• Navegar: clicar em um bloco abre o cenário, e o caminho do cenário aberto fica destacado. Ampliar abre a árvore em uma janela grande, e Baixar SVG salva a imagem.

A árvore compara o texto dos passos, sem considerar maiúsculas nem espaços repetidos. Duas frases diferentes para a mesma coisa viram dois caminhos, então ela não julga regras de negócio: reutilize as frases com o autocompletar para que os caminhos se juntem.

O que faz um bom cenário

A documentação do Cucumber recomenda de 3 a 5 passos por exemplo e resultados observáveis. ^[3] E pede que o cenário descreva o quê, não o como: ^[4] o estilo que descreve cliques fica preso à tela atual e dá mais trabalho para manter. Compare:

Uma pergunta ajuda: este texto teria de mudar se a tela mudasse? ^[4] Há casos em que o detalhe é o próprio objeto do teste; aí, mantenha-o.

Copiar, salvar e importar

O projeto no navegador some se você limpar os dados do site. Salve em JSON o que importa.

Prompts de IA

A análise costuma travar antes de escrever o primeiro cenário: as regras estão espalhadas, ninguém pensou nas exceções e os exemplos faltam. Uma IA ajuda a transformar um requisito em perguntas, regras e rascunhos. Ela também erra com segurança: inventa regras de negócio, supõe mensagens e aprova cenários ruins. Trate a saída como rascunho de um colega apressado. Para escrever prompts melhores, veja o tutorial de prompts.

Antes de colar: requisitos podem conter dados de clientes, regras e valores sigilosos. Troque por dados fictícios e siga a política da sua organização para uso de IA. O app não envia nada para a rede, mas o serviço de IA recebe o que você colar nele.

Troque os trechos entre colchetes e cole na ferramenta de IA que você usa. Os prompts seguem a ordem do trabalho, mas cada um funciona sozinho.

1. Entrevistar antes de escrever

Faz a IA descobrir o que falta, em vez de supor. As regras e os exemplos seguem a ideia do Example Mapping, com as dúvidas registradas à parte. ^[6]

Você é um analista de testes experiente em BDD.
Quero especificar este requisito: [descreva em poucas frases].

Antes de propor qualquer cenário, me entreviste:
- Faça uma pergunta por vez e espere minha resposta.
- Cubra: quem usa, o que quer conseguir e por quê; as regras de negócio; o que acontece nos limites; dados inválidos, ausentes ou repetidos; permissões; o que acontece quando um serviço falha; e como saber que deu certo.
- Peça um exemplo concreto, com valores, para cada regra.
- Não invente respostas. Se eu não souber, registre como dúvida.

Ao final, entregue: a história (quem, o que, para quê); as regras, cada uma com seus exemplos; e a lista de dúvidas, com quem pode responder cada uma.

2. Transformar um requisito em regras

Para histórias, atas e documentos. Pede a origem de cada regra, o que facilita conferir, e aponta os casos sem resposta.

A partir do texto abaixo, extraia as regras para escrever cenários de teste.

Texto:
[cole a história, a ata ou o documento]

Entregue:
1. Tabela de regras: regra, o trecho do texto que a sustenta e um exemplo concreto, com entrada e resultado esperado.
2. Termos ambíguos, como "rápido", "válido" ou "quando possível", e o que falta definir em cada um.
3. Casos que o texto não cobre, e regras que se contradizem.
4. Perguntas para esclarecer cada lacuna.

Não preencha lacunas por conta própria. O que não estiver no texto vai para as perguntas. Se um exemplo precisar de um valor que o texto não dá, marque como [a definir].

3. Gerar a funcionalidade em Gherkin

Devolve texto que o app importa. Cole o resultado do prompt 1 ou 2 no fim.

Escreva uma funcionalidade em Gherkin, a partir das informações no fim.

Responda só com o Gherkin, sem comentários e sem cercas de código.

Formato:
- Primeira linha: # language: [pt, en, it ou es].
- Uma única funcionalidade, sem Rule. Use as palavras-chave oficiais do idioma, como no exemplo.
- Dois espaços de recuo por nível.
- Use o esquema com exemplos quando o mesmo teste mudar só nos dados, com <variável> nos passos.
- Passos em comum a todos os cenários vão no contexto, com no máximo 4 linhas.

Regras:
- Um comportamento por cenário, com 3 a 5 passos e uma única ação.
- Descreva o que a pessoa quer fazer, não em qual botão clica nem como a tela funciona.
- O resultado precisa ser observável, com valor ou mensagem concretos. Evite "funciona" ou "corretamente".
- Cubra o caminho normal, os dados inválidos, os limites e as falhas citadas nas informações.
- Não invente regras, valores ou mensagens. Onde faltar um dado, escreva [a definir], e o app vai apontar o trecho para completar.

Exemplo do formato:
# language: pt
@senha
Funcionalidade: Recuperar senha
  Como cliente cadastrado
  Eu quero recuperar minha senha
  Para que eu volte a entrar

  Cenário: Pedir nova senha
    Dado que tenho uma conta ativa
    Quando peço uma nova senha
    Então recebo um e-mail com o link de troca

  Esquema do Cenário: Recusar pedido inválido
    Quando peço uma nova senha para "<email>"
    Então vejo a mensagem "<mensagem>"

    Exemplos:
      | email | mensagem |
      | nao-e-email | E-mail inválido |
      | semconta@exemplo.com | Conta não encontrada |

Informações:
[cole o resultado do prompt 1 ou 2, ou descreva o requisito]

4. Encontrar o que faltou

Procura caminhos não cobertos, usando classes de equivalência e valores limite. ^{[7] [8]}

Analise a cobertura destes cenários e aponte o que falta.

Regras do negócio:
[cole as regras, ou escreva "não tenho as regras à parte"]
Cenários:
[cole o Gherkin]

Faça:
1. Para cada dado de entrada, liste as classes de equivalência: válidos e inválidos.
2. Para cada faixa ou limite, liste os valores logo abaixo, exatamente nos extremos e logo acima.
3. Monte uma tabela: regra ou classe, cenário que cobre e situação (coberto, parcial ou faltando).
4. Liste o que nenhum cenário trata: permissões, repetição, estados intermediários, falha de serviço e concorrência.
5. Sugira só os cenários que faltam, em Gherkin, ordenados pelo risco de não testar, explicando o risco em uma frase.

Não invente regras: se a cobertura depender de uma regra que não foi informada, transforme em pergunta. Marque os valores que você supôs como [a definir].

5. Revisar os cenários

Copie o Gherkin do app e cole. É uma segunda opinião, não uma aprovação.

Revise estes cenários como um analista de testes experiente em BDD.

[cole o Gherkin]

Procure:
- Cenários que testam mais de um comportamento, ou que têm mais de uma ação.
- Resultados que não dá para observar, ou vagos, como "funciona".
- Detalhes de tela ou de implementação nos passos.
- Dado que descreve uma ação, em vez da situação inicial, e dependência entre cenários.
- Contexto longo, ou que não vale para todos os cenários.
- Títulos que não dizem o que muda em relação aos outros.
- Linguagem diferente para a mesma coisa, e termos que o negócio não usaria.
- Exemplos repetidos, ou que não mudam o resultado.

Entregue uma tabela com: cenário, problema, por que importa, sugestão e gravidade (alta, média ou baixa). Não reescreva tudo. Não confirme que está bom só porque não achou problemas, e diga o que não dá para avaliar sem conhecer as regras.

6. Preparar os valores dos exemplos

Devolve os valores prontos para colar na tabela de exemplos.

Prepare valores de teste para este esquema de cenário.

Cenário:
[cole o esquema com as <variáveis>]
Regras e limites:
[descreva o que se sabe sobre cada dado]

Entregue:
1. A tabela de valores como texto, com uma linha por caso e as colunas separadas por tabulação, na mesma ordem das variáveis, sem linha de cabeçalho, pronta para colar em uma planilha ou no app.
2. Depois, uma lista com o motivo de cada linha: a classe ou o limite que ela exercita.

Regras:
- Inclua valores válidos, inválidos, vazios, nos limites e com caracteres especiais, quando fizer sentido.
- Cada linha precisa testar algo que as outras não testam.
- Não use dados reais de pessoas: invente nomes, documentos e e-mails com domínio de exemplo.
- Se o resultado esperado não puder ser deduzido das regras, escreva [a definir] na célula.

7. Reescrever cenários presos à tela

Passa do estilo que descreve cliques para o que descreve o comportamento. ^[4]

Reescreva estes cenários no estilo declarativo, descrevendo o comportamento em vez dos cliques.

[cole o Gherkin]

Regras:
- Mantenha o idioma e as palavras-chave.
- Troque "clico", "digito" e nomes de campos ou botões pelo que a pessoa quer conseguir.
- Mantenha os valores que importam para a regra, e remova os que não mudam o resultado.
- Não mude o comportamento testado. Se um detalhe de tela for o próprio objeto do teste, mantenha e explique por quê.
- Pergunte a si mesmo: este texto teria de mudar se a tela mudasse?

Entregue o Gherkin reescrito e, depois, uma lista do que saiu de cada cenário, para eu conferir que nada importante se perdeu.

8. Preparar a conversa com a equipe

Transforma as dúvidas em uma pauta curta para negócio, desenvolvimento e teste.

Prepare a conversa da equipe sobre estes cenários.

Cenários:
[cole o Gherkin]
Dúvidas que já tenho:
[liste, ou escreva "nenhuma"]

Entregue, em até uma página:
1. Em duas frases, o que está sendo especificado.
2. As regras assumidas nos cenários e que ninguém confirmou.
3. Até 5 perguntas para o negócio, 5 para o desenvolvimento e 5 para o teste, em ordem de risco.
4. Os cenários que eu mostraria primeiro, e por quê.
5. O que deixar fora deste ciclo, e o risco de deixar.

Use só o que está nos cenários e nas dúvidas. Não afirme como o sistema funciona: apresente como pergunta.

Como levar a resposta da IA para o app

1. Copie o Gherkin da resposta, sem as cercas ```.
2. No app, use Arquivo ▾ → Colar Gherkin…, cole e clique em Importar. Ele entra como uma nova funcionalidade.
3. Abra a aba Verificar e confira cada item.

Se o projeto já tiver outra funcionalidade, as palavras-chave seguem o Idioma do Gherkin do projeto, e o texto dos passos não é traduzido. Os valores do prompt 6 vêm separados por tabulação: clique na primeira célula de Exemplos e cole.

Atalhos de teclado

Erros comuns e limitações

Erros de escrita

• Testar duas coisas no mesmo cenário. Se há duas ações, são dois cenários.
• Resultado que não dá para conferir. "Funciona" não diz o que olhar. Escreva o valor ou a mensagem.
• Só o caminho feliz. Use Sugerir cenários… para lembrar dos outros.
• Cenário que depende de outro. Cada um precisa fazer sentido sozinho.

Limitações

• O app não executa testes nem testa o sistema: ele só produz o arquivo.
• Importação: Rule vira cenário comum, vários blocos de exemplos são unidos, e comentários, tags e nomes de exemplos se perdem. O app avisa quando isso acontece.
• Idiomas: só português, inglês, italiano e espanhol.
• Navegadores: o app foi testado no Chromium. Outros navegadores e celulares reais não foram testados.

Revisão rápida

Tente responder antes de abrir cada pergunta.

Referências

1. Giovani Perotto Mesquita, “Gherkin Builder”, aplicativo em um único arquivo HTML, giovanipm.github.io/gherkin-builder.html.
2. Giovani Perotto Mesquita, “BDD”, tutorial deste site, giovanipm.github.io/BDD.html.
3. Cucumber, “Reference” (Gherkin), documentação, acesso em 01/11/2026, cucumber.io/docs/gherkin/reference.
4. Cucumber, “Writing better Gherkin”, documentação, acesso em 01/11/2026, cucumber.io/docs/bdd/better-gherkin.
5. Cucumber, “Localisation”, documentação, acesso em 01/11/2026, cucumber.io/docs/gherkin/languages.
6. Cucumber, “Example Mapping”, documentação, acesso em 01/11/2026, cucumber.io/docs/bdd/example-mapping.
7. Wikipedia (em inglês), “Boundary-value analysis”, acesso em 01/11/2026, en.wikipedia.org/wiki/Boundary-value_analysis.
8. Wikipedia (em inglês), “Equivalence partitioning”, acesso em 01/11/2026, en.wikipedia.org/wiki/Equivalence_partitioning.
9. Cucumber, @cucumber/gherkin 42.0.1, o parser oficial, usado para validar os arquivos deste tutorial, github.com/cucumber/gherkin.

What Gherkin Builder is

Gherkin Builder helps you write test scenarios in Gherkin, the format used in BDD, without memorizing the syntax. ^[1] You fill in the steps, and the .feature file comes out ready alongside. It is a single HTML file that works in the browser, with no installation or account.

Open Gherkin Builder →

Why write in Gherkin? Because the same text works for those who ask, those who build and those who test, and it can also become an automated test. To learn about BDD itself, see the BDD tutorial. ^[2]

The app does not run tests: it produces the file. To run them you need a tool such as Cucumber and the code behind each step.

How the app handles your data

• Nothing leaves your computer. The file blocks network connections.
• The project stays in the browser. It is stored automatically and comes back when you reopen the app. To keep your own copy, save it as JSON.

Gherkin in five minutes

Gherkin uses keywords to give structure to executable specifications. ^[3] Each scenario is a concrete example of a business rule.

The keywords exist in dozens of languages, and the first line of the file, # language: en, says which one is in use. Without it, English applies. ^{[3] [5]} The app always writes that line.

Your first file: a discount coupon

In about 10 minutes, you will specify a discount coupon in an online store. If the app opens with another project, use File ▾ → New project.

1. Name it and write the first scenario

Using only the keyboard:

1. In the start field, type Discount coupon and press Enter.
2. In the title, type Apply a valid coupon and press Enter.
3. Type I have the coupon "WELCOME10" for 10% and press Shift+Enter. The next step is already the action.
4. Type I apply the coupon and press Shift+Enter. The next step is already the result.
5. Type the total becomes $180.

2. Test several coupons at once

1. Press Ctrl+Enter to add another scenario, type Refuse an invalid coupon and press Enter.
2. Type when I apply the coupon "<coupon>" and press Enter. Writing the word at the start changes the keyword, and <coupon> makes the examples table appear.
3. Type then I see the message "<message>" and press Enter.
4. Type the total stays $200.
5. Copy the block below, click the first cell of Examples and paste. The same works with cells copied from a spreadsheet.

EXPIRED	Coupon expired
USED	Coupon already used
NOPE	Coupon not found

3. Ask for a suggestion

1. Click Suggest scenarios…, tick External service failure and click Add selected.
2. The first part in brackets is already selected. Type the coupon system and press Enter: the app goes to the next part.
3. Type apply the coupon, press Enter and type Try again later.

4. Complete the feature

1. Click the feature name in the list on the left.
2. Under User story (optional), fill in store customer, to use a coupon on my purchase and I pay less.
3. Under Common background (optional), click + Given and type I have $200 of products in the cart. This step now applies to all scenarios.
4. Click the first scenario in the list and, under Tags, type smoke and press Enter.

5. Check it and take the file

Open the Check tab. It should say No problems found. Go back to the Gherkin tab and use Copy or Download .feature. The result is this:

# language: en
Feature: Discount coupon
  As a store customer
  I want to use a coupon on my purchase
  So that I pay less

  Background:
    Given I have $200 of products in the cart

  @smoke
  Scenario: Apply a valid coupon
    Given I have the coupon "WELCOME10" for 10%
    When I apply the coupon
    Then the total becomes $180

  Scenario Outline: Refuse an invalid coupon
    When I apply the coupon "<coupon>"
    Then I see the message "<message>"
    And the total stays $200

    Examples:
      | coupon  | message             |
      | EXPIRED | Coupon expired      |
      | USED    | Coupon already used |
      | NOPE    | Coupon not found    |

  Scenario: External service failure
    Given the coupon system is down
    When I apply the coupon
    Then I see the message "Try again later"
    And my data is not lost

We checked this file with the official Cucumber parser: it is accepted and produces 5 runs, 1 for each plain scenario and 3 for the outline, all with the background step. ^[9]

The interface

The interface language and the Gherkin language are independent. You can use the screen in Portuguese and generate the file in English: the keywords change, but the text you wrote is not translated.

Writing steps quickly

• Enter and Shift+Enter: Enter adds a step that continues the previous one. Shift+Enter moves to the next phase: situation, action and result.
• Type the word: starting the step with the keyword and a space, such as when , changes the type of step.
• Paste a list: each line becomes a step. Markers such as - and 1. are removed, and a keyword at the start of the line is recognized.
• Autocomplete: the field suggests steps already used in the project. Reusing the same sentence avoids having two wordings for the same thing.
• Parts in brackets: on entering the step the part is selected, and Enter goes to the next one.

Empty steps do not go into the Gherkin, so there is no need to delete them before copying. The ⋯ button on each step opens the attachments.

Same test with several data sets

If two scenarios differ only in their values, merge them. Write <name> in a step or in the title: the scenario becomes a Scenario Outline, and the Examples table appears with one column for each variable. ^[3]

• Pasting from a spreadsheet fills several rows and columns. With the table full, Enter on the last row adds another.
• An empty cell is valid, as in a blank password test. The app reports an error only if the whole column is empty.
• Renaming the variable in the step creates a new column, and the values of the old one do not carry over.

To choose the values, think of equivalence classes and boundary values: one representative of each group of data the system treats alike, and the values just below, at and just above the limits. ^{[7] [8]}

Data tables and long text

Some steps need more data than fits in a sentence. Under the step's ⋯ button:

Attach data table

For lists of values in the step itself, such as the items in a cart. Use + Row and + Column.

Attach long text

For a longer passage, such as the body of an email. ^[3]

A data table belongs to one step, while the examples table repeats the whole scenario. Special characters such as | and \ are handled by the app.

Story, background and tags

User story (optional)

Who, what and why. It goes in as the feature description, and gives the reason for the scenarios.

Common background (optional)

Steps repeated in all scenarios. The official documentation recommends keeping it short; above 4 lines, consider moving the details into higher-level steps. ^[3]

Tags

Type and press Enter, comma or space. The app adds the @ and replaces spaces with hyphens. The list search accepts tags, such as @smoke.

Suggest scenarios

Suggest scenarios… brings eight templates. They do not read your system: they are starting points, with parts in brackets to complete.

The templates come in the project's Gherkin language. While there are brackets, the Check tab warns you.

Check

The Check tab reviews the project as you write, and clicking an item opens the scenario. The findings for the open scenario come first.

The check looks at the form of the text, not its meaning: a wrong rule, well written, passes with no warning. The lists of vague words and screen details are short and serve as reminders.

Decision tree

The Tree tab shows the feature's scenarios as paths, from situation to result. Steps with the same text share one path, and where scenarios part ways there is a decision point, marked with a diamond.

• To see what is missing: a branch with only the normal path, and no error case, often points to a forgotten scenario.
• Warnings: the tab points out the same path with different results (filled diamond), scenarios with the same steps and paths with no result.
• Order: Situation → action → result groups by starting situation, and Action → situation → result groups by action. The second helps you see, for one action, what changes with the situation.
• Examples: Open the examples rows shows each row as a branch, with the values in place of the variables.
• Navigating: clicking a block opens the scenario, and the open scenario's path is highlighted. Enlarge opens the tree in a large window, and Download SVG saves the image.

The tree compares the text of the steps, ignoring case and repeated spaces. Two different sentences for the same thing become two paths, so it does not judge business rules: reuse sentences with autocomplete so the paths join.

What makes a good scenario

The Cucumber documentation recommends 3 to 5 steps per example and observable results. ^[3] It also asks scenarios to describe what, not how: ^[4] the style that describes clicks stays tied to the current screen and takes more work to maintain. Compare:

One question helps: would this wording need to change if the screen changed? ^[4] In some cases the detail is the very object of the test; then, keep it.

Copying, saving and importing

The project in the browser disappears if you clear the site's data. Save what matters as JSON.

AI prompts

Analysis usually stalls before the first scenario is written: the rules are scattered, nobody thought about the exceptions and examples are missing. An AI helps turn a requirement into questions, rules and drafts. It also makes confident mistakes: it invents business rules, assumes messages and approves poor scenarios. Treat its output as a draft from a colleague in a hurry. To write better prompts, see the prompt tutorial.

Before pasting: requirements may contain customer data and confidential rules and figures. Replace them with made-up data and follow your organization's AI policy. The app sends nothing over the network, but the AI service receives whatever you paste into it.

Replace the parts in brackets and paste into the AI tool you use. The prompts follow the order of the work, but each one works on its own.

1. Interview before writing

Makes the AI find out what is missing instead of assuming. The rules and examples follow the idea of Example Mapping, with questions recorded separately. ^[6]

You are a test analyst experienced in BDD.
I want to specify this requirement: [describe in a few sentences].

Before proposing any scenario, interview me:
- Ask one question at a time and wait for my answer.
- Cover: who uses it, what they want to achieve and why; the business rules; what happens at the limits; invalid, missing or repeated data; permissions; what happens when a service fails; and how to know it worked.
- Ask for a concrete example, with values, for each rule.
- Do not invent answers. If I do not know, record it as a question.

At the end, deliver: the story (who, what, why); the rules, each with its examples; and the list of questions, with who can answer each one.

2. Turn a requirement into rules

For stories, minutes and documents. It asks for the source of each rule, which makes checking easier, and points out cases with no answer.

From the text below, extract the rules for writing test scenarios.

Text:
[paste the story, minutes or document]

Deliver:
1. A table of rules: rule, the passage of the text that supports it and a concrete example, with input and expected result.
2. Ambiguous terms, such as "fast", "valid" or "when possible", and what is still undefined in each.
3. Cases the text does not cover, and rules that contradict each other.
4. Questions to clarify each gap.

Do not fill gaps on your own. Whatever is not in the text goes to the questions. If an example needs a value the text does not give, mark it as [to be defined].

3. Generate the feature in Gherkin

Returns text the app imports. Paste the result of prompt 1 or 2 at the end.

Write a feature in Gherkin, from the information at the end.

Answer with the Gherkin only, no comments and no code fences.

Format:
- First line: # language: [pt, en, it or es].
- A single feature, with no Rule. Use the official keywords of the language, as in the example.
- Two spaces of indentation per level.
- Use the outline with examples when the same test changes only in its data, with <variable> in the steps.
- Steps common to all scenarios go in the background, with at most 4 lines.

Rules:
- One behavior per scenario, with 3 to 5 steps and a single action.
- Describe what the person wants to do, not which button they click or how the screen works.
- The result must be observable, with a concrete value or message. Avoid "works" or "correctly".
- Cover the normal path, invalid data, limits and the failures mentioned in the information.
- Do not invent rules, values or messages. Where data is missing, write [to be defined], and the app will point out the part to complete.

Format example:
# language: en
@password
Feature: Recover password
  As a registered customer
  I want to recover my password
  So that I can sign in again

  Scenario: Request a new password
    Given I have an active account
    When I request a new password
    Then I receive an email with the reset link

  Scenario Outline: Refuse an invalid request
    When I request a new password for "<email>"
    Then I see the message "<message>"

    Examples:
      | email | message |
      | not-an-email | Invalid email |
      | noaccount@example.com | Account not found |

Information:
[paste the result of prompt 1 or 2, or describe the requirement]

4. Find what is missing

Looks for uncovered paths, using equivalence classes and boundary values. ^{[7] [8]}

Analyze the coverage of these scenarios and point out what is missing.

Business rules:
[paste the rules, or write "I do not have the rules separately"]
Scenarios:
[paste the Gherkin]

Do this:
1. For each input, list the equivalence classes: valid and invalid.
2. For each range or limit, list the values just below, exactly at the ends and just above.
3. Build a table: rule or class, scenario covering it and status (covered, partial or missing).
4. List what no scenario handles: permissions, repetition, intermediate states, service failure and concurrency.
5. Suggest only the missing scenarios, in Gherkin, ordered by the risk of not testing, explaining the risk in one sentence.

Do not invent rules: if coverage depends on a rule that was not given, turn it into a question. Mark values you assumed as [to be defined].

5. Review the scenarios

Copy the Gherkin from the app and paste it. It is a second opinion, not an approval.

Review these scenarios as a test analyst experienced in BDD.

[paste the Gherkin]

Look for:
- Scenarios testing more than one behavior, or with more than one action.
- Results that cannot be observed, or vague ones such as "works".
- Screen or implementation details in the steps.
- A Given describing an action instead of the starting situation, and dependence between scenarios.
- A long background, or one that does not apply to all scenarios.
- Titles that do not say what differs from the others.
- Different wording for the same thing, and terms the business would not use.
- Repeated examples, or examples that do not change the result.

Deliver a table with: scenario, problem, why it matters, suggestion and severity (high, medium or low). Do not rewrite everything. Do not confirm it is good just because you found no problems, and say what cannot be assessed without knowing the rules.

6. Prepare the example values

Returns the values ready to paste into the examples table.

Prepare test values for this scenario outline.

Scenario:
[paste the outline with the <variables>]
Rules and limits:
[describe what is known about each piece of data]

Deliver:
1. The table of values as text, with one line per case and columns separated by tabs, in the same order as the variables, with no header line, ready to paste into a spreadsheet or the app.
2. Then, a list with the reason for each line: the class or limit it exercises.

Rules:
- Include valid, invalid, empty, boundary and special-character values, where it makes sense.
- Each line must test something the others do not.
- Do not use real people's data: invent names, documents and emails with an example domain.
- If the expected result cannot be deduced from the rules, write [to be defined] in the cell.

7. Rewrite scenarios tied to the screen

Moves from the style that describes clicks to the one that describes behavior. ^[4]

Rewrite these scenarios in the declarative style, describing the behavior instead of the clicks.

[paste the Gherkin]

Rules:
- Keep the language and the keywords.
- Replace "click", "type" and names of fields or buttons with what the person wants to achieve.
- Keep the values that matter to the rule, and remove those that do not change the result.
- Do not change the behavior being tested. If a screen detail is the very object of the test, keep it and explain why.
- Ask yourself: would this wording need to change if the screen changed?

Deliver the rewritten Gherkin and then a list of what left each scenario, so I can check nothing important was lost.

8. Prepare the team conversation

Turns the questions into a short agenda for business, development and testing.

Prepare the team conversation about these scenarios.

Scenarios:
[paste the Gherkin]
Questions I already have:
[list them, or write "none"]

Deliver, in up to one page:
1. In two sentences, what is being specified.
2. The rules assumed in the scenarios that nobody has confirmed.
3. Up to 5 questions for the business, 5 for development and 5 for testing, in order of risk.
4. The scenarios I would show first, and why.
5. What to leave out of this cycle, and the risk of doing so.

Use only what is in the scenarios and questions. Do not state how the system works: present it as a question.

How to take the AI's answer to the app

1. Copy the Gherkin from the answer, without the ``` fences.
2. In the app, use File ▾ → Paste Gherkin…, paste and click Import. It comes in as a new feature.
3. Open the Check tab and review each item.

If the project already has another feature, the keywords follow the project's Gherkin language, and the step text is not translated. The values from prompt 6 come separated by tabs: click the first cell of Examples and paste.

Keyboard shortcuts

Common mistakes and limitations

Writing mistakes

• Testing two things in one scenario. If there are two actions, there are two scenarios.
• A result you cannot check. "It works" does not say what to look at. Write the value or the message.
• Only the happy path. Use Suggest scenarios… to remember the others.
• A scenario depending on another. Each one must make sense on its own.

Limitations

• The app does not run tests or test the system: it only produces the file.
• Import: Rule becomes a plain scenario, several example blocks are merged, and comments, tags and example names are lost. The app warns you when this happens.
• Languages: only Portuguese, English, Italian and Spanish.
• Browsers: the app was tested in Chromium. Other browsers and real phones were not tested.

Quick review

Try to answer before opening each question.

References

1. Giovani Perotto Mesquita, “Gherkin Builder”, single-file HTML app, giovanipm.github.io/gherkin-builder.html.
2. Giovani Perotto Mesquita, “BDD”, tutorial on this site, giovanipm.github.io/BDD.html.
3. Cucumber, “Reference” (Gherkin), documentation, accessed 1 November 2026, cucumber.io/docs/gherkin/reference.
4. Cucumber, “Writing better Gherkin”, documentation, accessed 1 November 2026, cucumber.io/docs/bdd/better-gherkin.
5. Cucumber, “Localisation”, documentation, accessed 1 November 2026, cucumber.io/docs/gherkin/languages.
6. Cucumber, “Example Mapping”, documentation, accessed 1 November 2026, cucumber.io/docs/bdd/example-mapping.
7. Wikipedia, “Boundary-value analysis”, accessed 1 November 2026, en.wikipedia.org/wiki/Boundary-value_analysis.
8. Wikipedia, “Equivalence partitioning”, accessed 1 November 2026, en.wikipedia.org/wiki/Equivalence_partitioning.
9. Cucumber, @cucumber/gherkin 42.0.1, the official parser, used to validate the files in this tutorial, github.com/cucumber/gherkin.

Che cos'è Gherkin Builder

Gherkin Builder aiuta a scrivere scenari di test in Gherkin, il formato usato nel BDD, senza dover memorizzare la sintassi. ^[1] Compili i passi, e il file .feature esce pronto accanto. È un unico file HTML che funziona nel browser, senza installazione né account.

Apri Gherkin Builder →

Perché scrivere in Gherkin? Perché lo stesso testo serve a chi chiede, a chi sviluppa e a chi testa, e può anche diventare un test automatico. Per capire il BDD, vedi il tutorial di BDD. ^[2]

L'app non esegue i test: produce il file. Per eseguirli servono uno strumento come Cucumber e il codice di ogni passo.

Come l'app tratta i tuoi dati

• Nulla esce dal tuo computer. Il file blocca le connessioni di rete.
• Il progetto resta nel browser. Viene salvato automaticamente e riappare quando riapri l'app. Per averne una copia tua, salvalo in JSON.

Gherkin in cinque minuti

Gherkin usa parole chiave per dare struttura a specifiche eseguibili. ^[3] Ogni scenario è un esempio concreto di una regola di business.

Le parole chiave esistono in decine di lingue, e la prima riga del file, # language: it, indica quale è in uso. Senza di essa, vale l'inglese. ^{[3] [5]} L'app scrive sempre questa riga.

Il tuo primo file: un buono sconto

In circa 10 minuti, specificherai un buono sconto in un negozio online. Se l'app si apre con un altro progetto, usa File ▾ → Nuovo progetto.

1. Dai un nome e scrivi il primo scenario

Solo con la tastiera:

1. Nel campo iniziale, digita Buono sconto e premi Invio.
2. Nel titolo, digita Applicare un buono valido e premi Invio.
3. Digita che ho il buono "BENVENUTO10" del 10% e premi Maiusc+Invio. Il passo seguente è già l'azione.
4. Digita applico il buono e premi Maiusc+Invio. Il passo seguente è già il risultato.
5. Digita il totale diventa 180 €.

2. Prova più buoni insieme

1. Premi Ctrl+Invio per creare un altro scenario, digita Rifiutare un buono non valido e premi Invio.
2. Digita quando applico il buono "<buono>" e premi Invio. Scrivere la parola all'inizio cambia la parola chiave, e <buono> fa apparire la tabella degli esempi.
3. Digita allora vedo il messaggio "<messaggio>" e premi Invio.
4. Digita il totale resta 200 €.
5. Copia il blocco qui sotto, fai clic sulla prima cella di Esempi e incolla. Lo stesso vale per celle copiate da un foglio di calcolo.

SCADUTO	Buono scaduto
USATO	Buono già usato
NONESISTE	Buono non trovato

3. Chiedi un suggerimento

1. Fai clic su Suggerisci scenari…, seleziona Guasto di un servizio esterno e fai clic su Aggiungi selezionati.
2. La prima parte tra parentesi quadre è già selezionata. Digita il sistema dei buoni e premi Invio: l'app va alla parte seguente.
3. Digita applico il buono, premi Invio e digita Riprova più tardi.

4. Completa la funzionalità

1. Fai clic sul nome della funzionalità, nell'elenco a sinistra.
2. In Storia utente (facoltativa), compila con cliente del negozio, usare un buono per l'acquisto e io paghi meno.
3. In Contesto comune (facoltativo), fai clic su + Dato e digita che ho 200 € di prodotti nel carrello. Questo passo ora vale per tutti gli scenari.
4. Fai clic sul primo scenario nell'elenco e, in Tag, digita smoke e premi Invio.

5. Verifica e porta via il file

Apri la scheda Verifica. Deve apparire Nessun problema trovato. Torna alla scheda Gherkin e usa Copia o Scarica .feature. Il risultato è questo:

# language: it
Funzionalità: Buono sconto
  Come cliente del negozio
  Voglio usare un buono per l'acquisto
  Affinché io paghi meno

  Contesto:
    Dato che ho 200 € di prodotti nel carrello

  @smoke
  Scenario: Applicare un buono valido
    Dato che ho il buono "BENVENUTO10" del 10%
    Quando applico il buono
    Allora il totale diventa 180 €

  Schema dello scenario: Rifiutare un buono non valido
    Quando applico il buono "<buono>"
    Allora vedo il messaggio "<messaggio>"
    E il totale resta 200 €

    Esempi:
      | buono     | messaggio         |
      | SCADUTO   | Buono scaduto     |
      | USATO     | Buono già usato   |
      | NONESISTE | Buono non trovato |

  Scenario: Guasto di un servizio esterno
    Dato che il sistema dei buoni non è disponibile
    Quando applico il buono
    Allora vedo il messaggio "Riprova più tardi"
    E i miei dati non vanno persi

Abbiamo controllato questo file con il parser ufficiale di Cucumber: viene accettato e produce 5 esecuzioni, 1 per ogni scenario normale e 3 per lo schema, tutte con il passo del contesto. ^[9]

L'interfaccia

La lingua dell'interfaccia e quella del Gherkin sono indipendenti. Puoi usare la schermata in portoghese e generare il file in inglese: le parole chiave cambiano, ma il testo che hai scritto non viene tradotto.

Scrivere i passi rapidamente

• Invio e Maiusc+Invio: Invio crea un passo che continua il precedente. Maiusc+Invio passa alla fase seguente: situazione, azione e risultato.
• Digita la parola: iniziare il passo con la parola chiave e uno spazio, come quando , cambia il tipo di passo.
• Incolla un elenco: ogni riga diventa un passo. I marcatori come - e 1. vengono rimossi, e la parola chiave a inizio riga viene riconosciuta.
• Completamento: il campo suggerisce i passi già usati nel progetto. Riusare la stessa frase evita due testi per la stessa cosa.
• Parti tra parentesi quadre: entrando nel passo la parte è selezionata, e Invio va alla successiva.

I passi vuoti non escono nel Gherkin, quindi non serve cancellarli prima di copiare. Il pulsante ⋯ di ogni passo apre gli allegati.

Stesso test con più dati

Se due scenari cambiano solo nei valori, uniscili. Scrivi <nome> in un passo o nel titolo: lo scenario diventa uno Schema dello scenario, e la tabella di Esempi appare con una colonna per ogni variabile. ^[3]

• Incollare da un foglio di calcolo riempie più righe e colonne. A tabella piena, Invio sull'ultima riga ne crea un'altra.
• Una cella vuota è valida, come in un test di password vuota. L'app segnala errore solo se tutta la colonna è vuota.
• Rinominare la variabile nel passo crea una nuova colonna, e i valori della vecchia non passano alla nuova.

Per scegliere i valori, pensa alle classi di equivalenza e ai valori limite: un rappresentante di ogni gruppo di dati che il sistema tratta allo stesso modo, e i valori appena sotto, ai limiti e appena sopra. ^{[7] [8]}

Tabelle di dati e testi lunghi

Alcuni passi richiedono più dati di quanti ne stiano in una frase. Nel pulsante ⋯ del passo:

Allega tabella di dati

Per elenchi di valori nel passo stesso, come gli articoli di un carrello. Usa + Riga e + Colonna.

Allega testo lungo

Per un brano più lungo, come il corpo di un'e-mail. ^[3]

La tabella di dati appartiene a un passo, mentre la tabella degli esempi ripete l'intero scenario. I caratteri speciali, come | e \, sono gestiti dall'app.

Storia, contesto e tag

Storia utente (facoltativa)

Chi, cosa e perché. Entra come descrizione della funzionalità, e dà il motivo degli scenari.

Contesto comune (facoltativo)

Passi ripetuti in tutti gli scenari. La documentazione ufficiale raccomanda di tenerlo breve; oltre 4 righe, conviene spostare i dettagli in passi di livello più alto. ^[3]

Tag

Digita e premi Invio, virgola o spazio. L'app aggiunge la @ e sostituisce gli spazi con trattini. La ricerca dell'elenco accetta i tag, come @smoke.

Suggerire scenari

Suggerisci scenari… offre otto modelli. Non leggono il tuo sistema: sono punti di partenza, con parti tra parentesi quadre da completare.

I modelli entrano nella lingua del Gherkin del progetto. Finché ci sono parentesi quadre, la scheda Verifica avvisa.

Verifica

La scheda Verifica controlla il progetto mentre scrivi, e fare clic su una voce apre lo scenario. Le segnalazioni dello scenario aperto vengono per prime.

La verifica guarda la forma del testo, non il senso: una regola sbagliata, ben scritta, passa senza avvisi. Gli elenchi di parole vaghe e di dettagli di schermata sono brevi e servono da promemoria.

Albero di decisione

La scheda Albero mostra gli scenari della funzionalità come percorsi, dalla situazione al risultato. I passi con lo stesso testo condividono un percorso, e dove gli scenari si separano c'è un punto di decisione, segnato con un rombo.

• Per vedere cosa manca: un ramo con il solo percorso normale, senza alcun caso di errore, spesso indica uno scenario dimenticato.
• Avvisi: la scheda segnala lo stesso percorso con risultati diversi (rombo pieno), scenari con gli stessi passi e percorsi senza risultato.
• Ordine: Situazione → azione → risultato raggruppa per situazione iniziale, e Azione → situazione → risultato raggruppa per azione. Il secondo aiuta a vedere, per una stessa azione, cosa cambia con la situazione.
• Esempi: Apri le righe di esempi mostra ogni riga come un ramo, con i valori al posto delle variabili.
• Navigare: fare clic su un blocco apre lo scenario, e il percorso dello scenario aperto resta evidenziato. Ingrandisci apre l'albero in una finestra grande, e Scarica SVG salva l'immagine.

L'albero confronta il testo dei passi, ignorando maiuscole e spazi ripetuti. Due frasi diverse per la stessa cosa diventano due percorsi, quindi non giudica le regole di business: riusa le frasi con il completamento perché i percorsi si uniscano.

Cosa rende buono uno scenario

La documentazione di Cucumber raccomanda da 3 a 5 passi per esempio e risultati osservabili. ^[3] Chiede inoltre che lo scenario descriva il cosa, non il come: ^[4] lo stile che descrive i clic resta legato alla schermata attuale e richiede più lavoro di manutenzione. Confronta:

Una domanda aiuta: questo testo dovrebbe cambiare se cambiasse la schermata? ^[4] In alcuni casi il dettaglio è l'oggetto stesso del test; allora, mantienilo.

Copiare, salvare e importare

Il progetto nel browser sparisce se cancelli i dati del sito. Salva in JSON ciò che conta.

Prompt di IA

L'analisi di solito si blocca prima di scrivere il primo scenario: le regole sono sparse, nessuno ha pensato alle eccezioni e mancano gli esempi. Un'IA aiuta a trasformare un requisito in domande, regole e bozze. Sbaglia anche con sicurezza: inventa regole di business, suppone messaggi e approva scenari scadenti. Tratta il risultato come la bozza di un collega di fretta. Per scrivere prompt migliori, vedi il tutorial sui prompt.

Prima di incollare: i requisiti possono contenere dati di clienti e regole e valori riservati. Sostituiscili con dati fittizi e segui la politica della tua organizzazione sull'uso dell'IA. L'app non invia nulla in rete, ma il servizio di IA riceve ciò che vi incolli.

Sostituisci le parti tra parentesi quadre e incolla nello strumento di IA che usi. I prompt seguono l'ordine del lavoro, ma ognuno funziona da solo.

1. Intervistare prima di scrivere

Fa scoprire all'IA ciò che manca, invece di supporlo. Regole ed esempi seguono l'idea dell'Example Mapping, con i dubbi registrati a parte. ^[6]

Sei un analista di test esperto di BDD.
Voglio specificare questo requisito: [descrivilo in poche frasi].

Prima di proporre qualsiasi scenario, intervistami:
- Fai una domanda alla volta e aspetta la mia risposta.
- Copri: chi lo usa, cosa vuole ottenere e perché; le regole di business; cosa succede ai limiti; dati non validi, assenti o ripetuti; autorizzazioni; cosa succede se un servizio si guasta; e come capire che ha funzionato.
- Chiedi un esempio concreto, con valori, per ogni regola.
- Non inventare risposte. Se non lo so, registralo come dubbio.

Alla fine, consegna: la storia (chi, cosa, perché); le regole, ciascuna con i suoi esempi; e l'elenco dei dubbi, con chi può rispondere a ciascuno.

2. Trasformare un requisito in regole

Per storie, verbali e documenti. Chiede l'origine di ogni regola, il che facilita il controllo, e segnala i casi senza risposta.

Dal testo qui sotto, estrai le regole per scrivere scenari di test.

Testo:
[incolla la storia, il verbale o il documento]

Consegna:
1. Tabella delle regole: regola, il brano che la sostiene e un esempio concreto, con ingresso e risultato atteso.
2. Termini ambigui, come "veloce", "valido" o "quando possibile", e cosa resta da definire in ciascuno.
3. Casi che il testo non copre, e regole che si contraddicono.
4. Domande per chiarire ogni lacuna.

Non colmare le lacune da solo. Ciò che non è nel testo va nelle domande. Se un esempio richiede un valore che il testo non dà, segnalo come [da definire].

3. Generare la funzionalità in Gherkin

Restituisce testo che l'app importa. Incolla alla fine il risultato del prompt 1 o 2.

Scrivi una funzionalità in Gherkin, dalle informazioni alla fine.

Rispondi solo con il Gherkin, senza commenti e senza delimitatori di codice.

Formato:
- Prima riga: # language: [pt, en, it o es].
- Una sola funzionalità, senza Rule. Usa le parole chiave ufficiali della lingua, come nell'esempio.
- Due spazi di rientro per livello.
- Usa lo schema con esempi quando lo stesso test cambia solo nei dati, con <variabile> nei passi.
- I passi comuni a tutti gli scenari vanno nel contesto, con al massimo 4 righe.

Regole:
- Un comportamento per scenario, con da 3 a 5 passi e una sola azione.
- Descrivi ciò che la persona vuole fare, non quale pulsante clicca né come funziona la schermata.
- Il risultato deve essere osservabile, con un valore o un messaggio concreti. Evita "funziona" o "correttamente".
- Copri il percorso normale, i dati non validi, i limiti e i guasti citati nelle informazioni.
- Non inventare regole, valori o messaggi. Dove manca un dato, scrivi [da definire], e l'app indicherà la parte da completare.

Esempio del formato:
# language: it
@password
Funzionalità: Recuperare la password
  Come cliente registrato
  Voglio recuperare la password
  Affinché io possa accedere di nuovo

  Scenario: Chiedere una nuova password
    Dato che ho un account attivo
    Quando chiedo una nuova password
    Allora ricevo un'e-mail con il link di modifica

  Schema dello scenario: Rifiutare una richiesta non valida
    Quando chiedo una nuova password per "<email>"
    Allora vedo il messaggio "<messaggio>"

    Esempi:
      | email | messaggio |
      | non-e-email | E-mail non valida |
      | senzaaccount@esempio.com | Account non trovato |

Informazioni:
[incolla il risultato del prompt 1 o 2, o descrivi il requisito]

4. Trovare ciò che manca

Cerca percorsi non coperti, usando classi di equivalenza e valori limite. ^{[7] [8]}

Analizza la copertura di questi scenari e indica cosa manca.

Regole di business:
[incolla le regole, o scrivi "non ho le regole a parte"]
Scenari:
[incolla il Gherkin]

Fai questo:
1. Per ogni dato in ingresso, elenca le classi di equivalenza: valide e non valide.
2. Per ogni intervallo o limite, elenca i valori appena sotto, esattamente agli estremi e appena sopra.
3. Costruisci una tabella: regola o classe, scenario che la copre e stato (coperto, parziale o mancante).
4. Elenca ciò che nessuno scenario tratta: autorizzazioni, ripetizione, stati intermedi, guasto di servizio e concorrenza.
5. Suggerisci solo gli scenari mancanti, in Gherkin, ordinati per rischio di non testarli, spiegando il rischio in una frase.

Non inventare regole: se la copertura dipende da una regola non indicata, trasformala in domanda. Segna i valori che hai supposto come [da definire].

5. Rivedere gli scenari

Copia il Gherkin dall'app e incollalo. È un secondo parere, non un'approvazione.

Rivedi questi scenari come un analista di test esperto di BDD.

[incolla il Gherkin]

Cerca:
- Scenari che testano più di un comportamento, o con più di un'azione.
- Risultati non osservabili, o vaghi, come "funziona".
- Dettagli di schermata o di implementazione nei passi.
- Un Dato che descrive un'azione invece della situazione iniziale, e dipendenza tra scenari.
- Contesto lungo, o che non vale per tutti gli scenari.
- Titoli che non dicono cosa cambia rispetto agli altri.
- Linguaggio diverso per la stessa cosa, e termini che il business non userebbe.
- Esempi ripetuti, o che non cambiano il risultato.

Consegna una tabella con: scenario, problema, perché conta, suggerimento e gravità (alta, media o bassa). Non riscrivere tutto. Non confermare che va bene solo perché non hai trovato problemi, e di' cosa non si può valutare senza conoscere le regole.

6. Preparare i valori degli esempi

Restituisce i valori pronti da incollare nella tabella degli esempi.

Prepara i valori di test per questo schema di scenario.

Scenario:
[incolla lo schema con le <variabili>]
Regole e limiti:
[descrivi ciò che si sa di ogni dato]

Consegna:
1. La tabella dei valori come testo, con una riga per caso e colonne separate da tabulazioni, nello stesso ordine delle variabili, senza riga di intestazione, pronta da incollare in un foglio di calcolo o nell'app.
2. Poi, un elenco con il motivo di ogni riga: la classe o il limite che prova.

Regole:
- Includi valori validi, non validi, vuoti, ai limiti e con caratteri speciali, quando ha senso.
- Ogni riga deve provare qualcosa che le altre non provano.
- Non usare dati reali di persone: inventa nomi, documenti ed e-mail con dominio di esempio.
- Se il risultato atteso non si può dedurre dalle regole, scrivi [da definire] nella cella.

7. Riscrivere scenari legati alla schermata

Passa dallo stile che descrive i clic a quello che descrive il comportamento. ^[4]

Riscrivi questi scenari nello stile dichiarativo, descrivendo il comportamento invece dei clic.

[incolla il Gherkin]

Regole:
- Mantieni la lingua e le parole chiave.
- Sostituisci "clicco", "digito" e i nomi di campi o pulsanti con ciò che la persona vuole ottenere.
- Mantieni i valori che contano per la regola, e togli quelli che non cambiano il risultato.
- Non cambiare il comportamento testato. Se un dettaglio di schermata è l'oggetto stesso del test, mantienilo e spiega perché.
- Chiediti: questo testo dovrebbe cambiare se cambiasse la schermata?

Consegna il Gherkin riscritto e, poi, un elenco di ciò che è uscito da ogni scenario, così controllo che non si sia perso nulla di importante.

8. Preparare la conversazione con il team

Trasforma i dubbi in un breve ordine del giorno per business, sviluppo e test.

Prepara la conversazione del team su questi scenari.

Scenari:
[incolla il Gherkin]
Dubbi che ho già:
[elencali, o scrivi "nessuno"]

Consegna, in massimo una pagina:
1. In due frasi, cosa si sta specificando.
2. Le regole presupposte negli scenari e che nessuno ha confermato.
3. Fino a 5 domande per il business, 5 per lo sviluppo e 5 per il test, in ordine di rischio.
4. Gli scenari che mostrerei per primi, e perché.
5. Cosa lasciare fuori da questo ciclo, e il rischio di farlo.

Usa solo ciò che è negli scenari e nei dubbi. Non affermare come funziona il sistema: presentalo come domanda.

Come portare la risposta dell'IA nell'app

1. Copia il Gherkin dalla risposta, senza i delimitatori ```.
2. Nell'app, usa File ▾ → Incolla Gherkin…, incolla e fai clic su Importa. Entra come nuova funzionalità.
3. Apri la scheda Verifica e controlla ogni voce.

Se il progetto ha già un'altra funzionalità, le parole chiave seguono la Lingua del Gherkin del progetto, e il testo dei passi non viene tradotto. I valori del prompt 6 sono separati da tabulazioni: fai clic sulla prima cella di Esempi e incolla.

Scorciatoie da tastiera

Errori comuni e limiti

Errori di scrittura

• Provare due cose nello stesso scenario. Se ci sono due azioni, sono due scenari.
• Risultato non verificabile. "Funziona" non dice cosa guardare. Scrivi il valore o il messaggio.
• Solo il percorso ideale. Usa Suggerisci scenari… per ricordare gli altri.
• Scenario che dipende da un altro. Ognuno deve avere senso da solo.

Limiti

• L'app non esegue i test né prova il sistema: produce solo il file.
• Importazione: Rule diventa uno scenario normale, più blocchi di esempi vengono uniti, e commenti, tag e nomi degli esempi vanno persi. L'app avvisa quando succede.
• Lingue: solo portoghese, inglese, italiano e spagnolo.
• Browser: l'app è stata provata in Chromium. Altri browser e telefoni reali non sono stati provati.

Ripasso rapido

Prova a rispondere prima di aprire ogni domanda.

Riferimenti

1. Giovani Perotto Mesquita, “Gherkin Builder”, app in un unico file HTML, giovanipm.github.io/gherkin-builder.html.
2. Giovani Perotto Mesquita, “BDD”, tutorial di questo sito, giovanipm.github.io/BDD.html.
3. Cucumber, “Reference” (Gherkin), documentazione, consultato il 01/11/2026, cucumber.io/docs/gherkin/reference.
4. Cucumber, “Writing better Gherkin”, documentazione, consultato il 01/11/2026, cucumber.io/docs/bdd/better-gherkin.
5. Cucumber, “Localisation”, documentazione, consultato il 01/11/2026, cucumber.io/docs/gherkin/languages.
6. Cucumber, “Example Mapping”, documentazione, consultato il 01/11/2026, cucumber.io/docs/bdd/example-mapping.
7. Wikipedia (in inglese), “Boundary-value analysis”, consultato il 01/11/2026, en.wikipedia.org/wiki/Boundary-value_analysis.
8. Wikipedia (in inglese), “Equivalence partitioning”, consultato il 01/11/2026, en.wikipedia.org/wiki/Equivalence_partitioning.
9. Cucumber, @cucumber/gherkin 42.0.1, il parser ufficiale, usato per convalidare i file di questo tutorial, github.com/cucumber/gherkin.

Qué es Gherkin Builder

Gherkin Builder ayuda a escribir escenarios de prueba en Gherkin, el formato usado en BDD, sin tener que memorizar la sintaxis. ^[1] Rellenas los pasos, y el archivo .feature sale listo al lado. Es un único archivo HTML que funciona en el navegador, sin instalación ni cuenta.

Abrir Gherkin Builder →

¿Por qué escribir en Gherkin? Porque el mismo texto sirve a quien pide, a quien desarrolla y a quien prueba, y además puede convertirse en una prueba automatizada. Para entender el BDD, mira el tutorial de BDD. ^[2]

La aplicación no ejecuta pruebas: produce el archivo. Para ejecutarlas hacen falta una herramienta como Cucumber y el código de cada paso.

Cómo trata la aplicación tus datos

• Nada sale de tu ordenador. El archivo bloquea las conexiones de red.
• El proyecto se queda en el navegador. Se guarda automáticamente y reaparece al reabrir la aplicación. Para tener una copia propia, guárdalo en JSON.

Gherkin en cinco minutos

Gherkin usa palabras clave para dar estructura a especificaciones ejecutables. ^[3] Cada escenario es un ejemplo concreto de una regla de negocio.

Las palabras clave existen en decenas de idiomas, y la primera línea del archivo, # language: es, indica cuál está en uso. Sin ella, vale el inglés. ^{[3] [5]} La aplicación siempre escribe esa línea.

Tu primer archivo: un cupón de descuento

En unos 10 minutos, especificarás un cupón de descuento en una tienda en línea. Si la aplicación abre con otro proyecto, usa Archivo ▾ → Nuevo proyecto.

1. Pon un nombre y escribe el primer escenario

Solo con el teclado:

1. En el campo inicial, escribe Cupón de descuento y pulsa Enter.
2. En el título, escribe Aplicar un cupón válido y pulsa Enter.
3. Escribe que tengo el cupón "BIENVENIDO10" del 10% y pulsa Mayús+Enter. El paso siguiente ya es la acción.
4. Escribe aplico el cupón y pulsa Mayús+Enter. El paso siguiente ya es el resultado.
5. Escribe el total pasa a ser 180 €.

2. Prueba varios cupones a la vez

1. Pulsa Ctrl+Enter para crear otro escenario, escribe Rechazar un cupón no válido y pulsa Enter.
2. Escribe cuando aplico el cupón "<cupon>" y pulsa Enter. Escribir la palabra al principio cambia la palabra clave, y <cupon> hace aparecer la tabla de ejemplos.
3. Escribe entonces veo el mensaje "<mensaje>" y pulsa Enter.
4. Escribe el total sigue en 200 €.
5. Copia el bloque de abajo, haz clic en la primera celda de Ejemplos y pega. Lo mismo funciona con celdas copiadas de una hoja de cálculo.

CADUCADO	Cupón caducado
USADO	Cupón ya usado
NOEXISTE	Cupón no encontrado

3. Pide una sugerencia

1. Haz clic en Sugerir escenarios…, marca Fallo de un servicio externo y haz clic en Añadir seleccionados.
2. La primera parte entre corchetes ya viene seleccionada. Escribe el sistema de cupones y pulsa Enter: la aplicación va a la parte siguiente.
3. Escribe aplico el cupón, pulsa Enter y escribe Inténtalo más tarde.

4. Completa la funcionalidad

1. Haz clic en el nombre de la funcionalidad, en la lista de la izquierda.
2. En Historia de usuario (opcional), rellena con cliente de la tienda, usar un cupón en mi compra y pague menos.
3. En Antecedentes comunes (opcional), haz clic en + Dado y escribe que tengo 200 € en productos en el carrito. Este paso ahora vale para todos los escenarios.
4. Haz clic en el primer escenario de la lista y, en Tags, escribe smoke y pulsa Enter.

5. Verifica y llévate el archivo

Abre la pestaña Verificar. Debe aparecer No se encontraron problemas. Vuelve a la pestaña Gherkin y usa Copiar o Descargar .feature. El resultado es este:

# language: es
Característica: Cupón de descuento
  Como cliente de la tienda
  Quiero usar un cupón en mi compra
  Para pague menos

  Antecedentes:
    Dado que tengo 200 € en productos en el carrito

  @smoke
  Escenario: Aplicar un cupón válido
    Dado que tengo el cupón "BIENVENIDO10" del 10%
    Cuando aplico el cupón
    Entonces el total pasa a ser 180 €

  Esquema del escenario: Rechazar un cupón no válido
    Cuando aplico el cupón "<cupon>"
    Entonces veo el mensaje "<mensaje>"
    Y el total sigue en 200 €

    Ejemplos:
      | cupon    | mensaje             |
      | CADUCADO | Cupón caducado      |
      | USADO    | Cupón ya usado      |
      | NOEXISTE | Cupón no encontrado |

  Escenario: Fallo de un servicio externo
    Dado que el sistema de cupones está caído
    Cuando aplico el cupón
    Entonces veo el mensaje "Inténtalo más tarde"
    Y mis datos no se pierden

Comprobamos este archivo con el parser oficial de Cucumber: se acepta y genera 5 ejecuciones, 1 de cada escenario común y 3 del esquema, todas con el paso de los antecedentes. ^[9]

La interfaz

El idioma de la interfaz y el del Gherkin son independientes. Puedes usar la pantalla en portugués y generar el archivo en inglés: las palabras clave cambian, pero el texto que escribiste no se traduce.

Escribir pasos rápido

• Enter y Mayús+Enter: Enter crea un paso que continúa el anterior. Mayús+Enter pasa a la siguiente fase: situación, acción y resultado.
• Escribe la palabra: empezar el paso con la palabra clave y un espacio, como cuando , cambia el tipo de paso.
• Pega una lista: cada línea se convierte en un paso. Los marcadores como - y 1. se quitan, y la palabra clave al principio de la línea se reconoce.
• Autocompletar: el campo sugiere pasos ya usados en el proyecto. Reutilizar la misma frase evita dos textos para lo mismo.
• Partes entre corchetes: al entrar en el paso la parte queda seleccionada, y Enter va a la siguiente.

Los pasos vacíos no salen en el Gherkin, así que no hace falta borrarlos antes de copiar. El botón ⋯ de cada paso abre los adjuntos.

La misma prueba con varios datos

Si dos escenarios solo cambian en los valores, únelos. Escribe <nombre> en un paso o en el título: el escenario pasa a ser un Esquema del escenario, y la tabla de Ejemplos aparece con una columna para cada variable. ^[3]

• Pegar desde una hoja de cálculo rellena varias filas y columnas. Con la tabla llena, Enter en la última fila crea otra.
• Una celda vacía es válida, como en una prueba de contraseña en blanco. La aplicación solo señala error si toda la columna está vacía.
• Renombrar la variable en el paso crea una columna nueva, y los valores de la antigua no pasan a ella.

Para elegir los valores, piensa en clases de equivalencia y en valores límite: un representante de cada grupo de datos que el sistema trata igual, y los valores justo debajo, en los límites y justo encima. ^{[7] [8]}

Tablas de datos y textos largos

Algunos pasos necesitan más datos de los que caben en una frase. En el botón ⋯ del paso:

Adjuntar tabla de datos

Para listas de valores en el propio paso, como los artículos de un carrito. Usa + Fila y + Columna.

Adjuntar texto largo

Para un pasaje mayor, como el cuerpo de un correo. ^[3]

La tabla de datos pertenece a un paso, mientras que la tabla de ejemplos repite el escenario entero. Los caracteres especiales, como | y \, los trata la aplicación.

Historia, antecedentes y tags

Historia de usuario (opcional)

Quién, qué y para qué. Entra como descripción de la funcionalidad, y da el porqué de los escenarios.

Antecedentes comunes (opcional)

Pasos repetidos en todos los escenarios. La documentación oficial recomienda mantenerlos cortos; por encima de 4 líneas, conviene reunir los detalles en pasos de nivel más alto. ^[3]

Tags

Escribe y pulsa Enter, coma o espacio. La aplicación añade la @ y cambia los espacios por guiones. La búsqueda de la lista acepta tags, como @smoke.

Sugerir escenarios

Sugerir escenarios… trae ocho modelos. No leen tu sistema: son puntos de partida, con partes entre corchetes por completar.

Los modelos entran en el idioma del Gherkin del proyecto. Mientras haya corchetes, la pestaña Verificar avisa.

Verificar

La pestaña Verificar revisa el proyecto mientras escribes, y hacer clic en un elemento abre el escenario. Los avisos del escenario abierto van primero.

La verificación mira la forma del texto, no el sentido: una regla equivocada, bien escrita, pasa sin aviso. Las listas de palabras vagas y de detalles de pantalla son cortas y sirven de recordatorio.

Árbol de decisión

La pestaña Árbol muestra los escenarios de la funcionalidad como caminos, de la situación al resultado. Los pasos con el mismo texto comparten un camino, y donde los escenarios se separan hay un punto de decisión, marcado con un rombo.

• Para ver qué falta: una rama que solo tiene el camino normal, sin ningún caso de error, suele indicar un escenario olvidado.
• Avisos: la pestaña señala el mismo camino con resultados distintos (rombo relleno), escenarios con los mismos pasos y caminos sin resultado.
• Orden: Situación → acción → resultado agrupa por situación inicial, y Acción → situación → resultado agrupa por acción. La segunda ayuda a ver, para una misma acción, qué cambia según la situación.
• Ejemplos: Abrir las filas de ejemplos muestra cada fila como una rama, con los valores en lugar de las variables.
• Navegar: hacer clic en un bloque abre el escenario, y el camino del escenario abierto queda destacado. Ampliar abre el árbol en una ventana grande, y Descargar SVG guarda la imagen.

El árbol compara el texto de los pasos, sin tener en cuenta mayúsculas ni espacios repetidos. Dos frases distintas para lo mismo son dos caminos, así que no juzga reglas de negocio: reutiliza las frases con el autocompletado para que los caminos se unan.

Qué hace bueno a un escenario

La documentación de Cucumber recomienda de 3 a 5 pasos por ejemplo y resultados observables. ^[3] También pide que el escenario describa el qué, no el cómo: ^[4] el estilo que describe clics queda atado a la pantalla actual y da más trabajo de mantenimiento. Compara:

Una pregunta ayuda: ¿este texto tendría que cambiar si cambiara la pantalla? ^[4] En algunos casos el detalle es el objeto mismo de la prueba; entonces, mantenlo.

Copiar, guardar e importar

El proyecto en el navegador desaparece si borras los datos del sitio. Guarda en JSON lo que importa.

Prompts de IA

El análisis suele atascarse antes de escribir el primer escenario: las reglas están dispersas, nadie pensó en las excepciones y faltan ejemplos. Una IA ayuda a convertir un requisito en preguntas, reglas y borradores. También se equivoca con seguridad: inventa reglas de negocio, supone mensajes y aprueba escenarios malos. Trata el resultado como el borrador de un colega con prisa. Para escribir mejores prompts, mira el tutorial de prompts.

Antes de pegar: los requisitos pueden contener datos de clientes y reglas y valores confidenciales. Cámbialos por datos ficticios y sigue la política de tu organización sobre el uso de IA. La aplicación no envía nada a la red, pero el servicio de IA recibe lo que pegues en él.

Cambia las partes entre corchetes y pega en la herramienta de IA que uses. Los prompts siguen el orden del trabajo, pero cada uno funciona por sí solo.

1. Entrevistar antes de escribir

Hace que la IA descubra lo que falta, en vez de suponerlo. Las reglas y los ejemplos siguen la idea del Example Mapping, con las dudas registradas aparte. ^[6]

Eres un analista de pruebas con experiencia en BDD.
Quiero especificar este requisito: [descríbelo en pocas frases].

Antes de proponer ningún escenario, entrevístame:
- Haz una pregunta cada vez y espera mi respuesta.
- Cubre: quién lo usa, qué quiere conseguir y por qué; las reglas de negocio; qué ocurre en los límites; datos no válidos, ausentes o repetidos; permisos; qué ocurre si falla un servicio; y cómo saber que funcionó.
- Pide un ejemplo concreto, con valores, para cada regla.
- No inventes respuestas. Si no lo sé, regístralo como duda.

Al final, entrega: la historia (quién, qué, para qué); las reglas, cada una con sus ejemplos; y la lista de dudas, con quién puede responder cada una.

2. Convertir un requisito en reglas

Para historias, actas y documentos. Pide el origen de cada regla, lo que facilita comprobarla, y señala los casos sin respuesta.

A partir del texto siguiente, extrae las reglas para escribir escenarios de prueba.

Texto:
[pega la historia, el acta o el documento]

Entrega:
1. Tabla de reglas: regla, el pasaje que la sustenta y un ejemplo concreto, con entrada y resultado esperado.
2. Términos ambiguos, como "rápido", "válido" o "cuando sea posible", y lo que falta definir en cada uno.
3. Casos que el texto no cubre, y reglas que se contradicen.
4. Preguntas para aclarar cada laguna.

No rellenes lagunas por tu cuenta. Lo que no esté en el texto va a las preguntas. Si un ejemplo necesita un valor que el texto no da, márcalo como [por definir].

3. Generar la funcionalidad en Gherkin

Devuelve texto que la aplicación importa. Pega al final el resultado del prompt 1 o 2.

Escribe una funcionalidad en Gherkin, a partir de la información del final.

Responde solo con el Gherkin, sin comentarios y sin marcas de código.

Formato:
- Primera línea: # language: [pt, en, it o es].
- Una sola funcionalidad, sin Rule. Usa las palabras clave oficiales del idioma, como en el ejemplo.
- Dos espacios de sangría por nivel.
- Usa el esquema con ejemplos cuando la misma prueba cambie solo en los datos, con <variable> en los pasos.
- Los pasos comunes a todos los escenarios van en los antecedentes, con un máximo de 4 líneas.

Reglas:
- Un comportamiento por escenario, con 3 a 5 pasos y una sola acción.
- Describe lo que la persona quiere hacer, no en qué botón hace clic ni cómo funciona la pantalla.
- El resultado debe ser observable, con un valor o mensaje concretos. Evita "funciona" o "correctamente".
- Cubre el camino normal, los datos no válidos, los límites y los fallos citados en la información.
- No inventes reglas, valores ni mensajes. Donde falte un dato, escribe [por definir], y la aplicación señalará la parte por completar.

Ejemplo del formato:
# language: es
@clave
Característica: Recuperar la contraseña
  Como cliente registrado
  Quiero recuperar mi contraseña
  Para volver a entrar

  Escenario: Pedir una contraseña nueva
    Dado que tengo una cuenta activa
    Cuando pido una contraseña nueva
    Entonces recibo un correo con el enlace de cambio

  Esquema del escenario: Rechazar una petición no válida
    Cuando pido una contraseña nueva para "<correo>"
    Entonces veo el mensaje "<mensaje>"

    Ejemplos:
      | correo | mensaje |
      | no-es-correo | Correo no válido |
      | sincuenta@ejemplo.com | Cuenta no encontrada |

Información:
[pega el resultado del prompt 1 o 2, o describe el requisito]

4. Encontrar lo que falta

Busca caminos sin cubrir, usando clases de equivalencia y valores límite. ^{[7] [8]}

Analiza la cobertura de estos escenarios y señala lo que falta.

Reglas de negocio:
[pega las reglas, o escribe "no tengo las reglas aparte"]
Escenarios:
[pega el Gherkin]

Haz esto:
1. Para cada dato de entrada, lista las clases de equivalencia: válidas y no válidas.
2. Para cada rango o límite, lista los valores justo debajo, exactamente en los extremos y justo encima.
3. Monta una tabla: regla o clase, escenario que la cubre y estado (cubierto, parcial o faltante).
4. Lista lo que ningún escenario trata: permisos, repetición, estados intermedios, fallo de servicio y concurrencia.
5. Sugiere solo los escenarios que faltan, en Gherkin, ordenados por el riesgo de no probarlos, explicando el riesgo en una frase.

No inventes reglas: si la cobertura depende de una regla no indicada, conviértela en pregunta. Marca los valores que supusiste como [por definir].

5. Revisar los escenarios

Copia el Gherkin de la aplicación y pégalo. Es una segunda opinión, no una aprobación.

Revisa estos escenarios como un analista de pruebas con experiencia en BDD.

[pega el Gherkin]

Busca:
- Escenarios que prueban más de un comportamiento, o con más de una acción.
- Resultados que no se pueden observar, o vagos, como "funciona".
- Detalles de pantalla o de implementación en los pasos.
- Un Dado que describe una acción en vez de la situación inicial, y dependencia entre escenarios.
- Antecedentes largos, o que no valen para todos los escenarios.
- Títulos que no dicen qué cambia respecto a los demás.
- Lenguaje distinto para lo mismo, y términos que el negocio no usaría.
- Ejemplos repetidos, o que no cambian el resultado.

Entrega una tabla con: escenario, problema, por qué importa, sugerencia y gravedad (alta, media o baja). No lo reescribas todo. No confirmes que está bien solo porque no hallaste problemas, y di qué no se puede evaluar sin conocer las reglas.

6. Preparar los valores de los ejemplos

Devuelve los valores listos para pegar en la tabla de ejemplos.

Prepara valores de prueba para este esquema de escenario.

Escenario:
[pega el esquema con las <variables>]
Reglas y límites:
[describe lo que se sabe de cada dato]

Entrega:
1. La tabla de valores como texto, con una línea por caso y las columnas separadas por tabulaciones, en el mismo orden de las variables, sin línea de cabecera, lista para pegar en una hoja de cálculo o en la aplicación.
2. Después, una lista con el motivo de cada línea: la clase o el límite que prueba.

Reglas:
- Incluye valores válidos, no válidos, vacíos, en los límites y con caracteres especiales, cuando tenga sentido.
- Cada línea debe probar algo que las demás no prueban.
- No uses datos reales de personas: inventa nombres, documentos y correos con dominio de ejemplo.
- Si el resultado esperado no se puede deducir de las reglas, escribe [por definir] en la celda.

7. Reescribir escenarios atados a la pantalla

Pasa del estilo que describe clics al que describe el comportamiento. ^[4]

Reescribe estos escenarios en estilo declarativo, describiendo el comportamiento en vez de los clics.

[pega el Gherkin]

Reglas:
- Mantén el idioma y las palabras clave.
- Cambia "hago clic", "escribo" y los nombres de campos o botones por lo que la persona quiere conseguir.
- Mantén los valores que importan para la regla, y quita los que no cambian el resultado.
- No cambies el comportamiento probado. Si un detalle de pantalla es el objeto mismo de la prueba, mantenlo y explica por qué.
- Pregúntate: ¿este texto tendría que cambiar si cambiara la pantalla?

Entrega el Gherkin reescrito y, después, una lista de lo que salió de cada escenario, para que compruebe que no se perdió nada importante.

8. Preparar la conversación con el equipo

Convierte las dudas en un orden del día corto para negocio, desarrollo y pruebas.

Prepara la conversación del equipo sobre estos escenarios.

Escenarios:
[pega el Gherkin]
Dudas que ya tengo:
[lístalas, o escribe "ninguna"]

Entrega, en hasta una página:
1. En dos frases, qué se está especificando.
2. Las reglas asumidas en los escenarios que nadie ha confirmado.
3. Hasta 5 preguntas para el negocio, 5 para desarrollo y 5 para pruebas, por orden de riesgo.
4. Los escenarios que mostraría primero, y por qué.
5. Qué dejar fuera de este ciclo, y el riesgo de hacerlo.

Usa solo lo que está en los escenarios y las dudas. No afirmes cómo funciona el sistema: preséntalo como pregunta.

Cómo llevar la respuesta de la IA a la aplicación

1. Copia el Gherkin de la respuesta, sin las marcas ```.
2. En la aplicación, usa Archivo ▾ → Pegar Gherkin…, pega y haz clic en Importar. Entra como una nueva funcionalidad.
3. Abre la pestaña Verificar y revisa cada elemento.

Si el proyecto ya tiene otra funcionalidad, las palabras clave siguen el Idioma del Gherkin del proyecto, y el texto de los pasos no se traduce. Los valores del prompt 6 vienen separados por tabulaciones: haz clic en la primera celda de Ejemplos y pega.

Atajos de teclado

Errores comunes y limitaciones

Errores de escritura

• Probar dos cosas en el mismo escenario. Si hay dos acciones, son dos escenarios.
• Resultado que no se puede comprobar. "Funciona" no dice qué mirar. Escribe el valor o el mensaje.
• Solo el camino feliz. Usa Sugerir escenarios… para recordar los demás.
• Escenario que depende de otro. Cada uno debe tener sentido por sí solo.

Limitaciones

• La aplicación no ejecuta pruebas ni prueba el sistema: solo produce el archivo.
• Importación: Rule pasa a ser un escenario común, varios bloques de ejemplos se unen, y los comentarios, tags y nombres de ejemplos se pierden. La aplicación avisa cuando ocurre.
• Idiomas: solo portugués, inglés, italiano y español.
• Navegadores: la aplicación se probó en Chromium. Otros navegadores y móviles reales no se probaron.

Repaso rápido

Intenta responder antes de abrir cada pregunta.

Referencias

1. Giovani Perotto Mesquita, “Gherkin Builder”, aplicación en un único archivo HTML, giovanipm.github.io/gherkin-builder.html.
2. Giovani Perotto Mesquita, “BDD”, tutorial de este sitio, giovanipm.github.io/BDD.html.
3. Cucumber, “Reference” (Gherkin), documentación, consultado el 01/11/2026, cucumber.io/docs/gherkin/reference.
4. Cucumber, “Writing better Gherkin”, documentación, consultado el 01/11/2026, cucumber.io/docs/bdd/better-gherkin.
5. Cucumber, “Localisation”, documentación, consultado el 01/11/2026, cucumber.io/docs/gherkin/languages.
6. Cucumber, “Example Mapping”, documentación, consultado el 01/11/2026, cucumber.io/docs/bdd/example-mapping.
7. Wikipedia (en inglés), “Boundary-value analysis”, consultado el 01/11/2026, en.wikipedia.org/wiki/Boundary-value_analysis.
8. Wikipedia (en inglés), “Equivalence partitioning”, consultado el 01/11/2026, en.wikipedia.org/wiki/Equivalence_partitioning.
9. Cucumber, @cucumber/gherkin 42.0.1, el parser oficial, usado para validar los archivos de este tutorial, github.com/cucumber/gherkin.