Objetivo
Identificar obstáculos técnicos comuns no front-end que atrapalham a automação de testes de interface, com foco específico no site cnnbrasil.com.br como estudo de caso e base para exemplos. Também erros recorrentes cometidos por times de front-end que impactam negativamente o trabalho do QA.
Principais Obstáculos à Automação de UI
1. Falta de Identificadores Únicos e Estáveis
Problema: Elementos renderizados com classes ou IDs instáveis, auto-gerados por frameworks ou estilizações.
Exemplo real:
<div class="jsx-3456723 titulo card-vertical"></div>
Essas classes mudam entre builds.
Impacto: Dificulta a localização de elementos via seletores. Seletores baseados apenas em classes ou nth-child() são frágeis e quebram facilmente.
Soluções recomendadas:
- Adicionar data-testid, data-qa, aria-label, ou role.
- Usar nomes de classes sem hash ou sufixo dinâmico.
IDs únicos e descritivos para elementos interativos:
<button id="botao-carregar-noticias">Carregar mais</button>
2. Conteúdo Carregado Tardiamente ou de Forma Assíncrona
Problema: Muitos elementos da página só aparecem após requisições assíncronas, sem indicação clara de carregamento completo.
Impacto: O script de teste tenta interagir com elementos antes que estejam prontos ou visíveis.
Soluções recomendadas:
Incluir um indicador explícito de carregamento finalizado:
<div id="bloco-principal" data-status="carregado"></div>
Renderizar elementos com esqueleto visível desde o início, mesmo que vazios, e completar com dados depois.
3. Componentes Repetidos com Seletores Iguais
Problema: Diversos botões ou cards com a mesma classe ou sem um contexto para diferenciar.
Impacto: Seletores pegam elementos errados ou múltiplos de forma ambígua.
Exemplo ruim:
<button class="ler-mais">Ler mais</button> <!-- Vários iguais -->
Boas práticas:
Utilizar contexto hierárquico claro:
<article data-article-id="123">
<button
class="ler-mais"
aria-label="ler mais sobre notícia 123"
>
Ler mais
</button>
</article>
○ Usar atributos aria-* como alternativa acessível e testável.
4. Animações e Carrosséis Automáticos
Problema: Elementos como sliders/carrosséis mudam de posição automaticamente.
Impacto: Testes tentam interagir com um elemento que desaparece, muda de lugar ou “sai” do DOM.
Soluções:
Desativar animações no modo de teste com flag, por exemplo:
<body data-env="teste">
○ Fornecer controle manual no carrossel (pausar/play visível e testável).
5. Pop-ups e Banners Inesperados
Problema: Banners de cookie, newsletter, modal de aviso ou publicidade aparecem no carregamento e cobrem elementos.
Impacto: Botões ficam inacessíveis; cliques falham por “elemento não interativo”.
Soluções recomendadas:
- Adicionar um
data-testid="popup-cookies"e permitir que o banner seja fechado programaticamente. - Evitar mostrar pop-ups em ambientes de teste (condicional por ambiente).
- Usar
z-indexadequado para evitar sobreposição desnecessária de elementos críticos.
6. Navegação Quebra Fluxo (Nova Aba / Nova Janela)
Problema: A navegação abre links externos ou internos em nova aba com target=”_blank”.
Impacto: Quebra o contexto do navegador de teste e dificulta verificar a próxima tela.
Solução:
- Permitir que links sejam abertos no mesmo contexto (
target="_self") em ambiente de teste. - Expor as URLs diretamente para navegação programática com links previsíveis e fixos.
7. Conteúdo Volátil e Não Determinístico
Problema: O conteúdo da home muda com frequência (matérias, destaques, títulos).
Impacto: Testes que validam se uma notícia ou elemento está visível falham quando o conteúdo desaparece ou muda.
Melhorias sugeridas:
- Disponibilizar ambiente de teste com conteúdo estável.
- Inserir conteúdos fixos via mocks ou rotas alternativas (ex: /home-teste).
- Estruturar conteúdo por data-id que não muda.
8. Falta de Indicadores de Estado/Feedback Visual para Usuário e Testes
Problema: Ações como clicar em um botão não geram nenhum feedback visual imediato.
Impacto: Testes não sabem se a ação foi processada ou está em andamento.
Boas práticas:
Inserir indicadores de loading (aria-busy, data-loading).
Trocar texto ou ícone após clique:
<button data-loading="false">Salvar</button>
Muito importante: Além de data-testid, outras abordagens eficazes:
| Atributo / Técnica | Vantagem |
|---|---|
aria-label | Compatível com leitores de tela e test frameworks |
role="button", etc | Aumenta acessibilidade e facilita testes sem depender de CSS |
data-qa ou data-test | Alternativas neutras ao data-testid |
id fixo e significativo | Fácil de localizar e sem ambiguidade (ex: id="menu-principal") |
| Hierarquia clara | Permite usar seletores como main > nav > button de forma segura |
title ou alt | Também são acessíveis e suportados em validação de UI e acessibilidade |
Erros Comuns de Front-End que Prejudicam o QA
1. Reutilização excessiva de nomes de classe
Impacta testes e leitura semântica.
Solução: Use escopos únicos ou data-*.
2. Falta de versionamento visível da UI
Não saber se um componente foi alterado dificulta validar regressões.
3. Atributos gerados dinamicamente sem consistência
Ex: class="component-87a12f" muda a cada build.
Sugestão: Use nomes manuais e legíveis.
4. Uso de nth-child() como único seletor viável
Extremamente frágil com qualquer alteração de DOM.
5. Dependência excessiva de textos dinâmicos
Ex: Validar botão por “Leia mais” quando o texto muda por AB test ou editoria.
6. Carregamento por scroll infinito sem fallback
Torna o conteúdo imprevisível e os testes mais lentos.
Sugestão: Fornecer paginação nos ambientes de teste.
7. Uso de iframes para renderizar partes do layout
Complica navegação e acesso via automação.
Conclusão
A criação de uma interface testável não exige esforço significativo extra. Com boas práticas no uso de seletores, atributos e controle de estado visual, é possível manter a flexibilidade do front-end e ao mesmo tempo facilitar a automação de testes UI — algo que beneficia toda a equipe e acelera a entrega contínua com confiança.