Capítulo 7: Teste ágil, como implementar?

De Dftestes

Autor: Lucas Gonçalves Nadalete
Revisora: Juliana Kryszczun

Tabela de conteúdo 1 Introdução 2 O que é Teste Ágil?' 3 O que muda do Teste Tradicional para o Teste Ágil? 4 Como podemos implementar Teste Ágil no dia-a-dia? 4.1 ATDD e TDD, como implementar? 5 Quais as dificuldades de se implementar Teste Ágil? 6 Quais as vantagens de se implementar Teste Ágil? 7 Conclusão 8 Referências Bibliográficas

Introdução

O uso de metodologias e práticas de desenvolvimento ágil têm se tornado algo cada vez mais natural no cotidiano das empresas . Algumas dessas empresas, apesar de não admitirem sua adesão, implicitamente acabam aplicando algumas práticas comuns, com o objetivo de obter resultados mais cedo.

Essas práticas tendem a estimular e valorizar a equipe e a interação constante entre os seus membros, a colaboração constante com os clientes, o funcionamento do software em desenvolvimento e a capacidade de resposta a mudanças.

Poucas sabem, mas na realidade elas estão adotando os princípios ágeis definidos no Manifesto Ágil [1] na data de 11 à 13/02/2001. No entanto, o que muitas não tem claramente definido, é como controlar a qualidade do que está sendo desenvolvido de forma ágil, ou seja, como praticar teste ágil.

Conforme opinião expressa pelos colaboradores e reforçada por meio da própria literatura, aplicar teste ágil exige quebra de paradigmas, mudança de cultura, dinamismo da equipe (pré e pró-atividade), conhecimento técnico, testes automatizados, e muitas outras características e fatores que viabilizam a aplicação de teste ágil, quando praticadas conjuntamente.

Este capítulo apresenta uma explanação sobre "teste ágil e como implementá-lo" do ponto de vista das diversas perspectivas discutidas na Mesa Redonda DFTestes.

O que é Teste Ágil?'

Em se tratando de desenvolvimento ágil, alguns princípios definidos por meio do Manifesto Ágil [1] são utilizados com o objetivo de nortear a linha de produção, como:

• Indivíduos e interações entre eles mais que processos e ferramentas;

• Software em funcionamento mais que documentação abrangente;

• Colaboração com o cliente mais que negociação de contratos;

• Capacidade de responder a mudanças mais que seguir um plano.

Apesar de se valorizar muito mais os itens da esquerda, os itens da direita não são desconsiderados, ao invés disso, os mesmos são aplicados de forma ponderada e conforme a necessidade do processo, sem que haja impacto nas entregas a serem realizadas, prazos estabelecidos e qualidade do produto final gerado.

Os mesmos princípios usados para direcionar o desenvolvimento ágil, devem ser considerados quando for aplicado teste ágil, ou seja, testar de forma ágil exige uma forte adaptação na rotina e dinâmica da equipe de teste, em relação ao processo de desenvolvimento adotado, com o objetivo de propiciar um processo relativamente simples e que possa ser executado com grande facilidade e agilidade, cobrindo o maior número de riscos, com um nível de qualidade que seja apreciada e valorizada pelo cliente ou usuário final.

Através da definição do processo ideal e simplificado, onde o teste ágil é suportado, um conjunto de práticas que proporcionem a diminuição do tempo entre o erro e a sua descoberta tendem a ser estabelecidos em conjunto com uma sistemática de trabalho que possibilite à área de teste de software ser mais pró-ativa do que reativa.

O que muda do Teste Tradicional para o Teste Ágil?

Analisemos algumas das práticas do processo de teste tradicional aplicados na tentativa de gerenciar o "chaos", ou ao menos evitar culpados [2]:

• A área de teste de software assumindo a postura de "Último Defensor da Qualidade";

• Restrições no gerenciamento de mudanças;

• Preparação detalhada e planejamento acima de tudo;

• Conjunto de documentação pesado para a terceirização dos esforços de teste;

• Critérios de entrada e saída rigorosos e com aprovações;

• Automatização de testes pesada e com foco nas regressões;

• Tentativas de execução do processo.

Ao se tratar de teste ágil, essas mesmas práticas não se adaptam à dinâmica almejada. Em um ambiente ágil de controle de qualidade deve-se considerar os prazos e as atividades de teste do começo ao fim da iteração. Ao contrário do teste tradicional, não se espera que uma única equipe se responsabilize pela qualidade final das entregas, mas sim que todas as equipes tenham sua colaboração no controle dessa qualidade, desde o levantamento das necessidades do cliente, até a implantação do produto final gerado.

Figura 7.01 – Deslocamento de papéis - Adaptado de [2]

Conforme pode ser observado na Figura 1, no teste tradicional, espera-se que os defeitos sejam identificados no último nível, pela equipe de QA, enquanto que ao se aplicar teste ágil, isso é antecipado pela própria equipe de desenvolvimento por meio de práticas como desenvolvimento em pares, integração contínua, pequenas entregas, refatoração constante e padrões de codificação, de técnicas como TDD (Test Driven Development) e ATDD (Acceptance Test Driven Development), e através da automatização dos testes gerados.

Ao se trabalhar com testes ágeis, observa-se algumas mudanças de conceito em relação ao modelo tradicional, tais como:

• Mudanças são inevitáveis, e com base nisso toda equipe, incluindo os programadores, testadores e clientes, são responsáveis pelo resultado final;

• Todos da equipe devem estar acessíveis e se comunicando ativamente através do projeto;

• O teste de software se torna mais preventivo, ou seja, programadores testam mais cedo, com mais frequência e agressivamente. Neste ponto a prática de TDD [3] pode e deve ser aplicada;

• Toda equipe solicita ativamente feedback das demais;

• Testadores e programadores tendem a ser mais pró-ativos (participação direta com o cliente) e técnicos (aplicação de práticas XP e técnicas como TDD e ATDD);

• Testadores precisam saber automatizar, com o intuito de manter o ciclo de entregas dos testes sempre no prazo estabelecido e com teste de regressão atualizado. Só não se automatiza, o que realmente não pode ser automatizado ou não vale a pena ser automatizado (e.g. Teste de Usabilidade);

• Os testes tonam-se uma rotina que nasce e morre junto à iteração planejada.

Como podemos implementar Teste Ágil no dia-a-dia?

É possível trabalhar de forma ágil nas atividades de teste de software com qualquer tipo de metodologia de desenvolvimento, desde os mais tradicionais descendentes da família UP (e.g. RUP, EUP, OpenUP, AUP), até as mais ágeis como XP, Scrum, Cristal, Lean e outros. A questão é que nenhuma dessas metodologias garantirá "agilidade" no processo. Ser ágil não exige apenas adotar uma sistemática ágil, mas pensar e agir de forma ágil na plenitude do seu conhecimento.

Figura 7.02 – Fluxo ágil de desenvolvimento [2]

Em um projeto onde a sistemática de trabalho segue os princípios do Manifesto Ágil, o prazo de cada iteração tende a ser reduzido, visando agregar valor mais rápido ao produto final que é apresentado como subsídio para se obter o feedback do cliente (Figura 2).

É neste tipo de iteração que as "atividades de teste" devem assumir características ágeis. A Figura 3 apresenta um processo simplificado de teste ágil que pode ser adotado a cada iteração realizada.

Figura 7.03 – Representação de uma iteração de teste ágil - Adaptado de [2]

• Práticas XP: A aplicação de algumas das práticas de Programação Extrema possibilitam mitigar e minimizar os riscos de introduzir defeitos triviais na aplicação, por meio da aplicação de programação em par, design simplificado, testes, refatoração constante e a aplicação de padrões de codificação [4]. Outras práticas podem ser adicionadas conforme necessidade.

• Teste de Unidade Automatizado: Feito pelos próprios programadores, geralmente com o auxílio de um framework xUnit, e frequentemente como resultado da prática de TDD. A bateria de testes de unidade gerada representa um conjunto de especificações executáveis que apoia o processo de desenvolvimento.

• Teste de Aceitação Automatizado: Representa o resultado da colaboração entre os programadores e os stakeholders de negócio, e são frequentemente implementados com o auxílio de um FIT (Framework for Integrated Testing). A bateria de testes de aceitação gerada representa um conjunto de requisitos executáveis.

• Teste Exploratório Manual: Além de ser necessário para complementar os testes automatizados, os testes exploratórios fornecem algum feedback adicional, cobrindo possíveis lacunas que passam despercebidas pelos testes automatizados de unidade e aceitação.

Para se aplicar teste ágil, não há receita de bolo a ser seguida. É preciso conhecer o processo ágil praticado muito bem, assim como a cultura da empresa e a maturidade dos seus colaboradores em relação ao mesmo, e em cima disso, trabalhar uma estratégia de implantação e execução das atividades de teste dentro do processo.

Algumas sugestões são apresentadas por profissionais e podem ser consideradas na implementação de teste ágil:

• Implantação de forma gradativa, ou seja, a realização de um projeto piloto pode ser adotada com o intuito de iniciar a adoção, adquirir experiência, aperfeiçoar, ajustar e comprovar progressivamente os ganhos;

• Análise antes de automatizar os testes, se realmente vale a pena ou não. A automatização na maioria das vezes proporciona diversos ganhos ao projeto, principalmente a médio e longo prazo, no entanto, a mesma pode custar mais caro que os ganhos proporcionados em determinadas situações;

• Ao se aplicar teste ágil, há uma inversão na pirâmide dos níveis de teste, ou seja, ao invés de termos muitos testes a nível de sistema e aceitação, haverão muitos testes a nível de unidade e integração, onde a responsabiliade primária tende a ser dos programadores;

• Atue junto ao cliente, com o objetivo de obter feedback constante sobre o que está sendo desenvolvido, em relação ao esperado;

• Criar teste de unidade e integração para sistemas legados (código desenvolvido sem teste), é algo impraticável e pode impactar no orçamento e prazo final planejado.

ATDD e TDD, como implementar?

É muito comum ouvirmos a respeito de desenvolvimento orientado a teste (TDD) como uma "técnica para teste" onde os testes de unidade produzidos, guiam o desenvolvimento do código fonte da aplicação. Na verdade TDD não se trata de uma técnica, e sim de uma "prática de programação" que resulta em uma suíte de testes de unidade, onde tais testes são um efeito colateral e não o objetivo em si [7].Na aplicação da prática de TDD é guiada por três passos básicos, usados no desenvolvimento dos testes de unidade, e consequentemente do código fonte da aplicação:

• Desenvolve-se um teste de unidade que falhe, para demonstrar que a base de código existente ainda não contém tal recurso implementado;

• Uma vez que se tenha o teste de unidade que falhe, produz-se o código de produção para tonar o teste executável e fazê-lo passar;

• Com o teste passando, refatora-se o código com o objetivo de enxugar e eliminar duplicações para deixar o código fonte legível e melhorar o design.

Aplicar TDD nem sempre é uma tarefa fácil e muitas vezes é tida como complexa por pregar a criação dos testes antes mesmo do código da aplicação, além de representar expectativas quanto ao comportamento do software.Mas e o que a "prática" de ATDD tende a oferecer além da TDD?

ATDD visa capturar os critérios de aceitação para a funcionalidade 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.

A Figura 4 apresenta claramente o ciclo de desenvolvimento orientado a teste de aceitação, e como a prática de TDD pode ser inserida visando aumentar a abrangência dos testes.

Figura 7.04 - Ciclo de desenvolvimento orientado a teste de aceitação [7]

No artigo escrito por Elisabeth Hendrickson [7], 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.

Quando o ciclo proposto na Figura 4 é trabalhado do começo ao fim do projeto, os envolvidos tendem a concordar que o sistema tende a se tornar mais testável, manutenível e relativamente fácil. Com a suíte de testes gerada é possível efetuar os testes de regressão automaticamente, fornecendo um pronto feedback sobre as expectativas relacionadas às funcionalidades bases do sistema, e ao negócio como um todo.

Quais as dificuldades de se implementar Teste Ágil?

Nem todos os ambiente são propícios para a adoção e execução de desenvolvimento ágil. Barry Boehm e Richard Turner [5] sugerem em seu trabalho que a análise de risco seja usada para escolher entre métodos adaptativos ("ágeis") e preditivos ("dirigidos pelo planejamento"), destacando o ambiente ideal para cada um destes:

• Ambiente ideal para o desenvolvimento ágil:
  • Baixa criticidade;
  • Desenvolvedores sênior;
  • Mudanças frequente de requisitos;
  • Pequeno número de desenvolvedores;
  • Cultura que tem sucesso no caos.

• Ambiente ideal para o desenvolvimento direcionado a planejamento:
  • Alta criticidade;
  • Desenvolvedores júnior;
  • Baixa mudança de requisitos;
  • Grande número de desenvolvedores;
  • Cultura que procura a ordem.

Muitas vezes as características acima apresentadas são consideradas ao se definir qual a metodologia a ser adotada em um projeto de desenvolvimento de software e, consequentemente na sistemática adotada para as atividades de teste. Dentre outros fatores que podem comprometer a adoção de uma abordagem mais ágil na dinâmica de testes dentro da empresa, cita-se:

• Cultura organizacional resistente;

• Requer muita mudança cultural;

• Pode levar a maiores dificuldades nas negociações contratuais;

• Equipe não multidisciplinar, ou seja, considerando o fato de que o time de teste é forçado a cada vez mais estar pequisando e se aperfeiçoando em relação à novas ferramentas, além de saber programar, pois a automação se torna um elemento essencial, espera-se que os colaboradores sejam multidisciplinar;

• Cliente não é ou prefere não ser ágil, assumindo uma metodologia direcionada a planejamento. Neste ponto, espera-se que ao optar por uma metodologia ágil, o cliente seja participativo e comprometido com o sucesso do sistema, passando para o time de desenvolvimento suas reais necessidades e opiniões do sistema;

• A área de teste participando de forma reativa, ou seja, contando sempre com todos os documentos à mão, o que nem sempre é uma realidade em um ambiente ágil.

Segundo José Correia, um profissional especialista da área de teste de software, o mesmo relata sua experiência prática em relação à resistência do mercado na adoção de metodologias ágeis:

"Nos projetos que acompanho, o uso de práticas ágeis é elegível apenas quando o número de horas totais do projeto é inferior a 1000 horas. Alguns clientes são mais conservadores e estabelecem um teto de 640 a 800 horas. Projetos acima são executados dentro das práticas do RUP, modelos CMMI/MPS-Br e os testes complementados com base no Syllabus/ISTQB, CBOK/QAI, normas ISO e IEEE."

Experiências como a citada acima, nos mostram que um ambiente ágil nem sempre é elegível para um determinado projeto, seja pelas especificações do projeto a ser executado, seja pela capacitação dos recursos envolvidos, seja pelo prazo estabelecido, ou até mesmo pela resistência organizacional ou do cliente final. O que nos cabe é analisar cada caso e avaliar qual a melhor metodologia de desenvolvimento e teste a ser aplicada, e não simplesmente aplicá-la por aplicar.

Quais as vantagens de se implementar Teste Ágil?

A aplicação de teste ágil proporciona diversas melhorias, não só a nível de qualidade do processo, como também na qualidade do produto. A equipe de desenvolvimento se apresenta mais motivada e segura em relação a qualquer mudança que seja efetuada na aplicação. Em um ambiente ágil, os bugs são identificados, relatados e corrigidos em um curto espaço de tempo, pelo fato do foco estar na prevenção e não na remediação dos mesmos. O desenvolvimento torna-se sustentável.Em um ambiente ágil, a tendência é que as entregas sejam feitas mais rápidas, em curtas iterações. A gestão de defeitos tende a ser, também, mais dinâmica, pois passa a ser executada diretamente pelo próprio desenvolvedor, sem o relato de inconformidades e intervenção do testador, como também pode ser fomalizada pela equipe de QA à equipe de desenvolvimento quando identificadas a nível de sistema ou aceitação.

A participação do cliente nas atividades de teste se torna mais efetiva, ou seja, faz com que o software tenha realmente aquilo que precisa ter, e faça aquilo que realmente precisa fazer. Em paralelo, a automatização de testes adquire muito mais importância, possibilitando a realização de ciclos enxutos e cada vez mais rápidos, além de garantir a validação regressiva das funcionalidades, e de forma econômica.Ao se aderir a teste ágil, o retrabalho e manutenção executados na aplicação são bem menores, pois as validações são realizadas em todos os níveis da aplicação (unidade, integração, sistema e por fim aceitação do cliente final). Com isso, o custo e tempo atrelados ao desenvolvimento também tendem a reduzir.

É possível observar que o fator "tempo" tem se tornado cada vez mais curto, levando muitos profissionais a casarem a ideia de agilidade com qualidade. Com base nisso, tenta-se estabelecer um equilíbrio unindo o "útil" (qualidade) ao "necessário" (agilidade), sem perder a real essência das atividades de controle de qualidade. Em outras palavras, "agilidade" não representa "ter pressa", da mesma forma que não simboliza evitar a "documentação", pelo contrário, ser "ágil" significa fazer direito, conciso e coeso, onde toda documentação que seja efetiva e útil, é mais que assimilada. É por esse motivo que a documentação de teste de software esta entre uma das melhores e mais efetivas.

Em um artigo publicado na InfoQ por Kay Johansen, a mesma questiona à diferentes especialistas da área "Por quê você ama teste ágil?", obtendo as mais variadas respostas, as quais são compiladas em 10 razões chaves para isso [6]:

• Não há mais teste manual de scripts!: Scripts são executados automaticamente, disponibilizando mais tempo para o testador executar testes exploratórios.

• Desenvolvedores realmente gostam de mim!: Localizar problemas antes do final da iteração e enquanto o código está fresco na mente dos desenvolvedores, facilita o trabalho dos mesmos.

• Agora eu posso verificar os recursos antes deles serem escritos! (ambos Kay e Philip) – O testador pode evitar problemas ao iniciar o teste, antes que os recursos sejam definidos.

• Os resultados do teste automatizado podem ser visto muitas vezes ao dia – Fornecendo um feedback rápido após qualquer alteração.

• A atmosfera é fortemente orientada a equipe (John Overbaugh) – Cada membro da equipe se preocupa em terminar os testes e não somente o código (Lisa Crispin).

• O testador pode ocasionalmente ajustar o defeito  (Lista Crispin) – Cada membro da equipe sente-se mais confortável já que o teste é automatizado.

• Fornece a oportunidade para revisar constantemente as práticas de teste (Adam Knight) – Ao invés de simplesmente repetir o que foi feito anteriormente, as práticas são constantemente revistas. No caso de Adam os testes que costumavam levar 5 dias para serem executados manualmente foram reduzidos agora para 30 minutos.

• Eu gasto muito, muito menos tempo debugando  (Adrian Howard) – Eu tenho o feedback quase ao mesmo tempo em que cometi um erro, por isso, geralmente é trivial localizar e corrigir.

• Há chance de realmente impactar na qualidade ao invés de somente documentá-la! (Jonh Overbaugh) – Quando os defeitos são corrigidos imediatamente ao invés de colocar numa pilha de defeitos.

• Sempre existe tempo para testar, porque o teste é feito primeiro- Josue Barbosa dos Santos contou a história de trabalhar num escritório do governo no Brasil onde a prática era testar no final do projeto. O desenvolvimento estava sempre atrasado no cronograma do projeto, atingindo o prazo limite e sendo liberado para os usuários sem teste. Com a introdução das técnicas de TDD e ATDD pelo menos algum teste era executado enquanto o software era desenvolvido.

Conclusão

Os benefícios proporcionados pela aplicação de teste ágil tendem a ser extraordinários quando explorados da forma correta, com as práticas e técnicas corretas, e sob a análise correta dos recursos, infraestrutura, ambiente, frameworks e ferramentas a serem utilizados e aplicados no ciclo de vida de desenvolvimento do software.

A sistemática de teste aplicada tende a ser mais ousada e dinâmica, fornecendo feedback constante a equipe de desenvolvimento, que passa a se comprometer também com a qualidade do produto final, por meio da implementação de testes de unidade (TDD).

É comum ao se aplicar teste ágil, confundir o conceito de "agilidade" com "rapidez", quando na realidade está atrelado à "qualidade" e "integridade" dos artefatos finais entregues. Ao se aplicar uma abordagem ágil, as iterações tendem a ser menores, assim como as entregas tendem a ser efetuadas em um curto prazo de tempo,  no entanto cabe a equipe de teste em conjunto com as demais áreas garantir a consistência e qualidade final do produto gerado, assim como a satisfação do cliente diante das suas expectativas. Isso pode ser feito de várias formas, inclusive através da adoção das práticas de TDD e ATDD.

Em cada projeto desenvolvido, pode-se observar um conjunto de variáveis que influenciam diretamente nas decisões tomadas antes, durante e após o projeto, muitas vezes a favor e outras vezes contra a adoção de abordagens ágeis de desenvolvimento. No entanto o que se pode observar, é que "teste ágil" é uma realidade viável que pode extrair o melhor da equipe e do processo aplicado, fornecendo retorno imediato e a curto prazo diante da sistemática de teste adotada.

<- Voltar para o capítulo anterior | Ir para o próximo capítulo ->

Referências Bibliográficas

[1] FOWLER, Martin; HIGHSMITH, Jim. The Agile Manifesto. SD Magazine. Agosto, 2001. Disponível em: <http://andrey.hristov.com/fht-stuttgart/The_Agile_Manifesto_SDMagazine.pdf>. Acessado em: 02/02/2010.

[2] HENDRICKSON, Elisabeth. Agile QA/Testing. Quality Tree Software, Inc. Novembro, 2006. Disponível em: <http://testobsessed.com/wordpress/wp-content/uploads/2006/11/agiletesting-talk-nov2006.pdf>. Acessado em: 10/02/2010.

[3] BECK, Kent. Test Driven Development: By Example. 1. Ed. Addisson-Wesley Professional. Novembro, 2002. 240 p.

[4] Extreme Programming: A Gentle Introduction. Disponível em: <http://www.extremeprogramming.org/>. Acessado em: 11/02/2010.

[5] BOEHM, Barry. Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley, 2004. pp. 55-57.

[6] InfoQ: Top 10 Motivos para Amar Teste Ágil. Disponível em: <http://www.infoq.com/br/news/2009/06/love_agile_testing>. Acessado em: 28/02/2010.

[7] HENDRICKSON, Elisabeth. Driven Development with Tests: ATDD and TDD. Quality Tree Software, Inc. Agosto, 2008. Disponível em: <http://testobsessed.com/wordpress/wp-content/uploads/2008/12/atddexample.pdf>. Acessado em: 08/03/2010.