Boas Práticas de Automação

Objetivo da Página

Esta página consolida, em um único ponto, as diretrizes oficiais da DBSeller para automação de testes, abrangendo:

Boas práticas para criação de testes automatizados sustentáveis.

Critérios claros para decidir o que automatizar e o que não automatizar.

Práticas de manutenção para garantir estabilidade, confiabilidade e longevidade da automação.

Esta página faz parte do Book Execução de Testes, dentro do Chapter QA – Elaboração, e tem como principal objetivo garantir que a automação seja tratada como estratégia de qualidade, e não apenas como implementação técnica.

Automação, na DBSeller, não é sinônimo de escrever código de teste. É uma decisão consciente baseada em valor, risco, custo e retorno.

2. Princípios Fundamentais da Automação de Testes

Antes de falar sobre ferramentas, frameworks ou pipelines, é essencial estabelecer os princípios que norteiam a automação na DBSeller.

2.1 Automação serve ao negócio

Testes automatizados existem para:

Reduzir riscos recorrentes.

Aumentar a confiança em entregas frequentes.

Liberar o QA de validações repetitivas.

Eles não existem para:

Substituir pensamento crítico.

Cobrir tudo indiscriminadamente.

Resolver problemas de qualidade estrutural.

2.2 Automação não substitui testes manuais

Automação complementa o trabalho manual. Testes exploratórios, validações visuais e análises de comportamento continuam sendo responsabilidade humana.

2.3 Automação mal feita aumenta o custo

Testes instáveis, mal estruturados ou sem critério geram:

Falsos positivos.

Perda de confiança no pipeline.

Alto custo de manutenção.

Por isso, decidir o que automatizar é tão importante quanto como automatizar.

3. Onde a Automação se Encaixa no Fluxo de QA

A automação não começa na execução. Ela nasce na Elaboração da Estratégia de Teste da Task.

Fluxo simplificado:

[Leitura da Demanda]
        |
        v
[Mapeamento de Risco]
        |
        v
[Decisão de Automação]
        |
        v
[Criação / Atualização de Testes Automatizados]
        |
        v
[Execução e Manutenção]

A decisão de automatizar deve ocorrer antes da execução manual, sempre que possível.

4. O que Automatizar e o que Não Automatizar

4.1 Princípio da decisão

A pergunta correta nunca é “dá para automatizar?”, mas sim:

Vale a pena automatizar?

Essa decisão deve considerar valor, risco e esforço.

4.2 Critérios para automatizar

Um cenário é um bom candidato à automação quando:

É executado com frequência.

Possui regras de negócio bem definidas.

Tem resultado esperado objetivo.

Apresenta risco relevante em caso de falha.

Tem baixo custo de manutenção.

4.3 Critérios para não automatizar

Um cenário não deve ser automatizado quando:

É executado raramente.

Depende fortemente de análise visual.

Sofre mudanças constantes.

Possui dados instáveis ou imprevisíveis.

O custo de manutenção supera o benefício.

4.4 Tabela de decisão

Critério	Favorável à Automação	Desfavorável à Automação
Frequência	Executado sempre	Executado raramente
Estabilidade	Regra estável	Regra volátil
Resultado	Objetivo	Subjetivo
Risco	Alto impacto	Baixo impacto
Manutenção	Baixa	Alta

Se a maioria dos critérios estiver à esquerda, a automação é recomendada.

4.5 Exemplo real

Cenário: Validação de cálculo de taxa de seguro.

Regra clara.

Executado em múltiplas simulações.

Alto impacto financeiro.

Decisão: Automatizar o cálculo base.

Cenário: Validação visual de layout em diferentes resoluções.

Subjetivo.

Alto custo de manutenção.

Decisão: Manter manual.

5. Boas Práticas para Criação de Testes Automatizados

5.1 Clareza acima de tudo

Um teste automatizado deve ser fácil de entender, mesmo para quem não o escreveu.

Boas práticas:

Nomes claros de testes.

Estrutura legível.

Passos bem definidos.

Teste automatizado não é lugar para criatividade excessiva.

5.2 Testes pequenos e focados

Cada teste deve validar uma única responsabilidade.

Evitar:

Testes longos demais.

Dependência de múltiplos fluxos.

5.3 Independência entre testes

Testes automatizados não devem depender uns dos outros.

Cada teste deve:

Criar seus próprios dados.

Limpar o que foi criado.

5.4 Dados de teste controlados

Sempre que possível:

Use dados mockados.

Evite dependência de dados reais.

Isole cenários críticos.

5.5 Falhas devem ser confiáveis

Um teste que falha deve indicar problema real, não instabilidade do teste.

6. Estrutura Sustentável de Automação

6.1 Separação de responsabilidades

Estrutura recomendada:

Camada de teste.

Camada de ações.

Camada de dados.

Isso reduz impacto de mudanças.

6.2 Reutilização consciente

Reutilizar código é bom, mas reutilizar lógica errada espalha problemas.

7. Manutenção de Testes Automatizados

7.1 Automação é produto vivo

Testes automatizados exigem manutenção contínua.

Ignorar manutenção resulta em:

Pipeline quebrado.

Testes desativados.

Perda de confiança.

7.2 Quando revisar testes

Revisão deve ocorrer quando:

Regra de negócio muda.

Interface é alterada.

Teste começa a falhar intermitentemente.

7.3 Tabela de sinais de alerta

Sinal	Ação Recomendada
Falhas intermitentes	Revisar sincronização
Muitos testes desativados	Reavaliar estratégia
Execução lenta	Refatorar testes

7.4 Exemplo real

Após alteração de layout, múltiplos testes falharam.

Análise mostrou seletores frágeis.

Ação:

Refatorar seletores.

Atualizar boas práticas.

8. Relação com Execução e Métricas

A automação deve gerar:

Confiança no pipeline.

Métricas acionáveis.

Base para decisão de Go ou No-Go.

Automação que não gera informação útil deve ser reavaliada.

9. Boas Práticas Organizacionais

Automação é responsabilidade compartilhada.

QA define estratégia, não apenas implementa.

Código de teste é código de produção.

10. Conclusão

A automação de testes, quando bem aplicada, é uma aliada poderosa da qualidade.

Na DBSeller, ela deve ser:

Planejada.

Justificada.

Sustentável.

Automatizar menos, mas automatizar bem, gera mais valor do que automatizar tudo sem critério.

Esta página consolida o entendimento de que automação é decisão estratégica, não apenas técnica.