terça-feira, 9 de outubro de 2012

Acceptance Test Driven Development





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