Blog > O que é ATDD - Acceptance Test Driven Development

16/fev

Hoje é comum ter diversos termos relacionados a teste de software dentro do mundo ágil, e certamente você já deve ter ouvido falar sobre ATDD (e até se confundido com TDD).Neste post iremos falar o que é o ATDD - Acceptance Test Driven Development


O que é?

ATDD - Acceptance Test Driven Development ou Desenvolvimento Orientado a Testes de Aceitação é uma abordagem ou prática para a criação de requisitos colaborativamente entre o cliente e a equipe onde esta especificação se torna executável. Esta especificação é descrita de um forma natural para que o cliente e a equipe entendam os requisitos e utilize o mesmo sem criação de documentos adicionais para esta etapa. A prática do ATDD está ligada as fases iniciais de criação do backlog do produto.

O ATDD surgiu em 2008 criado por Elisabeth Hendrickson (http://testobsessed.com) utilizando alguns conceitos do TDD - Test Driven Development ou Desenvolvimento Orientado a Testes no intuito de criar testes antes mesmo de criar um código (neste foco um teste automatizado) que representam as expectativas de comportamento que o software deveria ter. Ao invés de criar testes focados em código com a perspectiva do desenvolvedor (que é o foco do TDD) o ATDD prega que o teste seja um teste de aceitação com uma visão direta de negócio voltado ao ponto de vista do usuário.

Especificação por Exemplos: o ponto chave!

Você já deve ter ouvido falar, em algum momento os termos “Especificação por Exemplos” ou “Especificação Executável”. Este termo foi fortemente difundido por Gojko Adzic em dois livros: Bridging the communication gap e Specification by Example (onde eu recomendo fortemente a leitura). O ponto chave é: ao invés de criar documentos que expressam requisitos de uma forma burocrática, muito formal e demasiadamente detalhista é criado um documento expresso em uma linguagem mais natural, focada em comportamento onde o próprio modelo de escrita, além de ser facilmente entendido por qualquer pessoa no projeto, possui um padrão onde pode ser automatizado (não é a regra, mas é o caminho natural na Especificação por Exemplos).

Há atualmente duas formas de criar uma Especificação por Exemplos que seja executável:

  • Utilização do Gerkin com o uso de BDD - Behavior Driven Development
  • Utilização de Fixtures

Processo do ATDD

O ATDD segue um processo bem simples para guiar sua utilização desde a fase inicial do projeto até a automação dos testes e demo para o cliente.

Este ciclo foi criado por James Shore com alterações de Grigori Melnick, Brian Marick, e Elisabeth Hendrickson.

Debater

Durante o período de conversa com o cliente para a obtenção dos requisitos (criação das user stories), que geralmente é na reunião ou workshop de preparação do backlog do produto (chamado de backlog grooming) os papéis pertencentes a equipe (product owner, programador, testador, analista de negócio) fazem uma série de perguntas para obter exemplos de utilização daquele requisito (user story) para que todos possam entender melhor o que está sendo discutido e escrever este entendimento como testes.

Exemplo

O cliente pede uma alteração na funcionalidade de login, depois de sofrer com diversas invasões porque as senhas eram sempre fáceis (elias123, admin137).

Ele propõe então que agora as senhas possuam, pelo menos, 8 caracteres e a obrigatoriedade de conter pelo menos uma letra, um número e um caractere especial.

Para um desenvolvedor, que quer implantar aquela funcionalidade, as dúvidas são quase nulas. Geralmente perguntando qual mensagem deve aparecer se os requisitos não forem atendidos e até mesmo se vai apresentar uma cor diferente no campo.

Um testador um pouco mais antenado iria perguntar:

  • E quando implantarmos essa alteração, como o usuário vai saber que ela foi aplicada?
  • Vamos emitir uma mensagem após o login por algum tempo pedindo para que o usuário altere a senha?
  • Isso já está contemplado no requisito de “Esqueci minha senha” e na alteração de senha no perfil, correto?

Poderíamos escrever diversos testes baseados em perguntas funcionais (e até vamos), mas o grande foco aqui é debater sobre o negócio para que nada seja impactado.

Refinar

O refinamento é feito em um formato de documento mais amigável e, de preferência, entendido pelos frameworks de automação de teste que entendem algum tipo de escrita de testes de aceitação como o formato para o Fit ou Cucumber (Gherkin), por exemplo.

Neste ponto a documentação adotada tem que ser entendida por todos no time, inclusive seu cliente.

Exemplo

Formato amigável para explicação ao cliente.
É interessante debater com o cliente exemplos de funcionamento, e isso pode ser feito no refinamento.
Podemos fazer mais perguntas do tipo: o que é um caractere especial para você? E então mostrar as informações obtidas de forma mais clara.

Uma Tabela de Exemplos (conhecida por alguns como Tabela de Decisão)

Argumento (Senha)ObservaçãoAção (Válido/Inválido)
p@ssw0rdletras, caractere especial e númerosVálido
@@@000ddletras, caracteres especiais e númerosVálido
p@ss w0rdletras, caractere especial, números e espaçoInválido
passwordsomente letrasInválido
p@ss3letras, caractere especial e números, total 5Inválido
passw0rdletras e númerosInválido
@@@000caractere especial e númerosInválido

Isso é um ótimo começo que fica claro para o cliente e para o time.

Depois podemos transformar isso em algo mais formal para que uma ferramenta faça parte do trabalho.

Vamos com um exemplo em Gherkin (Cucumber)

Desenvolver

O desenvolvimento é feito em duas vertentes: uma por parte dos programadores e a outra por nossa parte, testadores.
Ambos irão utilizar o mesmo documento para o desenvolvimento.
Como essa abordagem é voltada a aceitação nossa automação será na interface gráfica, logo usaremos algum framework de automação de teste para automatizar esta funcionalidade e mante-la executando na regressão

Exemplo

Ela pode ser diretamente ligada ou não ao framework que entende a escrita de testes de aceitação. O exemplo abaixo mostra exatamente o script desenvolvido com o Cucumber + Selenium WebDriver.

Observação: o script é apenas um exemplo e a página em questão não existe.

Demo

A demo nada mais é que a execução dos testes e a verificação da user story pelo cliente (product owner).

Essa demonstração pode ser feita em reuniões de demonstração no final da script ou entrega, mas o ideal é que seja feita em uma reunião de revisão para que o cliente aprove ou não. A reunião pode trazer mais casos/cenários e alteração de outros.

Você pode mostrar a execução do script, os resultados e explicar o fluxo que o script executou.

Exemplo

Segue um exemplo apenas do resultado final da execução da automação, mas notem que até mesmo o formato do resultado da execução é facilmente entendido.

Conclusão

O ATDD pode e nos traz ganhos que não imaginaríamos em qualquer outro modelo que chamamos de tradicional (cascata, RUP, etc...). Mas há uma mudança organizacional que deve ser estabelecida. Se você quiser iniciar com a aplicação desta abordagem tente sempre validar os seus pensamentos sobre testes (e os seus testes em si) com o cliente. A automação aqui também é mandatória para evitarmos perder tempo com teste manual ao longo das entregas (ciclos).

POSTS RELACIONADOS

AGENDA

CURSOS RELACIONADOS