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.
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.
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).
Eu gosto muito da frase:”Como nós iremos testar isso?”, que deve ser utilizada juntamente com a frase: “Como nós vamos construir isso”.
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.
Postagens
Nenhum comentário:
Postar um comentário