O que é Gherkin?
Gherkin é uma linguagem estruturada criada para tornar as histórias de usuário mais fáceis de entender — tanto para pessoas técnicas quanto não técnicas. Ao mesmo tempo, sua sintaxe é suficientemente precisa para descrever exemplos de uso e ilustrar regras de negócio de forma concisa.
Por quê utilizar o Guerkin? é obrigatório?
O uso do Gherkin não é obrigatório para escrever histórias de usuário. No entanto, sua adoção tem se tornado comum no mercado — e com bons motivos. Quando escritas de forma estruturada, as histórias de usuário não apenas facilitam a comunicação entre equipes e stakeholders, mas também podem servir como base para especificações executáveis e testes automatizados.
Gherkin e especificações executáveis (automação)
As histórias de usuário podem ser organizadas em arquivos separados, cada um contendo um conjunto enxuto de cenários. Isso permite que elas sejam mais especializadas e autocontidas. Esses arquivos — chamados de features — são acessíveis pela aplicação e, por conterem informações como entradas e saídas, restrições, exemplos e critérios de aceitação, tornam-se excelentes insumos para o desenvolvimento de testes automatizados.
Palavras-chave do Gherkin
O Gherkin utiliza palavras-chave específicas para estruturar as histórias:
- Funcionalidade
- Contexto
- Cenário
- Esquema do Cenário
- Exemplos
- Dado
- Quando
- Então
- E
- Mas:
- *
Destrinchando cada palavra chave
Funcionalidade
Define o nome da funcionalidade que está sendo descrita. Agrupa um conjunto de cenários relacionados a um mesmo contexto de negócio. Geralmente é acompanhada por uma breve descrição do objetivo da funcionalidade.
Contexto (Background)
Permite definir um conjunto de passos que se repetem em todos os cenários de um arquivo. Serve para evitar duplicação e tornar os cenários mais enxutos e legíveis. Também contribui para a manutenção do código, caso as histórias sejam usadas como base para testes automatizados.
Cenário
Representa um exemplo específico e concreto de como o sistema deve se comportar em determinada situação. Cada cenário descreve um fluxo completo, com entradas, ações e resultados esperados.
Esquema do Cenário
Utilizado quando temos vários cenários semelhantes, onde apenas os dados de entrada e saída variam. Em vez de repetir a estrutura várias vezes, usamos um único molde — o Esquema do Cenário — com diferentes combinações de valores. Isso reduz redundâncias e melhora a legibilidade.
Exemplos
Os exemplos acompanham o Esquema do Cenário, fornecendo os dados que serão inseridos nos passos. Para cada linha de exemplo, o mesmo cenário é executado com diferentes valores, permitindo testes mais amplos e precisos.
Dado / Quando / Então
Essas palavras estruturam os passos do cenário e ajudam a manter a lógica clara. Embora não seja obrigatório usá-las sempre, elas representam três partes fundamentais de qualquer cenário:
- Dado: define o contexto inicial (por exemplo, o estado do sistema ou dados já existentes).
- Quando: descreve a ação que o usuário realiza ou o evento que ocorre.
- Então: apresenta o resultado esperado após a ação.
E / Mas
Servem como conectores adicionais dentro dos cenários, permitindo incluir múltiplos passos ou exceções:
Mas: introduz uma exceção ou variação no fluxo.
E: adiciona uma nova condição ou ação ao passo anterior.
Colinha:
❌Exemplo do que não fazer:
Cenário: validar posso ou não entrar no cinema de acordo com minha idade
Dado que tenho 13 anos
E que quero assistir a um filme cuja faixa mínima é de 14 anos
Mas que posso assistir, se eu estiver acompanhado de um responsável
Quando tento entrar no cinema
Então serei impedido devido à minha idade
Mas caso eu esteja acompanhado de um responsável
Então poderei entrar no cinemaO exemplo acima é ótimo (para não ser seguido). A História não está objetiva, possui alguns passos desnecessários, além de fazer mais de uma validação ao mesmo tempo. Será que não poderíamos quebrar o cenário em mais de um? ou será que não seria melhor utilizar um Esquema do Cenário?
Para entender se faz sentido pensar em um Esquema de Cenário, precisamos nos perguntar: será que esse cenário não deveria ser dividido em dois ou mai scenários? Será que não seria melhor utilizar um Esquema do Cenário com exemplos variados? — na minha opinião, a escolha entre um e outro é pessoal, mas também devemos ter em mente SEMPRE se a forma que estamos apresentando uma história de usuário é clara o suficiente.
Lembre-se que uma das principais vantagens que buscamos ao descrever histórias de usuário é a clareza.
Exemplo do que fazer
Cenário: Menor de idade tenta entrar sozinho em filme com restrição
Dado que tenho 13 anos
E o filme tem classificação mínima de 14 anos
Quando tento entrar no cinema sem um responsável
Então minha entrada deve ser negada
Cenário: Menor de idade tenta entrar acompanhado em filme com restrição
Dado que tenho 13 anos
E o filme tem classificação mínima de 14 anos
E estou acompanhado de um responsável
Quando tento entrar no cinema
Então devo ser autorizado a entrar
Cenário: consegue pensar em um terceiro cenário? deixe nos comentários.Escrevendo “a mesma coisa utilizando Esquema do Cenário:
Esquema do Cenário: Verificar entrada no cinema de acordo com idade e acompanhamento
Dado que tenho <idade> anos
E o filme tem classificação mínima de <classificacao> anos
E estou <acompanhado>
Quando tento entrar no cinema
Então a entrada deve ser <resultado>
Exemplos:
| idade | classificacao | situação | resultado |
| 13 | 14 | sem responsável | negada |
| 13 | 14 | com responsável | autorizada |
| 16 | 14 | sem responsável | autorizada |Você pode aprender mais sobre Histórias de Usuário acessando esta postagem (clique aqui).
Ou ficando por dentro da categoria Histórias de Usuário (clique aqui).
faltou falarmos do “*“… Como o utilizamos?
Nem sempre é fácil escrever cenários usando as palavras-chave tradicionais (Dado, Quando, Então, E, Mas). Em alguns casos, pode ser mais prático — e até mais legível — utilizar o asterisco * como marcador genérico de passos.
Há situações em que cenários mal estruturados ficaram muito mais claros com o uso do *. O importante é lembrar que refletir sobre a estrutura do cenário nunca é perda de tempo, já que nosso objetivo é facilitar a comunicação.
Vamos retomar o exemplo anterior e reescrevê-lo de forma mais clara e objetiva. Desta vez, vamos utilizar o * (asterisco) no lugar das palavras-chave tradicionais como Dado, Quando, Então, E e Mas:
Cenário: validar posso ou não entrar no cinema de acordo com minha idade* tenho 13 anos* a classificação mínima do filme que quero assistir é de 14 anos
* ao tentar entrar no cinema sem um responsável me acompanhando
* minha entrada é negada devido a eu possuir idade abaixo da faixa de indicação
Cenário: Menor de idade tenta entrar acompanhado em filme com restrição
* tenho 13 anos
* a classificação mínima do filme que quero assistir é de 14 anos
* estou acompanhado de um responsável
* ao tentar entrar no cinema
* minha entrada será autorizada
Cenário: consegue pensar em um terceiro cenário? deixe nos comentários.
Embora o conteúdo seja essencialmente o mesmo, o novo formato torna o cenário mais enxuto e direto ao ponto. Optar pelo uso de * pode ajudar na legibilidade e reduzir a complexidade, especialmente quando os prefixos tradicionais não agregam muito valor.
Cuidados ao usar *
Apesar da liberdade que o * proporciona, é importante usá-lo com responsabilidade. A ausência de uma estrutura rígida pode levar à inclusão de passos irrelevantes ou mal formulados.
Mesmo sem os prefixos, a lógica do cenário — contexto → ação → resultado esperado — deve ser preservada.
Compare:
- ✅ “Tenho 13 anos” — passo claro e útil; define uma condição essencial do cenário.
- ❌ “Quero assistir a um filme” — vago; expressa apenas um desejo, sem impacto direto. Estamos buscando escrever de forma mais direta e eficiente.
- ✅ “Quero assistir a um filme cuja classificação mínima é 14 anos” — mais objetivo; acrescenta uma restrição relevante à história.
O uso do * pode ser uma boa alternativa para simplificar a escrita, mas não deve comprometer a clareza, a lógica e o valor informativo do cenário. Manter o foco na comunicação e na utilidade é essencial — com ou sem palavras-chave formais.
E pra finalizar, lembre-se:
O Gherkin é muito mais do que uma simples forma de escrever histórias de usuário — é uma ponte entre pessoas, times e tecnologia. Quando bem utilizado, ele transforma requisitos soltos em cenários claros, colaborativos e até automatizáveis.
Lembre-se: clareza é mais importante do que formalidade. O objetivo final sempre será o mesmo — facilitar a comunicação, alinhar expectativas e garantir que todos estejam na mesma página. Investir tempo na estruturação de boas histórias não é um detalhe: é parte essencial da construção de produtos melhores.