Plano de testes (ou roteiro de testes de aceitação): o documento que descreve os cenários a percorrer e os resultados esperados, para verificar que um sistema cumpre os seus requisitos (OpenClassrooms). Automatizar um plano de testes é transformar esses cenários em testes que se repetem de forma idêntica em cada entrega, sem escrever código: é exatamente o princípio do teste de regressão.
Um plano de testes bem escrito não caduca: o que para é a sua execução. No lançamento do projeto, a equipe percorre os 80 casos de teste em três dias. Seis meses depois, as entregas saem a cada duas semanas e a janela de aceitação dura duas horas. Testa-se o que acabou de ser entregue, deixa-se de repetir o que já funcionava, e a regressão passa pelo vão. Este artigo separa o que pode ser automatizado sem código do que deve continuar humano, e detalha o método para passar de um documento a uma campanha de regressão que se repete a cada entrega.
O essencial numa página (definição, automação sem código, grelha de escolha de uma ferramenta): Testes de regressão automatizados, sem código.
O seu plano de testes reduzido a metade dos casos por falta de tempo? O Delta-QA grava os seus percursos enquanto navega e repete o plano completo a cada entrega, sem código. Testar o Delta-QA grátis →
Por que um plano de testes manual não acompanha o ritmo das entregas
Um plano manual tem um custo de execução constante: percorrê-lo leva o mesmo tempo na quinquagésima entrega que na primeira. A sua utilidade, essa, cresce com a frequência de entregas, já que cada implantação pode partir um percurso que funcionava. Quando o vão entre essas duas curvas fica grande demais, as equipas cortam na cobertura: executam os casos do âmbito entregue e abandonam o resto.
O risco desloca-se então exatamente para onde ninguém olha. Um túnel de pagamento refeito é testado em detalhe; a página de conta, atingida pela mesma refatoração de componente, não é repetida por ninguém. O departamento de sistemas da Inria, que industrializou os testes de regressão do seu sistema de informação, chega à mesma conclusão: repetir os testes após cada mudança é repetitivo, caro em tempo e fonte de erros; a sua automação eliminou essas falhas (JRES 2019).
A boa pergunta não é « será preciso redigir melhor o plano? », mas « quantas vezes por ano merece cada caso ser repetido? ». Todo o caso cuja resposta é « a cada entrega » é candidato direto à automação.
O que se pode automatizar num plano de testes, e o que fica humano
Tudo o que seria repetido de forma idêntica pode ser automatizado sem código; o que exige julgamento fica com quem faz a aceitação. A fronteira passa entre verificar e avaliar.
| Verificação típica de um plano | Exemplo concreto | Automatizável sem código? |
|---|---|---|
| Percursos críticos | Compra completa, registo, pesquisa e reserva | Sim: percurso gravado, repetido e comparado |
| Renderização das páginas-chave | Página inicial, ficha de produto, em cada largura de ecrã | Sim: captura comparada com a referência |
| Estados da mesma página | Formulário vazio, com erro, validado; menu aberto | Sim: cada estado gravado como cenário |
| Coerência entre navegadores | O pagamento funciona no Chrome, e no Safari? | Sim: mesmo cenário, navegadores diferentes |
| Pertinência de um conteúdo | A nova mensagem de erro é clara? | Não: julgamento humano |
| Decisão final | A entrega é aceitável, com pleno conhecimento? | Não: isso é a aceitação, e continua humana |
Na prática, a maioria dos planos que vemos contém 60 a 80 % de casos repetíveis. É a parte que consome mais tempo na aceitação manual, porque é repetitiva. É também onde a fadiga produz os « OK » falsos: assinalar a linha sem repetir realmente a manipulação. Para redigir ou consolidar o documento em si, o guia de referência continua útil: Testes de aceitação de software: o guia completo.
Do plano de testes à campanha de regressão: o método em 5 passos
A migração faz-se sobre o plano existente, sem o reescrever: cada caso torna-se um cenário automatizado, ou um caso que continua manual porque exige julgamento.
- Triar o plano. Marque cada caso como « repetir a cada entrega » ou « julgamento pontual ». O primeiro lote vai para a automação; o segundo fica no documento manual, que fica mais curto e finalmente é executado por inteiro.
- Gravar os percursos navegando. Com uma ferramenta sem código, o cenário « pesquisar um produto, adicioná-lo ao carrinho, pagar com 3-D Secure » é gravado tal como o percorre. Nenhuma linha de código, nenhum framework para instalar.
- Capturar os estados que contam. Um formulário vazio, com erro e validado são três cenários distintos. Acrescente as larguras de ecrã críticas (móvel, tablet, secretária) e os navegadores da sua audiência.
- Repetir em cada candidata a entrega. A campanha completa executa-se em pré-produção antes de cada implantação. Também corre periodicamente em produção, para as mudanças que não passam pelas suas implantações: CMS, widgets de terceiros, atualizações de dependências do lado do navegador.
- Qualificar cada diferença. O relatório mostra o que mudou entre a referência e a entrega. A equipa decide: regressão a corrigir, ou evolução pretendida que se torna a nova referência.
No Delta-QA, a comparação é feita por uma IA determinística, não um LLM: um algoritmo proprietário, sem modelo treinado, que dá o mesmo veredicto em cada execução e só sinaliza o que um olho humano notaria. Por que este critério conta numa aceitação: uma ferramenta que varia de uma execução para a outra reintroduz exatamente o acaso que a automação devia eliminar. Sobre o papel da QA nesta migração: Automatizar os testes sem programadores.
Repetir 80 casos de teste antes de cada implantação? Grave os seus percursos uma vez no Delta-QA; a campanha repete-se sozinha e o relatório lado a lado mostra cada diferença. Testar o Delta-QA grátis →
Quanto tempo a automação demora, e quando se paga
Conte meio dia para os percursos críticos, um a dois dias para um plano completo: é o tempo de gravar os cenários navegando e qualificar as primeiras diferenças. O cálculo de rentabilidade depois é aritmética simples. Um plano de 40 casos a 10 minutos cada um custa cerca de 7 horas por execução completa; com uma entrega a cada duas semanas, a automação paga-se antes do fim do primeiro mês, e cada execução seguinte é tempo ganho.
Duas nuances honestas completam este cálculo. Primeiro, a manutenção existe: cada evolução de interface pretendida exige validar a nova referência, uns minutos por página. É o preço normal de uma campanha alinhada com o produto. Segundo, nem tudo é automatizável no primeiro dia, e não faz mal: uma campanha que cubra os percursos críticos no primeiro mês já protege o essencial das receitas.
FAQ
Pode-se automatizar um plano de testes sem saber programar?
Sim. As ferramentas de gravação e repetição capturam os cenários enquanto navega na aplicação, depois comparam-nos automaticamente com uma referência validada. O plano existente serve de planta: cada caso « repetir a cada entrega » torna-se um cenário gravado.
Qual a diferença entre aceitação e teste de regressão?
A aceitação valida uma entrega concreta, na sua globalidade e com julgamento humano. O teste de regressão verifica, a cada entrega, que os percursos já validados continuam a funcionar. Os dois coexistem: a aceitação decide, a regressão protege o adquirido.
O que fazer com os casos de teste que mudam a cada entrega?
Pertencem geralmente à confirmação da nova funcionalidade e continuam manuais. Quando a interface evolui de forma duradoura, a referência do cenário afetado atualiza-se validando o novo render uma vez; as execuções seguintes partem dessa nova base.
Um plano de testes automatizado substitui o tester?
Não. A automação executa as verificações repetitivas e sinaliza as diferenças; qualificar essas diferenças, a pertinência dos conteúdos e a decisão final GO/NO-GO continuam humanas. O tester ganha o tempo das execuções mecânicas para o investir em exploração e julgamento.
Por onde começar quando o plano já existe?
Pelos percursos que tocam as receitas ou um compromisso regulatório: compra, pagamento, registo, contacto. Gravados primeiro, cobrem a maioria do risco com uma minoria dos casos. O resto do plano segue nas semanas seguintes, sem prazo.
O seu plano de testes merece melhor do que uma execução em cada duas. Crie uma conta gratuita, grave os seus percursos críticos e deixe o Delta-QA repetir a campanha completa a cada entrega. Testar o Delta-QA grátis →