Nesta técnica, os testes de
aceitação são criados de maneira colaborativa e descritos em uma linguagem
comum a todos os membros da equipe. Dessa forma, toda a equipe compartilha o
mesmo entendimento do que deve ser feito, as restrições e as definições de
"Pronto".Essa nova abordagem traz os benefícios do TDD incorporando os
critérios do cliente, dessa forma, uma funcionalidade só estaria completa quando além
das necessidades técnicas, ela também implementasse todos os testes que
comprovam que a implementação está se comportando como o esperado. Os
testes são descritos em uma linguagem natural similar a linguagem do negócio e
deve ser facilmente entendida pelo cliente.
Os testes (critérios de aceitação) devem ser executáveis e tais testes
representam expectativas quanto ao
comportamento que o software deve
ter. Em ATDD, a equipe cria um ou mais
testes em nível de aceitação para uma funcionalidade que está sendo atualmente
trabalhada [HENDRICKSON,2008].
ATDD tem por objetivo capturar os critérios de
aceitação para as features em desenvolvimento. Normalmente isso é discutido,
identificado e levantado quando a equipe de teste interage com os responsáveis
pelo negócio, visando compreender sua real necessidade. Em complemento à
prática de TDD, que visa garantir que as funcionalidades bases da aplicação
sejam desenvolvidas em conformidade com a arquitetura e projeto, a prática de
ATDD tende a prover feedback sobre o quão perto da conclusão da tarefa a
equipe de desenvolvimento se encontra, demonstrando uma clara visão do
progresso [NADALETE, 2010].
O desenvolvimento dirigido por testes quando aplicado é definido pelas
seguintes etapas:
● Discutir (Discuss): trata da discussão
colaborativa com a equipe sobre as restrições,
assunções, premissas, expectativas, etc para definir os critérios de
aceitação. Esta etapa visa elicitar os critérios de aceitação.
● Refinar (Distill): trata do refinamento dos critérios de aceitação
em um conjunto concreto de cenários/exemplos de uso descrevendo o comportamento
esperado da aplicação em uma linguagem comum a todos os membros da equipe
● Desenvolver (Develop): trata da transformação
dos testes de aceitação (descrevendo o comportamento esperado do software) em
testes/especificação automatizados
O processo de
desenvolvimento é ilustrado pela figura abaixo:
Figura 1 - Ciclo de desenvolvimento
orientado a teste de aceitação, [HENDRICKSON,2008].
Testes de aceitação automatizados
são usados como medida de progresso e
indicador dos níveis de qualidade. Conforme ainda artigo escrito por [HENDRICKSON,2008], fonte
principal deste tópico, a autora apresenta um exemplo simples, prático e bem
completo de como extrair o melhor de ambas as práticas de TDD e ATDD. As
equipes que aplicam as práticas, principalmente ATDD, tendem a sentir os
benefícios ainda na fase de discussão dos requisitos e estabelecimento dos critérios
de aceitação, por meio de uma melhor e mais completa compreensão das
necessidades do cliente.
Pode-se afirmar que esta técnica tem
três objetivos principais, sendo o primeiro, fornecer um meio de comunicação compartilhada para melhorar a
troca de informações entre todas as partes interessadas, ATDD visa não apenas tenta fazer com que o fluxo
de informações se torne mais fácil entre
esses grupos, mas também uni-los. Em segundo lugar, ATDD fornece instrumentos
para armazenar a documentação que se mantém atualizada em toda fase de
desenvolvimento. Finalmente, ATDD implica que o sistema em construção
constantemente corresponda às suas exigências através de testes automatizados,
tornando o requisito o mesmo artefato de teste propiciando sua automação e
sendo ao mesmo tempo o teste de aceitação, logo ATDD caracteriza-se como um
paradigma que provê a documentação viva de um software, sanando assim um grande
problema coma documentação de software
que geralmente requer muito esforço e disciplina para manter-se em sincronia
com o software atual. Sendo assim, o código fonte do programa que é
constantemente alterado ao longo processo de desenvolvimento acaba sempre por
estar efetivamente documentado.
Os seres humanos são incapazes
de comunicarem-se de forma completamente
inequívoca ou não ambígua e, portanto, mal-entendidos são especialmente comuns
quando se tenta explicar a lógica de um
software complexo. Sabe-se que no início do desenvolvimento de um
sistema uma característica inerente a esta etapa é a representação abstrata de
requisitos que por vezes apresentam-se não modeladas ou concretas o suficiente
perante a fase de desenvolvimento gerando assim uma implementação contrária ou
não completa em relação a necessidade do usuário. ATDD tenta eliminar a ambiguidade
apresentando requisitos de software como exemplos de ações do usuário a ser
aplicados ao software, por meio de User Stories que segundo [KOUDELIA, 2011] uma User Story, no contexto
de ATDD, é uma breve descrição do que exatamente o próximo teste de aceitação irá testar. O propósito
deste artefato é extrair o objetivo essencial de uma funcionalidade e limitar seu
escopo. User Stories são destinadas a serem
facilmente compreensíveis e sem nenhuma ambiguidades, portanto são
escritas em linguagem humana natural, usando uma linguagem de domínio. Sendo
assim, teoricamente as User Stories devem ser escritas por especialistas no
domínio para obter o máximo de acurácia em relação a aquela funcionalidade a ser
desenvolvida.
A palavra-chave para este tipo de
técnica é "especificação executável", embora a documentação estática
tradicional deva ser atualizada manualmente. Especificações executáveis têm
muito mais chance de não serem abandonas, já escrevê-las, ao contrário de
escrever estática não-executável e tradicional documentação, torna-se
efetivamente parte de todo o processo de desenvolvimento. Executando estas
especificações é possível visualizar instantaneamente o que realmente o
software em questão faz, enquanto no momento em que se inspeciona o código
fonte é revelado somente o que este supostamente deveria realizar. Trazendo á
tona um benefício desta prática, gerando para uma equipe praticante uma maior
confiança em relação ao trabalho que está sendo desenvolvido. A partir disto, é
possível concluir que práticas como ATDD e suas derivações são intimamente
ligadas a automação de testes.
Sob uma visão geral ainda segundo
[KOUDELIA, 2011] as principais vantagens
do desenvolvimento orientado a testes de aceitação podem ser listados conforme
segue abaixo:
● Testes de aceitação servem como requisitos de
software.
● Testes de aceitação são implementados como
especificações executáveis para verificar que o sistema em teste se comporta
como esperado e satisfaz os requisitos.
● Testes de aceitação servem como um meio de comunicação
clara entre desenvolvedores de software e especialistas de domínio que fornecem
os requisitos.
● Testes de aceitação de proporcionam a todas às
partes interessadas a possibilidade de avaliar o software em toda a fase de
desenvolvimento mas não apenas quando se considera o mesmo pronto.
● Testes de aceitação ajudam a estimar o status
de verdadeiro progresso de um projeto e indicar quando o software está pronto.
● Testes de aceitação tornando o processo
de refactoring mais fácil e sinalizando
quando algo fica quebra durante o processo de refatoração.
● Desenvolvimento orientado a testes de
aceitação leva a software a ser desenvolvido com uma boa características de testabilidade e módulos fracamente acoplados.
Entretanto,
deve-se ressaltar que a utilização do ATDD
ocasiona fatores que muitas vezes dificultam sua aplicação pelo fato do
desenvolvimento ter que realmente ser dirigido pelos testes de aceitação,
tarefa que é porém mais fácil de dizer do que fazer. A maioria dos projetos
envolve as fases de pico e quando os problemas a serem resolvidos imediatamente
surgem o impulso para saltar o processo teste é muito tentador. Fazer isso,
entretanto é perigoso porque escrever partes do código fonte não cobertos por
testes de aceitação afeta o projeto como um todo não só pela falta destes, mas também afeta diretamente os
testes já existentes. Explicar para a gestão do projeto que uma considerável
quantidade de tempo deve ser gastam não produzindo o código do programa em si
pode ser difícil especialmente quando o orçamento já está apertado. Outro
grande desafio com os testes de aceitação é organizá-los. Mesmo um pequeno
software tem normalmente uma série de requisitos que, no caso de ATDD,
significa um lote de testes de aceitação. Test-Driven Development sugere um
grande esforço para sempre manter o código do programa limpo e sustentável. O mesmo se aplica para
testes de aceitação - como o passar do desenvolvimento, os testes de aceitação
em evolução precisam ser cuidados em relação a
eliminação de duplicações e reestruturação testes separados para formar
uma entidade significativa. Finalmente, é quase impossível adotar o ATDD sem
apoio e reconhecimento de outros membros da equipe.
.....
Para mais informações, um blog realmente bom é o do Camilo segue link (http://www.bugbang.com.br/)
Nenhum comentário:
Postar um comentário