Ferramentas de automação de UI: três categorias e o que cada uma pressupõe

As três categorias de ferramentas de automação de UI

• Frameworks de código. Você escreve testes em uma linguagem de verdade. Pressupõe: engenheiros com tempo para escrever e manter os testes.

• Gravação e low-code. Uma pessoa monta os fluxos em um editor. Pressupõe: alguém cuja função é criar fluxos de teste.

• Baseadas em agentes. A cobertura é gerada e refinada em linguagem natural. Pressupõe: que você vai revisar uma cobertura que não escreveu.

Qual pressuposto falha com mais frequência

O segundo. Plataformas low-code são construídas em torno de uma função de testes, e muitos times já não têm uma. A plataforma funciona, a licença está paga e ninguém está criando fluxos, então a cobertura para de crescer no mês em que o último testador foi embora.

O primeiro pressuposto falha mais devagar. Engenheiros conseguem escrever testes, e isso compete com entregar funcionalidades, então a suíte cresce no primeiro trimestre e depois estaciona.

Perguntas que valem mais que uma tabela de recursos

• Quem escreve o teste de número duzentos? Os dez primeiros são escritos durante a avaliação. Pergunte sobre o sexto mês.

• O que acontece quando a UI é redesenhada? Esse é o custo recorrente, e a resposta varia muito entre as categorias.

• Como é uma falha para quem vai corrigi-la? Cada vez mais, quem corrige é um agente de código, que não consegue interpretar uma captura de tela.

• Uma execução que nunca chegou às asserções é reportada como aprovada? Vale testar isso de propósito, porque às vezes a resposta é sim.

O custo que não aparece na comparação

Toda categoria aqui tem um custo contínuo que os fornecedores não quantificam, porque ele depende de você e não deles: o custo de decidir o que cobrir.

Com um framework de código, alguém escreve o teste, o que significa que alguém antes decidiu que aquele teste deveria existir. Com um editor low-code, a mesma coisa. Com cobertura gerada, a decisão passa para a revisão de um plano, o que é mais rápido, mas não é de graça, e costuma ser pulado, produzindo o modo de falha da cobertura que ninguém leu.

Qualquer que seja a sua escolha, reserve orçamento para isso de forma explícita. Uma hora por semana de alguém olhando o que está e o que não está coberto é a diferença entre uma suíte que reflete o seu produto e uma que reflete o que era conveniente automatizar dezoito meses atrás.

Como avaliar

Quebre algo de propósito. Introduza uma regressão real, como um salvamento que não persiste mais, e observe o que cada candidato reporta. Se ele falha, se a falha nomeia a divergência e se quem for corrigir conseguiria partir daquele resultado. Esse único exercício diz mais do que um mês de comparação de recursos.

Se você preferir não instalar nada, o dashboard faz a mesma coisa. Todo o resto que a linha de comando faz está no repositório da CLI.

Dois caminhos, e a escolha é, na verdade, sobre quem é dono do pipeline. Conectar o GitHub App pelo dashboard não exige nenhuma mudança no seu repositório, porque ele reage ao deploy que o seu build já emite. Adicionar um passo de GitHub Actions coloca a verificação no repositório, onde ela é revisada como o resto do build.

Qual pressuposto o TestSprite faz

Que você vai revisar uma cobertura que não escreveu pessoalmente. Essa é a troca: nenhum autor é necessário e, em contrapartida, alguém lê o plano e o corrige.

Na prática, os casos são gerados a partir do seu produto, os passos são expressos como intenções para que sobrevivam a redesenhos, e uma falha volta como o que foi tentado, o que o app fez e onde os dois divergiram, algo sobre o qual um agente de código consegue agir com a mesma facilidade que uma pessoa.

Para um time sem uma função dedicada de testes, esse pressuposto é mais fácil de cumprir do que os outros dois, porque revisar um plano leva uma hora por semana, enquanto escrever uma suíte exige um cargo. Se você tem esse cargo, um framework de código pode servir melhor, e a maneira honesta de escolher é perguntar qual pressuposto o seu time consegue cumprir de fato em um ano.