Construa cobertura em torno das tarefas do cliente
Liste as rotas e resultados que geram valor: encontrar um serviço, pesquisar, adicionar um item, reservar, entrar, pedir ajuda ou pagar. Para cada uma, nomeie os componentes que podem mudar de forma ou falhar: navegação, filtros, cards, tabelas, imagens, banners, formulários, gavetas e widgets incorporados. Teste larguras onde seu conteúdo fica restrito, não simplesmente um catálogo dos modelos de celular atuais. Teste logo abaixo, exatamente em e logo acima de cada breakpoint.
Inclua celulares estreitos e de largura média, uma largura parecida com tablet, laptop, desktop amplo e paisagem quando isso altera a tarefa.
Use títulos longos, resultados vazios, erros de validação, badges de preço, endereços completos e rótulos mais longos quando esses estados existirem.
Comprove reflow, leitura e zoom
Confirme que a página tem a configuração de viewport apropriada e depois procure por rolagem horizontal a nível de página. Imagens fixas, campos largos, margens negativas, painéis off-canvas e banners são causas comuns. O critério Reflow do WCAG 2.1 descreve conteúdo com rolagem vertical em uma largura equivalente a 320 CSS pixels, incluindo um viewport de 1280 pixels com zoom de 400%. Se esse critério estiver no escopo, teste o cenário real de zoom. Um mapa, vídeo ou tabela de dados pode exigir layout bidimensional, mas mantenha essa rolagem dentro do componente e deixe a página ao redor reflowar.
Verifique cabeçalhos, conteúdo principal, rodapés, barras sticky, diálogos e resumos de erro em cada limite testado.
Reorganize a informação para uma tela estreita; não remova silenciosamente um requisito, detalhe de preço ou caminho de ajuda.
Estresse conteúdo e formulários
Operações de conteúdo podem causar falhas responsivas sem um release de CSS. Teste o maior título aprovado, vários badges, uma imagem ausente, um filtro selecionado, um aviso legal extenso e um campo preenchido pelo navegador. Quando colunas empilham, confirme que a ordem de leitura e de teclado ainda faz sentido. Complete o formulário real em um dispositivo pequeno: abra controles, corrija um erro e envie. Teste widgets de terceiros na página parecida com produção porque seu container, estado de consentimento, fontes e estilos podem alterar o resultado.
Represente comprimentos e combinações máximas prováveis, mas não inclua dados de clientes ou pagamento nas evidências de QA.
Abra avisos, chat, promoções e mensagens de validação ao mesmo tempo; nenhuma deve cobrir a ação principal ou o campo em foco.
Exercite todo caminho de entrada
Uma tela grande não garante um mouse, e uma tela pequena não garante apenas toque. A feature de mídia hover testa se uma entrada primária consegue passar o cursor convenientemente, então o hover deve aprimorar e não ser a única rota para uma ação ou explicação. Teste uso por teclado e apontador no desktop, toques e rolagem em um dispositivo touch, e dispositivos com entradas mistas quando relevante. Reveja botões de fechar compactos, steppers, chips, calendários e ações por ícone. WCAG 2.2 Target Size (Minimum) especifica um alvo de 24 por 24 CSS-pixels com exceções definidas, incluindo espaçamento e links inline. É um critério com escopo e exceções, não uma promessa de que todo controle de 24 pixels seja igualmente fácil para todos.
Navegue com Tab pela página. O foco deve permanecer visível, seguir uma ordem sensata e entrar/ sair de menus e diálogos de forma previsível.
Torne um reveal essencial por hover disponível por foco, toque ou um controle visível, e evite comportamentos confusos no primeiro toque.
Verifique ativos e desempenho sob restrição
Uma imagem pode caber em seu container e ainda ser o arquivo errado para o dispositivo. Verifique se a mídia permanece contida, reserva espaço de layout quando aplicável, preserva sua crop útil e solicita candidatos adequados. Srcset e sizes dão ao navegador informação para escolher entre as fontes de imagem fornecidas; eles não garantem uma requisição específica. Use o throttling das DevTools para descobrir problemas cedo, mas seus controles de CPU e rede simulam condições relativas ao computador de desenvolvimento. Refaça os principais caminhos em um dispositivo real e conexão real. Inspecione fontes, mídia hero, carrosséis, trabalho client-side e scripts de terceiros por atrasos, shifts ou toques bloqueados.
Capture a rota, viewport, conexão real ou simulada e o que ficou lento ou instável; compare condições equivalentes.
Quando seguro, adie embeds não essenciais em uma build de teste para saber se a tarefa principal permanece utilizável.
Remedie como trabalho proativo de uptime
Para Status Is UP, a prontidão responsiva é otimização proativa de uptime: identifique um caminho de dispositivo que bloqueia o usuário, corrija sua causa, prove a reparação e previna recorrência. Não é uma afirmação de que um alerta de monitoramento pode julgar todo defeito de layout ou interação. Priorize por impacto da tarefa e alcance. Antes do deploy, teste larguras adjacentes e a jornada alterada em hardware real. Planeje um rollback para mudanças na navegação compartilhada, estilos, scripts, pagamentos ou integrações. Após o release, repita os passos de comprovação e anexe a evidência ao registro de mudança.
Informe rota, dispositivo ou viewport, orientação, entrada, estado, resultado esperado, resultado real e uma captura com dados mascarados.
Prefira um conserto em componente, regra de layout, token ou entrega de imagem a um override apenas na rota; dê dono e plano de remoção às exceções.