O que é Agile Testing? Entenda como o profissional da área trabalha

Entenda como o Agile Testing, conjunto de práticas de testagem em ambiente de automação, possibilita ao profissional da área a identificação prévia de falhas e a entrega de um produto com desempenho otimizado ao cliente. 

Neste artigo, vamos refletir sobre o processo de Agile Testing e o papel do profissional da área, o Agile Tester. Vamos entender quais as suas atribuições e de que forma é possível evoluir em sinergia com o desenvolvimento das demais técnicas e metodologias ágeis de trabalho e gestão. 

O que é Agile Testing?

Agile Testing é a prática de testagem de softwares segundo os princípios do Manifesto Ágil do Teste. Estas orientações guiam a estruturação dos sprints e auxiliam na identificação rápida de desvios, bem como o seu encaminhamento aos setores responsáveis pelo aprimoramento dos produtos. 

Os 5 princípios do Manifesto do Agile Testing são: 

  • Testar continuamente mais que testar no final;
  • Prevenir defeitos mais que encontrar defeitos;
  • Entender o teste mais que verificar a funcionalidade;
  • Construir o melhor sistema mais que quebrar o sistema;
  • Time responsável pela qualidade mais que responsabilidade do testador.

< Saiba mais em: Manifesto Ágil: veja como ele surgiu e conheça seus 12 princípios />

Do planejamento à adaptabilidade: a importância de seguir o processo evolutivo

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.

Dessa forma, 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 exemplo disso foi o Iridium, da Motorola. Trata-se de um projeto de bilhões de dólares que criou um telefone por satélite por meio do qual seria possível se comunicar em qualquer lugar do mundo. 

Esse projeto foi aclamado pelo PMI (Project Management Institute, instituição de referência na gestão de projetos) como um dos mais bem planejados da época, que conseguiu ser concluído no prazo, escopo e custo conforme o planejado. 

Porém, o resultado foi um fracasso. E, por incrível que pareça, o principal motivo para o fracasso foi o 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.

Como o testador na metodologia ágil pode colocar a reação a mudanças em prática?

Muitas pessoas pensam, erroneamente, que a palavra “Ágil” da abordagem ágil é sinônimo de velocidade. Na verdade, ágil, aqui, significa “capacidade de reação”. Ou seja, é a capacidade de romper a inércia, 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. Isso significa que toda 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 Agile Tester

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

Por exemplo, a implementação do código é feita de forma ágil, com kanban, painéis de acompanhamento Scrum e stand-up meetings diários em conjunto com o cliente. Tudo acontece 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 (nome dado a uma sequência de ações e instruções realizadas repetidamente). Erros aparecem mesmo em funcionalidades desenvolvidas há vários sprints (etapas de desenvolvimento) atrás. É possível, inclusive, que estes desvios inviabilizem sprints seguintes, trazendo atrasos para o projeto. Por isso, não devem existir duas equipes separadas operando individualmente, e sim, um time unificado e sinérgico.

Apesar disso, mesmo em ambientes que trabalham com uma única equipe, há questionamentos para entender se, em uma equipe ágil pequena, deve haver um profissional exclusivo para testes. 

A verdade é que não há consenso. O Scrum, por exemplo, defende que o time de desenvolvimento reúna todas as habilidades necessárias, incluindo as relacionadas ao agile testing.

Porém, especialistas da área, como Glenford Myers, defendem que é preciso contar com um especialista em Testes que tenha foco somente nisso, para que não aconteça o problema da visão viciada. 

Entretanto, mesmo com a presença de um especialista, algumas atividades podem ser executadas pelo resto da equipe, como planejamento e gestão da qualidade, estimativas, elaboração de relatórios e dashboards.

Comunicação ativa e antecipação dos feedbacks: entenda como equilibrar

Quanto mais tarde acontece o agile testing, mais problemas aparecem e menor é 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 eles forem executados, mais rápido será o feedback junto ao Product Owner. Consequentemente, mais veloz será a execução das medidas cabíveis para a solução dos problemas.

Mas cuidado com a ideia de “antecipação”! Isso porque, quando realizados de forma precoce, os testes também podem trazer diversos prejuízos se não forem feitos adequadamente. 

Alguns dos erros comuns relacionados a esta precipitação são:

  • executar testes em funcionalidades que ainda estão sendo alteradas;
  • verificar requisitos errados;
  • não alinhar todo o time envolvido sobre a etapa de testes. 

A verdade é que, em geral, os testadores ágeis não dispõem de grande documentação de requisitos como base para casos de teste ágil. 

Por isso, eles se apoiam fortemente na comunicação, que pode ser verbal, escrita ou virtual, para assimilar a informação de 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, é fundamental haver o equilíbrio entre os dois fatores-chave: 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 relatórios complexos sobre o andamento da verificação da qualidade. 

E, para executar essa árdua tarefa, mais uma vez, exige-se as capacidades de automação e comunicação.

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 e 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

Com a evolução do processo de desenvolvimento, o Agile Tester ganhou novas responsabilidades. E uma delas é contribuir com estimativas. 

Para isso, o Testador Ágil deve ter noções de métricas de tamanho de software, bem como informações históricas do esforço gasto nas funcionalidades passadas. Assim, ele pode ajudar na previsibilidade de esforço da seguinte forma:

1- 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.

2- Fornecendo uma previsão do que pode ser automatizado

O Testador Ágil deve indicar quais requisitos podem ser automatizados. Como testes automatizados são mais baratos e mais eficientes, eles devem ser priorizados. Nesse sentido, saber avaliar corretamente quais deles podem ser automatizados resulta 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.

3- Estimando o que não deveria ser automatizado

Complementando o item anterior, o Testador Ágil deve estimar quais funcionalidades não precisam de automatização. De forma geral, não se usa automação nos seguintes casos:

  • Funcionalidades instáveis;
  • Funcionalidades pouco usadas;
  • Funcionalidades que exigem inspeção visual.

Torne-se um Agile Tester com a ajuda da XP Educação!

Colocar em prática os 5 princípios do Manifesto Ágil de testes é uma boa forma de sentir, na prática, o fluxo do trabalho de melhoria contínua. 

Entretanto, que tal se preparar para mergulhar de cabeça no mundo do desenvolvimento com uma excelente base teórica? 

Nossa sugestão é o bootcamp online Engenharia de Software Ágil. Neste intensivo, você aprende todos os princípios das metodologias mais efetivas e modernas no mercado, como o Scrum, XP e Kanban para ser um(a) Engenheiro(a) de Software focado na metodologia Ágil. 

Atue com sucesso na área e veja sua carreira decolar!

Assine agora e comece a aprender! 

Professor autor: Marcelino Campos

*Créditos da imagem de capa: Christina @ wocintechchat.com em Unsplash

spot_img

Continue Aprendendo

spot_img