IGTI Blog

Os novos desafios do Testador na Metodologia Ágil

A abordagem ágil trouxe diversos paradigmas novos para que os desenvolvedores possam desenvolver aplicações já orientadas a Testes. Porém, nessa nova abordagem, como fica o papel do Testador, uma figura tão presente na metodologia RUP? Esse artigo tem como objetivo esclarecer como fica essa função, mostrando que o papel de Testador não morreu, e, que, inclusive, evoluiu.

Seguir o planejamento ou reagir a mudanças?

A metodologia tradicional de desenvolvimento sempre primou pela excelência no planejamento. Sendo assim, o membro da equipe deveria seguir os procedimentos à risca (by the book). Qualquer nova atividade, ideia, método, requisito, necessidade, não poderia ser levado em conta, afinal já existia um planejamento que foi feito por profissionais competentes para chegar ao resultado esperado.

Sendo assim, se eu seguir o planejamento à risca, tudo vai dar certo, não é verdade? Bom… nem sempre!

O grande problema dos planejamentos muito engessados é que eles se baseiam no fato de que todos os requisitos, características, situações e riscos são conhecidos, e isso quase nunca é verdade. Muitas vezes, mesmo os projetos muito bem planejados e executados podem ter como resultado um produto ruim. Um conhecido exemplo disso foi o Iridium da Motorola, um projeto de bilhões de dólares que criou um telefone por satélite ao qual seria possível se comunicar em qualquer lugar do mundo. Esse projeto foi aclamado pelo PMI como um dos mais bem planejados da época, que conseguiu ser concluído no prazo, escopo e custo conforme o planejado. Porém, o produto resultante foi um fracasso. E, por incrível que pareça, o principal motivo para o fracasso foi devido ao projeto ter sido executado exatamente como planejado. O mundo mudou, outras tecnologias mais baratas surgiram, a necessidade do público-alvo mudou, e o projeto não contemplou nada disso.

Reagindo a Mudanças

Muitas pessoas pensam, erroneamente, que a palavra “Ágil” da abordagem ágil é sinônimo de velocidade. Na verdade, a palavra ágil significa “capacidade de reação”, ou seja, é a capacidade de romper a inércia, capacidade de se adaptar aos novos fatores do seu ambiente. A velocidade é uma das consequências da agilidade.

Dessa forma, a abordagem ágil foca na reação às mudanças, toda a forma de trabalho deve ser centrada no fato de que é certo que haverá mudanças.

Isso tem um impacto enorme na forma como um membro da equipe deve se portar. Afinal de contas, os membros da equipe têm que realizar todo o seu trabalho já tendo em vista que algo pode mudar. Assim, a criatividade que não era recomendada na metodologia tradicional, agora tem um forte papel.

O Novo papel do Testador

Métodos ágeis exigem grandes mudanças na equipe. E não é somente na equipe de desenvolvimento. Implementar uma metodologia ágil para a equipe de desenvolvimento e não implementá-la para a equipe de teste reduz a flexibilidade e produz resultados insatisfatórios.

Por exemplo, a implementação do código é feito de forma ágil, com kanban, painéis de acompanhamento Scrum e stand-up meetings diários em conjunto com o cliente. Tudo feito conforme as boas práticas sugeridas pela comunidade ágil. No entanto, se o teste de software for feito por outra equipe, este será feito em outra iteração. Erros serão encontrados em funcionalidades que foram desenvolvidas há vários sprints atrás, erros estes que podem inviabilizar sprints seguintes, trazendo atrasos para o projeto. Por isso, não devem existir duas equipes separadas, deve haver apenas uma equipe.

Já em ambientes que trabalham com uma única equipe, muitos questionam se, em uma equipe ágil pequena deve haver um profissional exclusivo para testes. A verdade é que não há um consenso. O Scrum, por exemplo, preza que o time de desenvolvimento deve reunir todas as habilidades necessárias, incluindo as de testes. Porém, especialistas da área, como Glenford Myers, defendem que exista um especialista em Testes que tenha foco somente nisso, para que não aconteça o problema da visão viciada. Porém, mesmo existindo um especialista, algumas atividades de garantia da qualidade podem ser executadas pelo resto da equipe, como planejamento da qualidade, estimativas, elaboração de relatórios e dashboards.

Comunicação mais ativa e antecipação dos Feedbacks

Quanto mais tarde forem realizados os testes, mais problemas serão encontrados e menor será o tempo de resposta para tratá-los. Na abordagem ágil os efeitos de retardar os testes são ainda mais desastrosos. Dessa forma, devem-se iniciar os testes o quanto antes. E quanto mais rápido forem executados os testes, mais rápido será feito o feedback junto ao Product Owner e mais rápido serão tomadas as medidas cabíveis para a solução dos problemas.

Porém, os testes quando realizados de forma precoce, também podem trazer diversos prejuízos se não forem feitos adequadamente. Erros comuns são executar testes em funcionalidades que ainda estão sendo alteradas, ou verificar requisitos errados. Na maioria das vezes isso acontece por problemas de comunicação.

Testadores Ágeis não dispõem de grande documentação de requisitos como base para casos de teste. Eles se apoiam fortemente na comunicação, que pode ser verbal, escrita ou virtual para assimilar a informação que necessitam. Eles aprendem a fazer as perguntas certas, no momento certo e fornecer o nível certo de feedback no melhor momento.

Dessa forma, esses dois pilares devem estar fortalecidos: Testar o mais cedo possível e ter a comunicação ativa, tanto para receber feedback quanto para entender os requisitos.

Acompanhamento dos Resultados

Se não há tempo suficiente para documentações detalhadas, também não há tempo para elaboração de complexos relatórios sobre o andamento da verificação da qualidade. E, para executar essa árdua tarefa, mais uma vez as capacidades de automação e comunicação são fortemente exigidas.

Testadores Ágeis devem saber configurar painéis de testes que deem aos desenvolvedores o feedback necessário em relação à verificação do produto. Esses painéis devem fornecer gráficos, exibir os defeitos mais graves encontrados e priorizados para correção. Além disso, devem fornecer uma visão geral sobre o andamento e evolução da qualidade do software.

Estimativas

O Testador Ágil tem novas responsabilidades, e uma delas é contribuir com Estimativas. O Testador Ágil deve possuir noções de métricas de tamanho de software e ter informações históricas do esforço gasto nas funcionalidades passadas. Assim, ele pode ajudar na estimativa de esforço da seguinte forma:

  • Estimando a quantidade necessária de testes: Baseado na complexidade dos requisitos de qualidade, o Testador Ágil deve fornecer uma estimativa dos testes necessários e de como eles serão executados. A estimativa de testes é importante para dimensionar se o tempo de desenvolvimento dos testes se encaixa no prazo da próxima entrega.
  • Estimando o que pode ser automatizado: o Testador Ágil deve indicar quais requisitos podem ser automatizados. Como testes automatizados são mais baratos e mais eficientes, devem ser priorizados. Saber avaliar corretamente quais testes podem ser automatizados, resultam em uma grande diferença de esforço e qualidade ao final de uma Sprint. De forma geral, o Testador deve priorizar automatizar:
    • Testes de Regressão
    • Tarefas repetitivas
    • Cálculos matemáticos
  • Estimando o que não deveria ser automatizado: Complementando o item anterior, o Testador Ágil deve estimar quais funcionalidades não devem ser automatizadas. De forma geral, a automação não é recomendada para os seguintes casos:
    • Funcionalidades instáveis;
    • Funcionalidades pouco usadas;
    • Funcionalidades que exigem inspeção visual.

Professor autor: Marcelino Campos