Engenheiros de QA da SpaceWeb deixaram a IA escrever autotestes: script funcional em 50 minutos

Todo QA conhece essa aritmética: há mais funcionalidades do que mãos, os releases estão pegando fogo e metade do dia vai para casos de teste repetitivos e "esqueletos" de autotestes. Evgenia Myasnikova, engenheira de QA da SpaceWeb, e Vitaly Kireev, chefe de P&D, decidiram verificar que parte dessa rotina pode ser entregue honestamente a um LLM e onde ele apenas gera "enrolação" que depois você reescreve à mão de qualquer jeito.

Três tarefas para a IA e uma escolha importante

A equipe não tentou automatizar tudo de uma vez. Foram escolhidas três frentes: documentação e dados de teste (verificações positivas, negativas e de valores-limite, planos de teste, checklists), scripts de automação e ampliação das verificações de segurança e de API. O princípio é simples: a IA faz o rascunho, e o testador lê, complementa e depura.

A principal escolha prática diz respeito aos dados. Por causa de informações sensíveis, o agente foi conectado ao modelo local Qwen3.8-27B. Para documentação e código usou-se um assistente interno, e tudo rodou na stack habitual: Postman, Python, Pytest e Selenium. Se você trabalha com código fechado e esquemas internos de API, uma nuvem externa não é obrigatória para esse tipo de trabalho.

Nos formulários, funciona assim. Carregam-se no modelo as pré-condições, os requisitos de obrigatoriedade dos campos e de validação, e na saída obtém-se uma tabela de verificações positivas e depois negativas. Para a integração com GitHub/GitLab, a IA destacou ainda os cenários mais críticos. Para a API, deram ao agente um exemplo de JSON válido para criar uma VPS e pediram que preparasse dados: requisições mínimas e de referência, valores-limite, domínios em cirílico, caracteres especiais e casos inválidos, como criar um servidor em uma região inexistente.

Ainda assim, o resultado precisa ser lido com atenção. Em um dos exemplos, o hostname é descrito como "exatamente 63 caracteres", mas a string é visivelmente mais longa, e um espaço foi parar em um endereço IPv6. Em um teste de limite isso pode até ser intencional, mas é mais seguro conferir essas coisas manualmente.

Autoteste em menos de uma hora

O caso mais ilustrativo é a automação da criação de uma caixa de e-mail no painel de hospedagem. O prompt é detalhado passo a passo e contém tudo o que a pessoa diante da tela sabe: Pytest, Selenium, Chrome, autenticação a partir do conftest.py, seletores exatos, regras de senha (8–20 caracteres, letras, números, caracteres especiais) e o redirecionamento esperado para a página review. O modelo entregou um test_mail_add.py pronto, com comentários, esperas explícitas via WebDriverWait e verificações do resultado.

Depois a tarefa foi complicada: pediu-se parametrizar o teste para diferentes nomes de caixa. Resultaram dois testes: test_create_valid_mail_box e test_reject_invalid_mail_box. Os conjuntos positivos verificam comprimento de 1 e 64 caracteres, caracteres especiais e números. Os negativos verificam letras maiúsculas, espaços, barra e comprimento de 65. Se um caso falha, vê-se imediatamente qual cenário quebrou.

Quanto ao tempo: cerca de 30 minutos foram gastos no prompt e na busca de seletores, mais 20 na depuração. Não é "apertar um botão e pronto", mas para um esqueleto de rotina o resultado é bom.

As limitações também aparecem no código. No teste negativo, a IA não sabia como o sistema reage a um erro e por isso propôs duas variantes: ou o front-end exibe o erro, ou o formulário é enviado e não há redirecionamento. A segunda variante ficou comentada, e o comportamento teve de ser esclarecido por uma pessoa. Além disso, no teste positivo, nomes sem número no final recebem um sufixo aleatório. Por causa dele, o caso "exatamente 64 caracteres" vira um nome maior que o limite, ou seja, a verificação de limite na prática quebra. Coisas assim só a revisão pega.

IDOR: há um começo, ainda sem resultados

O terceiro caso trata da segurança da API. Era preciso verificar IDOR no método edit (JSON-RPC): o campo service_ref funciona como identificador direto do objeto, e o servidor deve verificar se o usuário tem direitos sobre ele. O agente propôs de imediato uma verificação básica: enviar a mesma requisição com o service_ref de outro usuário. Em seguida, a equipe pediu um script em Requests que percorresse os valores de um arquivo TXT com identificadores de serviços de terceiros.

Na parte disponível da publicação, o texto é interrompido nesse ponto, de modo que não há resultados finais sobre IDOR. Não se deve concluir se a IA encontrou vulnerabilidades reais.

O que levar para a prática

• Dê ao modelo contexto estruturado: pré-condições, esquema do método, exemplo de JSON válido, seletores concretos. A qualidade do resultado depende do prompt.
• Trate a saída como rascunho. Verifique limites de valores, comportamento esperado em erros e localizadores.
• Para dados sensíveis, implante um modelo local: a SpaceWeb mostrou que um cenário funcional é possível também com ele.
• Comece pela rotina: casos de teste, dados de teste, esqueletos de testes de UI. É ali que a economia é mais evidente.

A conclusão honesta é esta: a IA não substitui o engenheiro de QA, mas tira dele a parte mais mecânica. O controle de qualidade continua nas mãos de quem sabe como o sistema deve se comportar.