Teste ágil, como implementar?

Autor: Lucas Gonçalves Nadalete
Revisora: Juliana Kryszczun

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.

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.

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.

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.