Testes ágeis: quais as maneiras de testar em uma equipe ágil?

Nos últimos anos, uma nova maneira de criar software tomou conta do mundo de desenvolvimento e teste de software: a metodologia ágil. De acordo com o Relatório State of Agile da VersionOne, 97% das organizações praticam o Agile. No entanto, entrevistados relatam que essa adoção nem sempre é generalizada em suas organizações, o que significa que ainda há um longo caminho a percorrer. Neste artigo, vamos abordar os testes ágeis: como se encaixam na metodologia ágil e quais as maneiras de testar uma equipe ágil.

O que significa testar em uma equipe ágil?

Os princípios ágeis dizem respeito a uma postura colaborativa, flexível e adaptável. Isso porque têm como premissa o fato de que o mundo, agora, muda regularmente, o que significa que as equipes de software não têm mais anos para lançar novos produtos no mercado.

Nesse período, as ofertas dos concorrentes, assim como as expectativas dos clientes podem mudar e a equipe corre o risco de irrelevância. É ai que o Agile atua: minimiza esse risco enquanto ajuda as equipes a colaborarem mais e se adapta ao que ela precisa para ter sucesso.

Isso é feito através do incentivo às equipes a mostrar regularmente seu trabalho e obter feedback, para que possam se adaptar rapidamente às mudanças.

Ágil não é tamanho único

Toda organização é única e enfrenta diferentes fatores internos e externos. Para ajudar a atender às diversas necessidades de diferentes organizações, existem várias metodologias ágeis e vários tipos diferentes de testes que você pode realizar. A combinação certa para sua equipe dependerá de fatores, necessidades e objetivos internos e externos. Seguem metodologias ágeis e métodos de teste mais populares:

Metodologias ágeis

1) Scrum

O Scrum adota uma abordagem altamente iterativa que se concentra na definição dos principais recursos e objetivos antes de cada sprint. Foi projetado para reduzir riscos e fornecer valor rapidamente.

A metodologia começa com um requisito ou uma história do usuário que descreve como os recursos devem ser executados e testados. A equipe então percorre uma série de sprints para fornecer pequenas rajadas de valor rapidamente. Para ajudar a equipe a trabalhar dessa maneira flexível e evitar mudanças de prioridades, o Scrum exige que as perguntas sejam respondidas desde o início.

Ele exige uma colaboração mais regular entre testadores, desenvolvedores e BAs, geralmente na forma de standups diários e retrospectivas de sprint, para garantir a comunicação e o alinhamento adequados. Além disso, existe um Scrum Master que ajuda a manter o projeto na tarefa removendo os bloqueadores da equipe para garantir maior eficácia.

Por fim, oferece uma das transições mais fáceis para as equipes provenientes de um ambiente Waterfall, pois o tempo com sprints e lançamentos ainda pode ser planejado com antecedência. Dito isto, exige iterações mais rápidas e colaboração mais forte.

2) Kanban

É uma metodologia muito simples e baseada na fabricação. O Kanban pode ser considerado uma grande lista de tarefas com prioridade. Assim como no Scrum, seus requisitos são rastreados pelo estágio atual do processo (tarefas, desenvolvimento, teste e execução).

O Kanban não é baseado em tempo, mas unicamente em prioridade. Quando um desenvolvedor está pronto para a próxima tarefa, ele a puxa da lista de tarefas e como há menos reuniões de planejamento, essa abordagem requer que a equipe precisa esteja extremamente próxima.

Para fazer uma transição suave para o Kanban, analistas de negócios, desenvolvedores, testadores e demais partes interessadas devem sentar-se juntos e se comunicar regularmente. Ao fazer essa transição, é importante lembrar que a metodologia oferece a maneira mais rápida de trazer código à produção, mas é provável que o código tenha alguma dívida técnica. Isso ocorre porque o desenvolvimento que não atualiza constantemente o que vem a seguir, não se presta necessariamente à produção do código mais reutilizável.

É mais adequado para equipes pequenas ou equipes que não produzem recursos para o público nem prometem determinadas datas para lançamentos. Além disso, é uma metodologia de primeira escolha para qualquer produto ou equipe focada principalmente no trabalho de manutenção, pois os bugs nem sempre são diretos e geralmente exigem pesquisa para serem resolvidos.

Métodos de teste

Desenvolvimento orientado a comportamentos (BDD)

O BDD exige testes de nível superior no nível comercial. Em vez de começar com um teste de unidade voltado para a técnica, o método começa com um requisito inicial baseado no comportamento do usuário final e exige testes que sejam “legíveis por humanos”, os quais podem até substituir algumas documentações de requisitos.

Principiando por uma especificação funcional usando a sintaxe Gherkin: Given/When/Then, o teste orienta os desenvolvedores, testadores e proprietários de produtos que se movem pelos recursos. Usa-se também funções de teste automatizadas para determinar a integridade, refinando o código até que ele passe no teste, exceto no nível da equipe.

Para garantir que o teste seja aprovado, o desenvolvedor deve refatorar apenas o código e não adicionar nenhuma nova funcionalidade. Esse funcionamento requer uma estratégia de automação "inteligente" que gere um alto nível de eficiência.

Mudar para uma metodologia BDD pode ser desafiador quando a equipe está acostumada a um estilo tradicional de testes, pois exige que um BA ou testador escreva testes antecipadamente e que os desenvolvedores escrevam a especificação do teste no código correspondente.

É um novo tipo de coordenação dentro da equipe, mas é extremamente positivo, pois a equipe trabalha em conjunto como uma unidade, incluindo os usuários de negócios.

Desenvolvimento orientado a testes de aceitação (ATDD)

O ATDD é como o BDD, pois exige que os testes sejam criados anteriormente e que o código seja gravado para passar nesses testes. No entanto, no ATDD os testes são tipicamente de aceitação, voltados para o cliente.

A ideia por trás do ATDD é que a percepção do produto pelo usuário é tão importante quanto sua funcionalidade; essa perspectiva deve impulsionar o desempenho do produto para ajudar a aumentar a adoção. Para dar vida a essa ideia, deve-se coletar informações dos clientes, utilizá-las para desenvolver critérios de aceitação, converter esses critérios em testes de aceitação manuais ou automáticos e finalmente desenvolver o código nesses testes. Trata-se, antes, de uma metodologia de testes, não um processo orientado a requisitos.

Ajuda a eliminar áreas de mal-entendidos em potencial, retirando a necessidade de os desenvolvedores interpretarem como o produto será usado. O ATDD vai um passo além do TDD e do BDD, porque atinge diretamente a fonte (cliente) para entender como o produto será usado. Essa conexão direta deve ajudar a minimizar a necessidade de redesenhar recursos em novos lançamentos.

Como o ATDD representa um afastamento dos métodos tradicionais, não é fácil passar de uma equipe para outra. Para estar na melhor posição para adotar uma metodologia ATDD, as equipes precisam obter a adesão das partes interessadas, o que às vezes pode ser um desafio.

Teste exploratório

O teste exploratório fornece aos testadores a propriedade do código para testá-lo de uma maneira organizada. Nesse caso, os testadores não seguem as etapas do teste, mas usam o software de maneiras padrão ou inteligentes para tentar quebrá-lo.

É possível documentar os defeitos normalmente, mas nem sempre é fornecida documentação detalhada sobre o que e como o aplicativo foi testado.

Trata-se de desenvolver os melhores testes com base em cada peça de software exclusiva. Devido à sua abordagem sem script, os testes exploratórios geralmente imitam como os usuários potencialmente irão interagir com o software na vida real. No geral, seguem-se quatro princípios-chave:

Planejamento de teste paralelo, design e execução de teste;

Específico, porém flexível;

Alinhado à investigação de oportunidades potenciais;

Compartilhamento de conhecimento.

Adotar o teste exploratório é relativamente fácil, pois é rápido de implantar, simples de aprender e fornece benefícios para toda a equipe. Os testes exploratórios podem ajudar a reduzir o tempo gasto nos testes, encontrar mais defeitos e melhorar a cobertura do código.

Dessa forma, adéqua-se melhor às equipes com restrições de tempo, às que precisam de ajuda para identificar os melhores tipos de testes a serem executados e às equipes que desejam garantir que nada se perda dos testes anteriores.

Teste baseado em sessão

O Teste Baseado em Sessão se inspira no teste exploratório, mas fornecendo mais estrutura. Tem como objetivo facilitar em algumas deficiências, dando mais corpo ao teste exploratório sem tirar os benefícios que este oferece, como a capacidade de imitar melhor a experiência do usuário e ser criativo com o teste.

Esse teste se dá em sessões ininterruptas com intervalo de tempo, testes contra uma carta e exige que os testadores relatem os testes que ocorreram durante cada sessão. Além disso, o teste com base na sessão deve ser encerrado com um "questionário" entre o(s) testador(es) e o gerente que cobre os cinco pontos da PROVA.

A adoção desses testes é relativamente fácil. Para os testadores, o maior obstáculo é adotar a estrutura adicional para a qual os testes baseados em sessão chamam. As equipes que executam testes baseados em sessões devem lembrar que não se trata de uma parada final, mas um método para ajudar a determinar o melhor tipo de teste a ser realizado a seguir.