O anual Relatório de Qualidade Mundial 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 Agile. Enquanto o advento de Ágil trouxe 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 tem seu próprio custo, incluindo atenção reduzida aos testes. Alguns, como Rob Mason, vão ainda mais longe e argumentam que Agile está acabando com os testes de software . Recentemente, o Facebook mudou seu lema de “mova-se rápido e quebre as 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 o teste pode ser melhor integrado ao novo mundo do desenvolvimento de software Agile? Teste ágil.
O teste tradicional é bastante complicado e depende de muita documentação. O teste Agile é uma abordagem para o processo de teste que imita os princípios do desenvolvimento de software Agile, pelo qual:
Nos últimos sete anos, fiz a transição de muitas equipes para o teste Agile e trabalhei lado a lado com os testadores para ajudar seus processos a se adequarem à nova metodologia. Neste artigo, vou compartilhar algumas das dicas mais impactantes que aprendi ao longo do meu caminho para melhores testes Agile. Embora seja natural haver atrito entre velocidade e qualidade nas práticas Agile, este artigo abordará algumas técnicas que podem ser usadas para aumentar a qualidade do teste sem comprometer a agilidade. A maioria das sugestões descritas aqui exigirá o envolvimento da equipe, portanto, será benéfico ter os desenvolvedores e testadores participando do planejamento.
Um problema com o teste é a ausência do ciclo de teste de lançamento, nenhuma programação de lançamento ou solicitações de teste irregulares. As solicitações de teste sob demanda tornam o processo de QA difícil, especialmente se os testadores estiverem lidando com vários projetos.
Muitas equipes fazem apenas uma única construção após cada sprint, o que não é ideal para projetos Agile. Mudar para lançamentos uma vez por semana pode ser benéfico, fazendo a transição gradual para várias compilações por semana. O ideal é que as compilações e os testes de desenvolvimento ocorram 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 seriam capazes de implantar um novo código sob demanda. Para implementar isso, as equipes podem empregar um processo de integração e implantação contínuas (CI / CD). CI / CD limita a possibilidade de uma construção com falha no dia de um lançamento 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 os bugs críticos antes do lançamento programado do cliente. Um dos princípios do Agile afirma que o software funcional é a principal medida de progresso. Nesse contexto, um ciclo de lançamento formalizado torna o processo de teste mais ágil.
Um dos pontos de atrito comuns para o teste é ter o código implantado em um ambiente de preparação. Este processo depende da infraestrutura técnica que sua equipe pode não ser capaz de 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 lhes permitiriam implementar a base de código atualizada para testar a si mesmos.
Por exemplo, em uma de 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 executar 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, ao mesmo tempo que reduziu o desperdício de comunicação e as interrupções constantes quando os testadores tiveram que pedir aos desenvolvedores para implantar um branch para teste.
Desenvolvimento orientado a testes (TDD) é um tipo de processo de desenvolvimento de software que coloca muita ênfase na qualidade. Tradicionalmente, um desenvolvedor escreve código e então alguém o testa e relata se algum bug foi encontrado. No TDD, os desenvolvedores escrevem testes de unidade primeiro, antes mesmo de escrever qualquer código que completaria 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.
Desenvolvimento orientado para teste de aceitação (ATDD) segue uma lógica semelhante ao TDD, mas, como o nome indica, concentra-se em testes de aceitação. Nesse caso, os testes de aceitação são criados antes do desenvolvimento em colaboração com desenvolvedores, testadores e solicitadores (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 os requisitos muito bem. 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 as questões ou conflitos do produto surgem apenas nos estágios posteriores, o tempo de desenvolvimento e os custos aumentam.
Em uma de minhas equipes, tínhamos um desenvolvedor extremamente rápido, especialmente com pequenos recursos. Ele receberia muitos comentários durante a revisão do código, mas nosso Scrum master e eu descartamos isso como falta de experiência. No entanto, conforme ele começou a codificar recursos mais complexos, os problemas se tornaram mais aparentes. Ele desenvolveu um padrão de passagem de código para teste antes de estar totalmente pronto. Esse padrão normalmente 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 liberar recursos o mais rápido possível e “terceirizar” a qualidade para os testadores. Essa configuração apenas move o gargalo mais adiante na sprint. A garantia de qualidade (QA) é a rede de segurança mais importante que a equipe possui, mas isso pode significar que a existência de QA dá aos desenvolvedores a capacidade de renunciar a considerações de qualidade.
Muitos modernos ferramentas de gerenciamento de projeto têm os recursos para rastrear o movimento dos 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:
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 era muito rápido; no entanto, isso provou ser falso quando levamos em consideração o tempo de teste. Mover histórias de usuário para frente e para trás obviamente não é uma abordagem enxuta.
Para resolver isso, começamos tendo uma discussão honesta com este desenvolvedor. Em nosso caso, ele simplesmente não estava ciente de como seu padrão de trabalho era prejudicial. Foi apenas a maneira como 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ápidas, ele ainda tinha um alto desempenho, mas o “desperdício” removido do processo de QA tornou todo o processo de teste muito mais ágil.
O teste em projetos não Agile envolve atividades como análise de teste, design de teste e execução de teste. Essas atividades são sequenciais e requerem ampla 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 tornam muito mais fácil testar recursos novos e pequenos, pois o código de teste pode ser executado em segundo plano enquanto os 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.
Os 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 ter sucesso. 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.
Com o desenvolvimento de software não Agile, 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 operassem em vários projetos. Esta responsabilidade sobreposta pode criar conflitos nos cronogramas e fazer com que os testadores percam cerimônias críticas quando um testador prioriza o teste de liberação de uma equipe sobre a sessão de planejamento de 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 de teste para preencher uma função de 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.
Uma configuração possível é fazer com que o testador gaste o tempo de inatividade do sprint ajudando a equipe de suporte ao cliente. Ao enfrentar constantemente os problemas dos clientes, o testador compreende melhor a experiência do usuário e como melhorá-la. Eles são capazes de contribuir com 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.
Outra técnica para gerenciar as prioridades do testador é 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 do testador, porque os gerentes de produto juniores passam muito tempo criando requisitos para as histórias de usuário e, portanto, têm conhecimento íntimo da maioria das tarefas.
Como discutimos anteriormente, o teste manual geralmente é inferior à automação. Neste contexto, o impulso para a automação pode ser acoplado a um testador dedicar sua atenção total à equipe e utilizar seu tempo livre para aprender a trabalhar com ferramentas de automação de teste, como Selênio .
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 do Agile inclua uma mudança para os testes do Agile, e existem algumas maneiras de conseguir isso:
A cada ano, o software está melhorando e as expectativas dos usuários aumentam. Além disso, conforme os clientes se acostumam com produtos de alta qualidade das principais marcas de software, como Google, Apple e Facebook, essas expectativas também se transferem para outros produtos de software. Portanto, é provável que a ênfase na qualidade seja ainda mais importante nos próximos anos. Essas melhorias no processo de teste e desenvolvimento geral podem tornar o teste mais ágil e garantir um alto nível de qualidade do produto.
Existem alguns níveis de teste que podem ser usados no Agile: unidade, integração, sistema e aceitação.
O teste ágil é uma transição de procedimentos de teste em cascata altamente documentados para testes mais flexíveis e responsivos. O teste ágil envolve o desenvolvimento ágil de software para apoiar a equipe ágil na entrega de pequenos incrementos de produto em prazos mais curtos.
Um plano de teste pode ser usado no Agile, mas deve ser um guia geral e não um documento rígido e imutável que leva muito tempo para ser criado. Agile promove software funcional em vez de documentação abrangente.
Uma estratégia de teste ágil deve definir como o software é testado na equipe ágil.