19
abr 17

Testes de Aceitação com BDD – Como obter melhores resultados

Testes de Aceitação com BDD – Como obter melhores resultados

BDD (Behavior Driven Development) é uma técnica de desenvolvimento ágil, que visa integrar regras de negócios com linguagem de programação, focando o teste no comportamento do software. Usando BDD como cenário de teste, o time tem a possibilidade de manter a documentação viva, obter feedback rápido e alinhar a comunicação com o time e com o cliente.

Como fazer

Assim que o Product Owner finaliza o refinamento das Histórias de Usuário (User Story) e os Critérios de Aceite (Acceptance Criteria), antes de iniciar a Sprint, o QA deve revisar as histórias e os requisitos e, em seguida, escrever os cenários de validação para as funcionalidades que são candidatas a entrar em desenvolvimento. Para realizar esta tarefa utilizamos os conceitos de BDD.

BDDImagem 1 – Arquivo de Gherkin por História de Usuário. Fonte: It’s a Delivery Thing.


 

Escrevendo BDDs e mudando o Mindset

Quem escreve Casos de Teste (Test Case) e começa a escrever cenários no formato Dado/Quando/Então consegue rapidamente gerar documentações que no futuro podem ser automatizadas. No início é normal observar especificações tão detalhadas quanto casos de teste, como no exemplo:

Cenário: Cadastrar Perfil Auxiliar
Dado que eu esteja na tela de boas vindas
Quando eu acesso o menu Cadastrar Perfil
Então o sistema exibe a tela de Cadastrar Perfil
E eu preencho o campo Nome com o valor Nome XY
E eu seleciono o perfil de usuário Auxiliar
E eu preencho o campo E-mail com o valor Nome XY
E eu clico no botão Salvar
Então o sistema exibe a mensagem “Usuário cadastrado com sucesso”

No entanto, é essencial neste momento que o QA consiga mudar seu mindset (modo de pensar), visto que os objetivos do BDD são descrever o comportamento das funcionalidades e obter feedbacks rapidamente garantindo que a funcionalidade está de acordo com o esperado. No exemplo anterior, temos a descrição de um script e não o comportamento em uma funcionalidade. Ou seja, fazendo assim não contribuímos para o bom entendimento do time e muito menos para o entendimento por parte do cliente, além de dificultar o processo de automação dos testes. Os impactos da má formulação dos BDDs, para a validação dos testes de aceitação, são observados com o passar das sprints e com a evolução da aplicação, com o aumento de demandas de manutenção.

Algumas dicas para escrever bons cenários:

  • Eles devem descrever o comportamento e não ser um passo a passo;
  • Precisam seguir a linguagem da história do usuário e dos critérios de aceite;
  • O time deve ser envolvido no processo;
  • Os cenários devem ser independentes;
  • Utilize tags para exportar exemplos.

Sendo assim, o cenário de teste que contemplaria as dicas seria:

Esquema do Cenário: Cadastrar Perfil de <perfil>
Dado que eu esteja logado como um Administrador
Quando cadastro um usuário com o perfil de <perfil>
Então o sistema deve exibir a mensagem de confirmação de cadastro

Exemplos:

| perfil                          |
| Auxiliar                     |
| Coordenador         |

O próximo passo é, antes da reunião de planejamento, organizar todos os cenários das funcionalidades que serão discutidas na reunião e apresentados para o Product Owner, visando confirmar se os cenários estão correspondentes com o escopo e as metas de negócio levantadas com o cliente. Durante a reunião de planejamento, além das histórias de usuário e critérios de aceite, os cenários devem ser discutidos e refinados com o time, conceito de Especificação por Exemplo.

BDD Time
Imagem 2. Fonte: Dion Beetson – A developers blog.


Deste modo, construindo BDDs conforme as dicas acima, reduzimos as chances de modificações no decorrer da sprint, gerando menos retrabalho e maior confiança do time com o produto. Além disto, no processo de automação, temos mais maturidade para codificar os testes de aceitação.


Quer saber mais sobre Testes de Software? Acesse o material que preparamos para você!

Acessar conteúdo


Fontes: Scrum AllianceDelivery Thing; ThoughtWorks; Dan North & Associates; W3ii; Concrete Solutions.

Raphael Silva
Raphael Silva

Raphael Rodrigues é Analista de Testes da SoftDesign e faz parte da equipe há mais de 3 anos. Bacharel em Sistemas da Informação e seguidor de metodologias ágeis, possui experiência em automação de testes funcionais Web e Mobile.

Deixe uma resposta