Skip to content

Acceptance Test Driven Development (ATDD)

hugo-asb edited this page Oct 20, 2016 · 14 revisions

Responsáveis: missão nascente + jardim botânico web


Teste de Aceitação

Definição

Boas práticas para a criação de testes de aceitação

É importante lembrar que o uso do termo *escrever o teste* não necessariamente está relacionado a implementação dele, mas sim à definição do que deve ser testado, quais são os aspectos relevantes do teste e ainda, qual deve ser o resultado esperado.

  • Pertence ao cliente

O propósito principal dos testes de aceitação é especificar os critérios que irão confirmar que uma história de usuário está funcionando. Logo, a pessoa mais bem posicionada para escrevê-los é o cliente, que tem a maior compreensão do que o produto deve fazer para atender o usuário final.

  • Devem ser escritos em conjunto

Mesmo que o maior interessado do produto esteja numa melhor posição para definir os testes de aceitação, a falta de conhecimento sobre o funcionamento da metodologia ágil, de histórias de usuário ou de testes em programação pode ser um problema se este escrever os testes sozinho. Por isso, a melhor forma de realizar essa tarefa é definir o que deve ser testado em conjunto, de maneira que toda a equipe se mantenha integrada e tenha noção do escopo de cada teste, além de aumentar a comunicação entre cliente e desenvolvedor.

  • É sobre o o que, e não sobre o como

É importante perceber que os testes de aceitação devem focar em _onde está o valor para o usuário final_, ao invés de em como esse valor é adquirido. Ao escrever um teste de aceitação não se deve focar na implementação, mas sim nas ações que são feitas e os detalhes desnecessários devem ser omitidos.

  • Deve ser de maneira que o cliente possa compreender

Como é recomendado que os testes sejam escritos em conjunto com o cliente, é fácil compreender que a descrição dos passos de cada teste deve ser feita em uma linguagem simples e fácil, de maneira que o cliente possa compreender o que será feito em cada um e quais são seus objetivos.

  • Deve ser conciso, preciso e não ambíguo

Uma boa prática na realização dos testes de aceitação é manter a simplicidade na descrição dos passos. Não é necessário descrever quais telas precisam ser acessadas, quais botões são utilizados e outros fatores semelhantes - estes são passos da implementação. O ideal é reforçar apenas o objetivo real do teste, de maneira que a compreensão seja imediata.

Desenvolvimento Orientado a Teste de Aceitação (ATDD)

O que é?

_O Acceptance Test-Driven Development_ (ATDD), ou "Desenvolvimento Orientado a Testes de Aceitação", é uma prática de obtenção de requisitos de forma colaborativa aplicada por equipes ágeis, onde exemplos concretos e testes automatizados são utilizados para especificar os requisitos, tornando-os mais claros, com o objetivo de criar especificações executáveis.Eles são gerados em sessões de criação do _backlog_ do produto, com a participação da equipe, _Product Owner_, além dos demais interessados.

O ATDD é muito similar ao TDD, diferenciando-se deste último pelo fato de termos uma colaboração maior entre o desenvolvedor, analista de qualidade (_tester_) e negócio (cliente/partes interessadas). Enquanto o teste unitário está intrinsicamente relacionado com o código, de um ângulo do desenvolvedor (visão interna), o teste de aceitação está voltado ao ponto de vista do usuário, uma visão externa ao sistema. ##Ciclo do desenvolvimento da metodologia ATDD

##Aplicando o ATDD

  1. Debater os requisitos

As histórias de usuário (_user story_) são refinadas em um workshop ou em uma reunião de preparação do backlog do produto ([backlog grooming](https://www.scrumalliance.org/community/articles/2011/march/how-to-hold-an-effective-backlog-grooming-session)), antes da reunião de planejamento da iteração/sprint. Em ambos os casos, os participantes são uma equipe multifuncional, o Product Owner e, algum outro interessado que potencialmente tem mais informações sobre as histórias.

Algumas perguntas devem ser feitas para elencar exemplos de utilização ou cenários de uso dessas histórias de usuário e, assim, entendermos melhor o que está sendo conversado, de tal forma que esses cenários possam ser escritos como testes.

  1. Refinar os testes de aceitação

O próximo passo é organizar os testes de aceitação em um formato requerido pelo framework de automação de testes.

  1. Implementar o código com TDD

O próximo passo é implementar a funcionalidade para fazer com que o teste de aceitação passe.

E, para tanto, o desenvolvimento deve iniciar pelos testes unitários, incluindo todas as condições propostas para as expectativas existentes.

Depois de codificados todos os testes unitários, eles são executados e passamos a uma fase para ajustar aqueles que estão falhando.

  1. Apresentar os resultados dos testes de aceitação

Após os testes passarem com sucesso, a história é verificada pelo Product Owner, normalmente em uma reunião de Review/Showcase, onde ele poderá aprová-la ou não. O resultado pode levar à criação de uma nova história ou uma alteração nos testes existentes, a fim de contemplar novos cenários. Outra forma que também funciona bem, e não posterga a validação em uma reunião específica, é a validação de cada história (Review), imediatamente após ela ser desenvolvida pela equipe, de tal maneira que o Product Owner possa fazer isso com o desenvolvedor ou o par de desenvolvedores que a finalizaram.

Treinamento ATDD

  • Incluir descrição do treinamento/DOJO - passo a passo - etapas
  • Registrar os detalhes da dinâmica
  • Infraestrutura Necessária para a dinâmica
  • Código referência no projeto da disciplina (00-Disciplina)
  • Treinamento em, pelo menos 2 linguagens

Referências Bibliográficas

Clone this wiki locally