Como executar agentes de garantia de qualidade em todos os pedidos de alteração com a QA.tech (sem escrever um único guião de testes)

Se a sua equipa adotou ferramentas de programação com IA, já conhece a matemática desconfortável. As equipas de engenharia que entregavam alguns pedidos de integração por semana estão agora a entregar cinquenta, cem, por vezes mais – grande parte escritos por agentes de programação, revistos por agentes de revisão de código e integrados a um ritmo para o qual nenhum processo de garantia de qualidade manual foi concebido. Uma equipa com quem falámos recentemente tinha acabado de concluir os seus primeiros cinquenta pedidos de integração escritos inteiramente por agentes e fez-nos a pergunta óbvia: o que verifica tudo isto?

A resposta tradicional – escrever mais scripts de teste – não resiste ao contacto com esse volume de pedidos de integração. Os scripts demoram mais tempo a criar e a manter do que o código escrito por agentes demora a produzir, pelo que a coleção de testes fica para trás logo no primeiro dia e nunca consegue recuperar.

Este guia explica a alternativa que criámos na QA.tech: ligar os nossos agentes de garantia de qualidade ao seu repositório para que cada pedido de integração desencadeie testes baseados em objetivos, derivados automaticamente daquilo que foi alterado. Sem código de teste, sem seletores, sem fila de manutenção. Eis como configurar tudo e o que esperar em cada etapa.

Passo 1: deixe o agente aprender primeiro a sua aplicação

Antes de a integração com os pedidos de integração fazer algo de útil, o agente precisa de conhecer o seu produto. Quando liga a QA.tech ao seu ambiente de pré-produção ou de testes isolado, esta executa uma exploração inicial: percorre a aplicação da forma como um novo colaborador meticuloso o faria, seguindo todos os caminhos e ações que consegue encontrar, e reúne essa informação num grafo de conhecimento sobre a estrutura do seu produto.

Duas notas práticas resultantes de centenas de processos de integração. Primeiro, se a sua aplicação estiver protegida por início de sessão, configure o fluxo de início de sessão como um caso de teste pré-requisito – o agente conclui-o primeiro e, em seguida, explora tudo o que está por detrás dele. Segundo, é você quem controla a profundidade da exploração. Uma exploração superficial (com um ou dois passos de profundidade em cada percurso do utilizador) é rápida e, normalmente, suficiente para começar; pode aprofundá-la nos fluxos mais importantes, em vez de mapear exaustivamente tudo logo à partida.

Esta etapa é a razão de ser da integração com os pedidos de integração. Como o agente conhece todos os recantos da aplicação, consegue raciocinar sobre o que uma determinada alteração poderá afetar – exatamente o discernimento que um bom engenheiro de garantia de qualidade aplica ao decidir o que deve verificar antes de uma disponibilização.

Passo 2: ligue o repositório

A integração com o GitHub demora minutos: autorize a aplicação, selecione os repositórios e escolha quando os testes devem ser executados – normalmente, aquando da criação ou atualização de um pedido de integração. Os pedidos de integração do GitLab seguem o mesmo padrão. A partir deste momento, os testes fazem parte do seu fluxo de integração e entrega, em vez de serem uma etapa que ocorre depois deste.

Passo 3: abra um pedido de integração e veja o que acontece

Quando é aberto um pedido de integração, o agente lê o que foi adicionado e alterado, cruza essa informação com o seu grafo de conhecimento e gera os casos de teste justificados pela alteração – normalmente quatro ou cinco para um pedido de integração rotineiro, e mais para alterações que afetam fluxos partilhados. Em seguida, executa-os imediatamente num navegador real, interagindo visualmente com a compilação atualizada, exatamente como um utilizador faria.

Esta é a parte que surpreende as equipas habituadas a coleções de scripts desencadeadas pela integração contínua: ninguém criou esses casos de teste. Foram derivados da própria alteração, no contexto de tudo o que o agente já sabe sobre o seu produto. Lance um novo filtro no seu painel de controlo e o agente testa o filtro e os fluxos do painel de controlo nos quais este está integrado. Ninguém teve de se lembrar de adicionar cobertura.

Passo 4: leia os resultados onde os seus engenheiros já trabalham

O resultado, aprovado ou reprovado, aparece no próprio pedido de integração. Em cada execução, o agente produz um relatório de avaliação: o objetivo, o resultado esperado, o que aconteceu efetivamente, um vídeo da execução, capturas de ecrã passo a passo e os registos da consola e da rede. Uma falha não é um X vermelho que tenha de ser analisado ao contrário – é uma explicação escrita do que o agente esperava ver e do que viu em vez disso.

Como o agente testa através da interface, comunica as falhas ao nível do produto – dir-lhe-á que o código de desconto já não é aplicado no momento do pagamento, com as provas anexadas. Esse contexto ao nível do produto é exatamente aquilo de que os seus engenheiros – ou os seus agentes de programação – precisam para localizar e corrigir a causa. As equipas que executam ciclos de desenvolvimento agentivo enviam os nossos relatórios de avaliação diretamente para os seus agentes de programação, como contexto da falha a corrigir – e, com a integração MCP, esses agentes de programação podem desencadear eles próprios execuções de testes enquanto trabalham.

Passo 5: Adicione testes de regressão aos testes de PR

Os testes acionados por PR verificam a alteração. Os planos de regressão verificam tudo o resto. No QA.tech, agrupa casos de teste em planos – uma bateria de testes rápidos para cada implementação, uma regressão completa antes de versões principais – e executa-os na cadência que melhor se adapta ao seu processo de lançamento.

Como os testes são executados em paralelo, o tempo real necessário é uma fração do que a mesma cobertura exige manualmente. Um plano de regressão completo recente que executámos abrangia um volume de testes que ocuparia um testador manual durante um ou dois dias; ficou concluído em cerca de vinte minutos. É esta diferença que torna "executar a regressão completa em cada lançamento" numa política real, em vez de uma aspiração.

Passo 6: Pergunte ao agente onde a sua cobertura é insuficiente

Como o grafo de conhecimento mapeia cada fluxo descoberto pelo rastreio, a plataforma sabe a diferença entre o que o seu produto contém e o que os seus testes exercitam. Pode perguntar diretamente no chat: "Quais são os fluxos de maior valor que não têm cobertura neste momento?" O agente responde com base no mapa do seu produto e pode gerar os testes em falta no momento.

Isto inverte a dinâmica habitual da cobertura. Em vez de a cobertura ser tudo aquilo que se acumulou ao longo de anos de criação de testes orientada por tickets, passa a ser uma questão que pode colocar e à qual pode responder na mesma tarde.

Como isto se apresenta ao fim de um mês

O padrão que observamos nas equipas é consistente. A primeira semana envolve alguma interação – o agente faz perguntas, precisa ocasionalmente de contexto sobre as particularidades do seu produto e o utilizador corrige a sua compreensão. Na segunda semana, as perguntas são raras. Na terceira, praticamente deixaram de existir, porque o grafo de conhecimento assimilou o funcionamento do seu produto. A partir daí, os testes são executados ao ritmo dos seus pedidos de integração e as pessoas envolvidas analisam os resultados em vez de manterem scripts. Se quiser a sequência completa de implementação – desde a prova de conceito até à retirada das suas baterias de testes antigas – publicámo-la num guia prático, Adotar testes baseados em agentes: o guia.

Para as equipas que passaram a utilizar código escrito por agentes, isto fecha o ciclo que faltava: geração de código, revisão de código e verificação, tudo a funcionar ao ritmo das máquinas, com os seus engenheiros a orientar o sistema em vez de o alimentarem.

Veja o que os agentes de QA geram para o seu próximo pedido de integração – ligue um repositório ao QA.tech e execute o primeiro teste em minutos.