Este artigo foi publicado originalmente em: https://www.concrete.com.br/2019/03/25/code-review-dos-meus-cenarios/

***

Escrever cenários de teste sem um processo de revisão sempre me deixava em dúvida sobre a clareza do que estava transmitindo e até mesmo sobre qual seria a melhor estratégia de teste a ser implementada.

Sem dúvidas, minha principal preocupação era se meus cenários estavam legíveis, e depois que passei a trabalhar com outro QA pude notar que até mesmo alguns cenários que eu acreditava que tinham boa legibilidade poderiam ser melhorados.

A partir daí passei a trabalhar com a revisão de outros papéis, como o P.O, designer ou UX, e isso contribuiu ainda mais para tornar meus cenários mais claros, cumprindo o objetivo do BDD.

Depois de conhecer as boas práticas de escrita com o BDD, comecei a me preocupar mais ainda com a clareza dos cenários.

Apesar disso, às vezes escorregava em algo e outro QA me alertava, falando: “Olha, tal ‘dado’ pode ser um contexto”. Ou, em testes para mobile: “Este cenário pode ser instrumentado”.

Uma coisa bacana que fizemos foi entrar em um consenso sobre como seria a estrutura dos nossos cenários.

Apesar de ter variáveis que são boas práticas e outras que vão muito de gosto (ou de um jeito mais caprichoso de escrever), entrar nesse “acordo” foi bom porque evitou uma salada mista.

Com ele, fica mais fácil de os outros papéis (dev, designer, PO) entenderem os cenários, porque mantemos um padrão.

Com base nessa experiência, seguem algumas informações que podemos considerar para entrar em um consenso sobre a escrita dos cenários.

Exemplo do que levar em consideração na estrutura de cenários

Quem é o sujeito?

Nos cenários, como devo me referir a quem executa as features do sistema?

De novo, não tem um certo ou errado, apenas mantenha um padrão de como vai chamar o sujeito, seja “usuário”, “cliente” ou “eu”. Aqui, a preferência é por descrever como vai ser testado.

Ou seja, não importa muito o nome, mas se começou a chamar de “cliente”, estabeleça como padrão e chame de “cliente” em todos os outros cenários, a não ser que o contexto mude realmente e quem vai interagir no sistema mude para o “vendedor”, por exemplo.

Gestos dos usuários

Se você está escrevendo cenários para dispositivos mobile, precisa se referir aos gestos que o usuário vai fazer. Por exemplo: tap, swipe, pinch.

Aqui queremos descrever o que a feature vai fazer. Como vai fazer pode mudar, e se mudar, você tem que alterar os seus cenários, então não se apegue a componentes da tela, como botões, ícones ou até mesmo gestos do usuário, pois o design pode mudar.

A mudança é sadia – isso significa que estamos inspecionado e adaptando para conseguir melhor usabilidade, e isso é bom.

Evite usar termos ligados à tela, pense sempre em como o usuário utiliza a funcionalidade (alto nível). Devemos evitar termos do tipo: clicar em links, preencher os campos ou códigos de seletores.

Cenários não são casos de testes

Os casos de testes são bem descritivos e precisam ser assim, pois serão executados por uma pessoa que provavelmente não vai ter o conhecimento do sistema, como equipes independentes de teste, por exemplo.

Já os cenários, são automatizados e têm steps que executam os passos necessários até chegar a um resultado esperado (ou não), e se não obtiverem sucesso na execução, evidências serão geradas automaticamente (assim espero).

Outro ponto positivo de trabalhar com a revisão dos cenários por outro QA, foi o ágil em escala. Como o QA que revisava meus cenários era de outro time, mas do mesmo projeto, foi mais fácil não duplicar steps e reaproveitar outros que já tinham sido escritos.

Podemos ter mais de um “Então” ou mais de um “Quando”?

É recomendado utilizar apenas um por cenário. Os dois juntos podem significar que poderíamos ter um outro cenário ali, garantindo um valor único para cada cenário.

Acordamos no início do projeto que também não teríamos um “E” após um “Quando”, porém, depois sentimos a necessidade disso. Então, não se apegue ao “seu” código, pois ele não é nosso, é do projeto, e lembre-se de que o objetivo é passar a informação de uma maneira simples, concisa e entendível.

Observe se o que está descrito no título do cenário está bem descritivo no “Quando” e no “Então”. Se não ficar bem explícito, talvez você deva mudar o título do seu cenário.

Dicas de boas práticas de BDD

Nomes de arquivos

Agrupe seus arquivos de features por objetivos de negócio:

busca.feature
login.feature

Cenários declarativos

Os cenários declarativos permitem que pessoas não técnicas possam ajudar a escrevê-los e mantê-los. Pense mais no negócio e menos na implementação.

Imperativo (não recomendado)

Cenário: Fazer uma retirada de uma conta com fundos
Dado que minha conta esteja ativa
E que possua R$100,00 de saldo
E que inseri meu cartão no ATM
E informei minha senha
E pressiono “ok”
Quando faço uma retirada de R$50,00
Então devo receber R$50,00
E o meu novo saldo deve ser R$50,00

Declarativo (recomendado)

Cenário: Fazer uma retirada de uma conta com fundos
Dado que esteja logado na minha conta
E que possua R$100,00 de saldo
Quando faço uma retirada de R$50,00
Então o meu novo saldo deve ser R$50,00

Insira uma narrativa

Use uma narrativa resumida, que diga o que aquela .feature faz.

Eu enquanto possível cliente de um e-commerce
Quero realizar uma busca de produto por texto
Para poder encontrar o que desejo rapidamente

Evite usar ‘e’

Se um step possui duas ações ligadas por um ‘e’, você provavelmente deveria quebrá-lo em dois steps:

Dado A e B

Deveria ser:

Dado A
E B

Reuse os steps

A seguir, um exemplo com Ruby.

Feature:
Cenário1
Dado que eu loguei com credenciais válidas
Cenário2
Dado que eu loguei com sucesso

Steps:
Dado(/^que eu loguei com sucesso$/) do
  step %{que eu loguei com credenciais válidas}
end

Use contexto

Se algum step se repete para todos os cenários de uma feature, use o contexto.

Contexto:
    Dado que o usuário esteja logado
Cenário: A
  Quando y
  Então x
Cenário: B
  Quando y
  Então z

Use linguagem de domínio do negócio

O maior benefício de usar Cucumber é ter os stakeholders envolvidos no projeto. Por isso, utilize uma linguagem que seja comum ao negócio.

Escreva cenários independentes

Não utilize acoplamento entre os cenários – cada cenário deve ser independente e prover sua própria massa de dados.

Utilize as tags

Use as tags para realizar parametrização na execução. Podemos criar uma tag @smokeTets ou @testeRegressivo, por exemplo.

@smokeTets
Cenário: Realizar login com sucesso
   Dado que informei os dados obrigatórios
   Quando tocar em Entrar
   Então devo ver o login realizado com sucesso

Fica a dica.

Tem alguma outra dica pra compartilhar? Dúvidas? Aproveite os campos abaixo.

Até a próxima!