Um caminho para melhores testes ágeis

O World Quality Report anual criado pela Capgemini mostra que 42% dos entrevistados listam a “falta de experiência profissional em testes” como um desafio na aplicação de testes ao desenvolvimento ágil. Embora o advento do Agile tenha trazido o aumento da velocidade das iterações para o desenvolvimento de software, em alguns casos, isso veio à custa da qualidade.

A competição acirrada está pressionando as equipes a entregar constantemente novas atualizações de produtos, mas isso às vezes vem com seu próprio custo, incluindo menor atenção aos testes. Alguns, como Rob Mason, vão ainda mais longe e argumentam que o Agile está matando os testes de software. Recentemente, o Facebook mudou seu lema de “mova-se rápido e quebre coisas” para “mova-se rápido com infraestrutura estável” em uma tentativa de resolver as tentações de sacrificar a qualidade.

Então, como os testes podem ser melhor integrados ao novo mundo do desenvolvimento de software Agile? Testes ágeis.

O teste tradicional é bastante complicado e depende de muita documentação. O teste ágil é uma abordagem ao processo de teste que imita os princípios do desenvolvimento de software ágil, em que:

• O teste é feito com muito mais frequência,
• O teste depende menos da documentação e mais da colaboração dos membros da equipe, e
• Algumas atividades de teste são realizadas não apenas por testadores, mas também por desenvolvedores.

Nos últimos sete anos, fiz a transição de muitas equipes para testes Agile e trabalhei lado a lado com testadores para ajudar seus processos a se adequarem à nova metodologia. Neste artigo, compartilharei algumas das dicas mais impactantes que aprendi ao longo do meu caminho para melhorar os testes ágeis. Embora seja natural haver atrito entre velocidade e qualidade nas práticas ágeis, este artigo abordará algumas técnicas que podem ser usadas para aumentar a qualidade dos testes sem comprometer a agilidade. A maioria das sugestões descritas aqui exigirá o envolvimento da equipe, portanto, será benéfico ter desenvolvedores e testadores participando do planejamento.

Formalize um processo de ciclo de teste de lançamento

Um problema com o teste é a ausência do ciclo de teste de lançamento, nenhum cronograma de lançamento ou solicitações de teste irregulares. As solicitações de teste sob demanda dificultam o processo de controle de qualidade, especialmente se os testadores estiverem lidando com vários projetos.

Muitas equipes fazem apenas uma única compilação após cada sprint, o que não é ideal para projetos ágeis. Mudar para versões uma vez por semana pode ser benéfico, fazendo a transição gradual para várias compilações por semana. Idealmente, as compilações e testes de desenvolvimento devem acontecer diariamente, o que significa que os desenvolvedores enviam o código para o repositório todos os dias e as compilações são programadas para serem executadas em um horário específico. Para dar um passo adiante, os desenvolvedores poderiam implantar um novo código sob demanda. Para implementar isso, as equipes podem empregar um processo de integração contínua e implantação contínua (CI/CD). CI/CD limita a possibilidade de uma compilação com falha no dia de uma versão principal.

Quando CI/CD e automação de teste são combinados, a detecção precoce de bugs críticos é possível, permitindo que os desenvolvedores tenham tempo suficiente para corrigir bugs críticos antes do lançamento agendado do cliente. Um dos princípios do Agile afirma que o software funcionando é a principal medida de progresso. Nesse contexto, um ciclo de lançamento formalizado torna o processo de teste mais ágil.

Capacite testadores com ferramentas de implantação

Um dos pontos de atrito comuns para teste é ter o código implantado em um ambiente de teste. Esse processo depende da infraestrutura técnica que sua equipe pode não conseguir afetar. No entanto, se houver alguma flexibilidade, as ferramentas podem ser criadas para pessoas não técnicas, como testadores ou gerentes de projeto, que permitiriam que eles implementassem a base de código atualizada para testar a si mesmos.

Por exemplo, em uma das minhas equipes, usamos Git para controle de versão e Slack para comunicação. Os desenvolvedores criaram um Slackbot que tinha acesso ao Git, scripts de implantação e uma máquina virtual. Os testadores conseguiram fazer ping no bot com um nome de branch adquirido do GitHub ou Jira e implantá-lo em um ambiente de teste.

Essa configuração liberou muito tempo para os desenvolvedores, reduzindo o desperdício de comunicação e as interrupções constantes quando os testadores precisavam pedir aos desenvolvedores para implantar uma ramificação para teste.

Experimente com TDD e ATDD

O desenvolvimento orientado a testes (TDD) é um tipo de processo de desenvolvimento de software que coloca muita ênfase na qualidade. Tradicionalmente, um desenvolvedor escreve o código e, em seguida, alguém o testa e relata se algum bug foi encontrado. No TDD, os desenvolvedores escrevem testes de unidade antes mesmo de escrever qualquer código que complete uma história de usuário. Os testes inicialmente falham até que o desenvolvedor escreva a quantidade mínima de código para passar nos testes. Depois disso, o código é refatorado para atender aos requisitos de qualidade da equipe.

O desenvolvimento orientado a testes de aceitação (ATDD) segue uma lógica semelhante ao TDD, mas, como o nome indica, concentra-se nos testes de aceitação. Nesse caso, os testes de aceitação são criados antes do desenvolvimento em colaboração com desenvolvedores, testadores e solicitantes (cliente, proprietário do produto, analista de negócios etc.). Esses testes ajudam todos na equipe a entender os requisitos do cliente antes que qualquer código seja escrito.

Técnicas como TDD e ATDD tornam os testes mais ágeis, movendo os procedimentos de teste para os estágios iniciais do ciclo de vida de desenvolvimento. Ao escrever cenários de teste desde o início, os desenvolvedores precisam entender muito bem os requisitos. Isso minimiza a criação desnecessária de código e também resolve quaisquer incertezas do produto no início do ciclo de desenvolvimento. Quando questões ou conflitos sobre o produto surgem apenas nos estágios posteriores, o tempo de desenvolvimento e os custos aumentam.

Descubra ineficiências rastreando o movimento do cartão de tarefas

Em uma das minhas equipes, tínhamos um desenvolvedor extremamente rápido, principalmente com recursos pequenos. Ele recebia muitos comentários durante a revisão de código, mas nosso Scrum master e eu descartamos isso como falta de experiência. No entanto, à medida que ele começou a codificar recursos mais complexos, os problemas se tornaram mais aparentes. Ele havia desenvolvido um padrão de passagem de código para teste antes que estivesse totalmente pronto. Esse padrão geralmente se desenvolve quando há falta de transparência no processo de desenvolvimento – por exemplo, não está claro quanto tempo diferentes pessoas gastam em uma determinada tarefa.

Às vezes, os desenvolvedores apressam seu trabalho na tentativa de lançar recursos o mais rápido possível e “terceirizar” a qualidade para os testadores. Essa configuração apenas move o gargalo mais para baixo no sprint. A garantia de qualidade (QA) é a rede de segurança mais importante que a equipe tem, mas isso pode significar que a existência de QA dá aos desenvolvedores a capacidade de renunciar a considerações de qualidade.

Muitas ferramentas modernas de gerenciamento de projetos têm recursos para rastrear o movimento de cartões de tarefas em um quadro Scrum ou Kanban. No nosso caso, usamos o Jira para analisar o que aconteceu com as tarefas do desenvolvedor em questão e fizemos comparações com outros desenvolvedores da equipe. Descobrimos que:

• Suas tarefas gastaram quase o dobro do tempo na coluna de testes do nosso conselho;
• Suas tarefas seriam devolvidas com muito mais frequência do controle de qualidade para uma segunda ou terceira rodada de consertos.

Portanto, além de os testadores terem que gastar mais tempo em suas tarefas, eles também tiveram que fazer isso várias vezes. Nosso processo opaco fez parecer que o desenvolvedor foi muito rápido; no entanto, isso provou ser falso quando levamos em conta o tempo de teste. Mover histórias de usuários para frente e para trás obviamente não é uma abordagem enxuta.

Para resolver isso, começamos tendo uma discussão honesta com esse desenvolvedor. No nosso caso, ele simplesmente não estava ciente de quão prejudicial era seu padrão de trabalho. Foi assim que ele se acostumou a trabalhar em sua empresa anterior, que tinha requisitos de qualidade mais baixos e um pool de testadores maior. Após nossa conversa e com a ajuda de algumas sessões de programação em pares com nosso Scrum master, ele gradualmente fez a transição para uma abordagem de desenvolvimento de maior qualidade. Devido às suas habilidades de codificação rápida, ele ainda tinha um alto desempenho, mas o “desperdício” removido do processo de controle de qualidade tornou todo o processo de teste muito mais ágil.

Adicionar automação de teste ao conjunto de habilidades da equipe de controle de qualidade

O teste em projetos não ágeis envolve atividades como análise de teste, design de teste e execução de teste. Essas atividades são sequenciais e requerem extensa documentação. Quando uma empresa faz a transição para o Agile, na maioria das vezes, a transição se concentra principalmente nos desenvolvedores e não tanto nos testadores. Eles param de criar documentação extensa (um pilar dos testes tradicionais), mas continuam a realizar testes manuais. No entanto, o teste manual é lento e normalmente não consegue lidar com os ciclos de feedback rápidos do Agile.

A automação de teste é uma solução popular para esse problema. Os testes automatizados facilitam muito o teste de recursos novos e pequenos, pois o código de teste pode ser executado em segundo plano enquanto desenvolvedores e testadores se concentram em outras tarefas. Além disso, como os testes são executados automaticamente, a cobertura do teste pode ser muito maior em comparação com os esforços de teste manual.

Testes automatizados são pedaços de código de software semelhantes à base de código que está sendo testada. Isso significa que as pessoas que escrevem testes automatizados precisarão de habilidades técnicas para serem bem-sucedidas. Existem muitas variações diferentes de como o teste automatizado é implementado em diferentes equipes. Às vezes, os próprios desenvolvedores assumem o papel de testadores e aumentam a base de código de teste a cada novo recurso. Em outras equipes, os testadores manuais aprendem a usar ferramentas de automação de teste ou um testador técnico experiente é contratado para automatizar o processo de teste. Qualquer que seja o caminho que a equipe tome, a automação leva a testes muito mais ágeis.

Gerenciar prioridades de teste

Com o desenvolvimento de software não ágil, os testadores geralmente são alocados por projeto. No entanto, com o advento do Agile e do Scrum, tornou-se comum que os mesmos profissionais de QA operem em vários projetos. Essa responsabilidade sobreposta pode criar conflitos nos cronogramas e levar os testadores a perderem cerimônias críticas quando um testador prioriza o teste de lançamento de uma equipe sobre a sessão de planejamento do sprint de outra.

A razão pela qual os testadores às vezes trabalham em vários projetos é óbvia – raramente há um fluxo constante de tarefas para testes para preencher uma função em tempo integral. Portanto, pode ser difícil convencer as partes interessadas a ter um recurso de teste dedicado alocado para uma equipe. No entanto, existem algumas tarefas razoáveis ​​que um testador pode realizar para preencher seu tempo de inatividade quando não estiver envolvido em atividades de teste.

Suporte ao cliente

Uma configuração possível é fazer com que o testador passe o tempo de inatividade do sprint ajudando a equipe de suporte ao cliente. Ao enfrentar constantemente os problemas que os clientes têm, o testador tem uma melhor compreensão da experiência do usuário e como melhorá-la. Eles são capazes de contribuir para as discussões durante as sessões de planejamento. Além disso, eles ficam mais atentos durante suas atividades de teste, pois estão mais familiarizados com a forma como os clientes realmente usam seu software.

Gestão de produtos

Outra técnica para gerenciar as prioridades dos testadores é essencialmente torná-los gerentes de produto juniores que realizam testes manuais. Essa também é uma solução viável para preencher o tempo de folga de um testador porque os gerentes de produto juniores gastam muito tempo criando requisitos para as histórias do usuário e, portanto, têm conhecimento profundo da maioria das tarefas.

Automação de teste

Como discutimos anteriormente, o teste manual geralmente é inferior à automação. Nesse contexto, o impulso para a automação pode ser associado a um testador dedicar toda a atenção à equipe e utilizar seu tempo livre para aprender a trabalhar com ferramentas de automação de teste como o Selenium.

Resumo: Testes Ágeis de Qualidade

Tornar os testes mais ágeis é uma inevitabilidade que muitas equipes de desenvolvimento de software estão enfrentando agora. No entanto, a qualidade não deve ser comprometida pela adoção de uma mentalidade de “teste o mais rápido possível”. É imperativo que uma transição Agile inclua uma mudança para o teste Agile, e existem algumas maneiras de conseguir isso:

• Formalize um processo de ciclo de teste de lançamento.
• Capacite os testadores com ferramentas de implantação.
• Experimente o desenvolvimento orientado a testes e o desenvolvimento orientado a testes de aceitação.
• Descubra ineficiências rastreando o movimento do cartão de tarefas.
• Adicione automação de teste ao conjunto de habilidades da equipe de controle de qualidade.
• Gerencie as prioridades do testador.

A cada ano, o software está melhorando e as expectativas dos usuários estão aumentando. Além disso, à medida que os clientes se acostumam com produtos de alta qualidade das principais marcas de software, como Google, Apple e Facebook, essas expectativas também são transferidas para outros produtos de software. Assim, é provável que a ênfase na qualidade seja ainda mais importante nos próximos anos. Esses testes e melhorias no processo de desenvolvimento geral podem tornar os testes mais ágeis e garantir um alto nível de qualidade do produto.