Testes Tradicionais e Testes Ágeis

14 04 2009

Como trabalho atualmente com desenvolvimento de software utilizando uma metodologia ágil, nada mais justo que falar sobre testes ágeis. Bom, retirei do blog do meu colega Abu, este post, que de certa forma, é dedicado a ele, pois é por causa dele que hoje entendo um pouco mais sobre metodologias ágeis de desenvolvimento. Aqui está na íntegra, o post dele, do dia 30-10-2008.

Este post traz uma visão do Teste de Software realizado de maneira Tradicional e de maneira Ágil.

O texto traz partes retiradas do artigo Agile QA/Testing de Elisabeth Hendrickson, mas este post não tem o objetivo de ser uma tradução do artigo. Seguindo esta visão o texto possui contribuições minhas e da Neilza. Temos também o vídeo da apresentação da Elisabeth, que é indiscutivelmente uma das melhores apresentações que eu já assisti sobre teste de software.

Link do PDF original: http://testobsessed.com/wordpress/wp-content/uploads/2006/11/agiletesting-talk-nov2006.pdf

Teste de software de maneira Tradicional

Nós não vivemos no mundo perfeito onde os requisitos levantados no início do projeto não vão mudar, e o entendimento desses requisitos será possível junto com a tarefa de seu levantamento.

No mundo perfeito o processo levantamento de requisitos, design, codificação e testes será feito uma única vez, pois nesta única execução ele já vai ser realizado de maneira correta.

O teste de software executado de maneira tradicional irá realizar o teste após o término da análise, design e codificação, e os erros encontrados serão entradas do processo de análise, onde o analista de sistemas realiza a validação do erro encontrado pela equipe de testes e após o trabalho do analista de sistemas, é executado o processo de maneira seqüencial, isto é, design, codificação e teste novamente (figura 1).

Um problema que ocorre na não existência de um mundo perfeito é que os cronogramas de projetos não comportam o processo de análise, design, codificação e teste mais que uma vez.

Quando esse processo é executado mais de uma vez, acarreta em impactos nos cronogramas e consequentemente na tríplice restrição: Escopo, tempo e custo, que traz impacto direto na qualidade.

fig1

Na falta do mundo perfeito os gerentes do projeto na hora de estabilizar o cronograma realizam cortes de tempo, o que acarreta em impacto na qualidade (tríplice restrição), assim o primeiro tempo a ser cortado é o tempo dos testes de software (figura 2).

Como software nada mais é que algoritmo implementado, o tempo de codificação é sempre protegido o máximo possível, sem código implementado não existe teste e é nessa visão de execução que o teste é punido.

fig2

Testes Ágeis

Para a implementação de técnicas ágeis no ambiente de testes, temos a necessidade de mudar a maneira que as equipes estão acostumadas a trabalhar. Uma das mudanças necessárias é a introdução ao conceito de colaboração com o cliente, ao invés de se utilizar documentação abrangente, este item faz parte do manifesto ágil. Desta maneira passamos a fazer um trabalho mais próximo com o cliente, onde a sua participação no processo é peça chave para que a técnica ágil de testes possa ser adotada. Outro ponto importante é que todos da equipe devem realizar testes e não apenas o analista de testes. Em ágil nós falamos que a equipe é infectada por testes e desta maneira o sistema é construído para estar testado desde o início do projeto e não apenas no fim da codificação.

A qualidade passa a ser da equipe e não apenas dos analistas de testes ou profissionais que possuem a palavra “Qualidade” nos seus cargos.

O projeto que nasce com cobertura de teste desde início permite Teste de Regressão, que é executar testes em todo o sistema e não apenas na funcionalidade implementada.

Ter um sistema com cobertura de testes desde o início, é realizar o máximo possível de uma cobertura automatizada de testes, para que o trabalho manual e repetitivo não venha a ocorrer.

Esta técnica traz ganho de tempo na execução do teste, onde o custo de transformar um caso de teste em automatizado rapidamente se paga. Eu tenho observado em minhas equipes um custo de 30% a mais na execução e transformação do teste em automatizado, mas após a terceira vez que eu executo a bateria de testes, eu já vejo como este custo de 30% saiu barato.

O tempo de execução do automatizado com relação ao manual é incomparável, os ganhos de velocidade de execução e a possibilidade de a qualquer momento realizar um teste de regressão são maiores.

Os testes de maneira ágil devem seguir o conceito de pequenas interações, para que a informação de retorno como está sendo construído o sistema e os erros que existem sejam rapidamente identificados e corrigidos. O término de uma interação deve ter todos os testes executados com êxito (figura 3).

fig3

Os desenvolvedores e os testadores devem fazer parte de uma mesma equipe, para que exista colaboração e comunicação entre eles. Assim conseguiremos criar o conceito de equipe e poderemos realizar a condução dos testes e do desenvolvimento do sistema como uma única equipe, isto é, todos juntos, onde os acompanhamentos da execução do desenvolvimento e da execução de testes estão sincronizados, e estes profissionais acompanham a execução, falha e status de ok do código validado pelos testes.

É uma mudança de paradigma, mas é uma mudança que trás resultados rápidos e perceptíveis.

Abraços, Abu e Neilza.

Fernanda


Ações

Information

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s




%d blogueiros gostam disto: