Pontos-chave
- As PWAs não são simples sites: elas têm estados visuais específicos (offline, standalone, instalação, splash screen) que os testes web padrão ignoram
- A experiência do usuário de uma PWA instalada é julgada pelos padrões de aplicações nativas, não de sites web
- O teste visual deve cobrir as transições entre os modos online e offline, a renderização em modo standalone e os elementos específicos como o splash screen e os prompts de instalação
- Sem cobertura visual desses estados, você está entregando o que parece ser um app nativo, mas na verdade é um site quebrado
Uma Progressive Web App (PWA) é definida pelo W3C como "uma aplicação web que utiliza tecnologias web modernas — especialmente Service Workers, Web App Manifest e HTTPS — para oferecer aos usuários uma experiência confiável, rápida e envolvente, comparável à de uma aplicação nativa, diretamente do navegador ou após a instalação no dispositivo" (W3C, especificação do Web App Manifest).
Essa definição é tecnicamente precisa. Mas ela não capta o essencial: do ponto de vista do usuário, uma PWA instalada não é um site. É um aplicativo. Ela aparece no dock, na barra de tarefas, no app switcher. Tem sua própria splash screen, sua própria janela, seu próprio comportamento quando a rede cai.
E é exatamente aí que está o problema. Se seus usuários percebem sua PWA como um aplicativo, eles a julgam com as exigências de um aplicativo. Mas se você a testa como um simples site, está deixando categorias inteiras de bugs visuais passarem despercebidos.
As PWAs Têm Estados Visuais Que os Sites Não Têm
O estado online: o falso amigo
O estado online é o que todo mundo testa. É sua PWA em um navegador, com uma conexão de rede estável, funcionando exatamente como um site web clássico. Tudo funciona, tudo aparece, os dados carregam.
A armadilha é acreditar que testar esse estado é suficiente. É como testar um aplicativo móvel apenas em Wi-Fi no seu escritório e considerar que a cobertura é adequada. O estado online é o ponto de partida, não o destino.
O estado offline: a verdadeira prova de maturidade
Quando uma PWA perde a conexão de rede — ou quando o usuário a abre em modo avião — o Service Worker assume o controle. As páginas em cache são servidas do armazenamento local. Os dados não sincronizados são gerenciados localmente. As funcionalidades que exigem rede são degradadas graciosamente.
Do ponto de vista visual, o estado offline é um campo minado. Veja o que pode dar errado, e o que sistematicamente passa despercebido:
Páginas não cacheadas exibem uma página de erro. Se sua estratégia de cache não cobre todas as rotas, o usuário vê uma página em branco, um erro do navegador ou uma página de fallback. Você desenhou essa página de fallback? Testou-a visualmente? Em todos os viewports?
Imagens não carregam. Seu cache contém o HTML e o CSS, mas as imagens não cacheadas exibem um placeholder quebrado, um ícone de link quebrado, ou pior, um espaço vazio que desorganiza o layout. O teste visual é a única forma confiável de verificar que o estado offline é visualmente aceitável.
Componentes dinâmicos se degradam. Um gráfico que precisa de dados em tempo real, um feed de notícias, um chat integrado — no modo offline, esses componentes devem exibir um estado degradado explícito e visualmente coerente. Não um spinner infinito, não um container vazio, não uma mensagem de erro técnica.
Indicadores de status de rede aparecem (ou não). Se sua PWA exibe um banner "Você está offline" no topo da página, esse banner faz parte da experiência do usuário. Sua aparência, posicionamento e interação com o restante do layout devem ser testados visualmente.
A splash screen: os primeiros milissegundos importam
Quando um usuário abre sua PWA instalada, a primeira coisa que ele vê não é sua página inicial. É a splash screen, gerada automaticamente pelo navegador a partir dos dados do seu Web App Manifest (nome, ícone, cor de fundo).
Essa splash screen costuma ser a filha negligenciada do design. E isso é um erro. Ela define a primeira impressão do seu aplicativo a cada inicialização. Se o ícone está pixelado, se a cor de fundo não combina com o tema do seu app, se o texto está truncado, o usuário percebe imediatamente uma descontinuidade que corrói a confiança.
A splash screen é particularmente traiçoeira porque sua aparência depende do navegador e do SO. O Chrome no Android a gera de forma diferente do Safari no iOS. Os tamanhos de ícone esperados não são os mesmos. O tratamento de margens e centralização varia. Você precisa de capturas visuais nas plataformas que está visando.
O prompt de instalação: o momento de conversão
O prompt de instalação — aquele banner ou modal que convida o usuário a "Adicionar à tela inicial" — é um momento de conversão crítico. É o equivalente ao botão "Baixar" em uma app store. Sua aparência visual influencia diretamente a taxa de instalação.
Muitas PWAs usam um prompt personalizado (interceptando o evento beforeinstallprompt) em vez do prompt nativo do navegador. Esse prompt personalizado é um componente da sua aplicação. Deve ser testado visualmente como qualquer outro componente — em todos os viewports, todos os temas, todos os contextos.
Mas o prompt nativo varia por navegador e versão. Você não controla sua aparência, mas controla o que acontece ao redor dele: o conteúdo da página ao fundo, o posicionamento dos seus elementos, o comportamento quando o prompt empurra o conteúdo para baixo. Tudo isso merece verificação visual.
O modo standalone: a interface sem chrome do navegador
Quando sua PWA está instalada e é aberta a partir da tela inicial, ela abre em modo "standalone": sem barra de endereço, sem abas, sem botões de navegação do navegador. A aplicação ocupa toda a tela disponível (exceto a barra de status do sistema).
Essa mudança de ambiente tem implicações visuais diretas.
O espaço disponível muda. Sem a barra de endereço, sua aplicação tem de 50 a 80 pixels extras em altura. Se seu layout se baseia em alturas fixas ou cálculos de viewport (100vh), a renderização pode ser sensivelmente diferente em standalone versus no navegador.
A área de safe area entra em jogo. Em dispositivos com notch ou Dynamic Island, a área de conteúdo segura é diferente no modo standalone. Elementos posicionados no topo ou na parte inferior da tela (headers fixos, barras de navegação, FABs) podem ficar parcialmente ocultos se as safe areas não forem tratadas corretamente.
A navegação muda. Sem o botão "voltar" do navegador (especialmente no iOS), sua aplicação deve fornecer sua própria navegação. Se um usuário pode ficar preso em uma página sem forma de voltar, isso é um bug UX grave — e o teste visual pode detectá-lo verificando a presença sistemática de elementos de navegação.
As interações com a barra de status do sistema. A cor da sua barra de status (definida no manifest ou via meta tag theme-color) deve harmonizar com seu header. Um header branco com uma barra de status preta cria uma ruptura visual desagradável.
O Problema dos Testes Web Padrão
Eles só testam um estado
A grande maioria das suítes de testes — incluindo testes visuais — testa apenas o estado online em um navegador. É o estado padrão, o mais simples de configurar e o mais estável. Mas também é o estado que mais se parece com um simples site web.
Se você testa apenas esse estado, está testando a versão menos exigente da sua PWA. Está verificando que sua aplicação funciona nas condições ideais. Isso é necessário, mas insuficiente.
Eles ignoram o ciclo de vida da PWA
Uma PWA tem um ciclo de vida que sites web não têm. A instalação, a atualização do Service Worker, a sincronização em segundo plano, o retorno online após um período offline — cada uma dessas transições pode provocar estados visuais inesperados.
Quando o Service Worker se atualiza enquanto o usuário está usando a aplicação, um banner "Nova versão disponível — Recarregar" pode aparecer. A aparência desse banner, seu posicionamento, sua interação com o conteúdo — tudo isso deve ser testado.
Quando a aplicação volta a ficar online após um período offline, os dados se sincronizam. Durante essa sincronização, a interface pode exibir estados de carregamento, indicadores de progresso, conflitos de dados. Esses estados visuais transitórios costumam ser negligenciados e frequentemente estão quebrados.
Eles não reproduzem o contexto standalone
Abrir sua PWA em tela cheia em um navegador não é a mesma coisa que abri-la em modo standalone. As dimensões são diferentes, o tratamento das safe areas é diferente, o comportamento de overscroll é diferente. Um teste executado no Chrome DevTools com um viewport simulado não reproduz fielmente o ambiente real de uma PWA instalada.
Como Testar Visualmente uma PWA Corretamente
Mapeie seus estados visuais
Antes de configurar seus testes, liste explicitamente todos os estados visuais da sua PWA. No mínimo, você deve cobrir:
O estado online em modo navegador. Esse é seu baseline web padrão. Cada página, cada viewport.
O estado online em modo standalone. As mesmas páginas, mas no contexto de instalação. Verifique as diferenças de layout relacionadas à ausência do chrome do navegador.
O estado offline — páginas cacheadas. Quando o usuário acessa uma página disponível no cache sem conexão, o que ele vê? Os dados estão completos? As imagens estão presentes?
O estado offline — páginas não cacheadas. Quando o usuário acessa uma rota não cacheada sem conexão, a página de fallback é visualmente correta? Ela oferece um caminho de volta ao conteúdo cacheado?
A transição de online para offline. O banner offline aparece corretamente? Os componentes dinâmicos se degradam visualmente de forma elegante?
A transição de offline para online. A ressincronização é visível? Os dados atualizados aparecem sem artefatos visuais?
A splash screen. Nas plataformas-alvo (Android Chrome, iOS Safari, Samsung Internet), a splash screen está visualmente correta?
O prompt de instalação. Seu prompt personalizado (se tiver um) é visualmente correto em todos os contextos?
Automatize as mudanças de estado de rede
Para testar o estado offline, simule a perda de rede programaticamente. O Chrome DevTools Protocol permite simular o modo offline, e ferramentas como o Playwright suportam nativamente a manipulação de condições de rede.
A sequência típica: carregar a página online, verificar visualmente, cortar a rede, recarregar ou navegar, verificar visualmente o estado offline. Essa sequência deve ser automatizada e reproduzível.
Teste o modo standalone sem dispositivo físico
Usar a opção de lançamento do Chrome em modo "app" (janela sem chrome do navegador) é a abordagem mais pragmática. Não é idêntico a uma PWA realmente instalada, mas é próximo o suficiente para detectar regressões de layout relacionadas à ausência da barra de endereço.
Para as safe areas, verifique visualmente os elementos posicionados com env(safe-area-inset-top) ou env(safe-area-inset-bottom) com os valores correspondentes aos seus dispositivos-alvo.
As Especificidades do iOS: Um Mundo à Parte
Vamos ser diretos: o Safari no iOS é o navegador mais problemático para PWAs. E provavelmente é a plataforma mais importante para seus usuários.
Apesar de avanços significativos desde o iOS 16.4 (que introduziu notificações push para PWAs), o Safari ainda está atrás do Chrome em suporte a PWA. A splash screen é tratada de forma diferente. O modo standalone tem comportamentos específicos. O tratamento do viewport e das safe areas é mais restritivo.
Isso significa que seus testes visuais devem incluir o Safari iOS como alvo explícito, não como um detalhe secundário. As diferenças de renderização entre Chrome Android e Safari iOS para uma mesma PWA costumam ser substanciais e surpreendentes.
Segundo dados da StatCounter para 2025, o Safari representa aproximadamente 27% do mercado mundial de navegadores móveis. Ignorar suas especificidades PWA é ignorar um quarto dos seus usuários potenciais.
O Que o Delta-QA Traz para as PWAs
O Delta-QA simplifica consideravelmente o teste visual de PWAs graças à sua abordagem no-code. Você não precisa escrever scripts para simular os diferentes estados da sua PWA — você configura seus cenários visualmente.
A capacidade do Delta-QA de testar em diferentes viewports é particularmente relevante para PWAs, que devem funcionar tão bem em uma tela de smartphone em modo standalone quanto em uma tela de desktop em um navegador. Uma única ferramenta cobre todo o espectro.
E como as PWAs se atualizam frequentemente (as atualizações são transparentes, sem passar por uma app store), a cadência de testes deve ser alta. A integração do Delta-QA no seu pipeline CI/CD garante que cada deploy é verificado visualmente antes de chegar aos seus usuários.
FAQ
Os testes visuais padrão não são suficientes para uma PWA?
Não. Os testes visuais padrão cobrem o estado online em um navegador. Para uma PWA, isso corresponde ao estado menos representativo da experiência real do usuário. O estado offline, o modo standalone, a splash screen, o prompt de instalação — são estados visuais específicos das PWAs que os testes web padrão ignoram. Se você testa apenas o estado online, está deixando a maioria dos riscos visuais da PWA sem cobertura.
Como simular o estado offline em testes automatizados?
Você pode usar as capacidades do Chrome DevTools Protocol (CDP) para simular a perda de rede programaticamente. Frameworks de teste como o Playwright oferecem métodos nativos para isso. A sequência típica: carregue a página normalmente, corte a rede via API, depois navegue ou recarregue para observar o comportamento offline. Capture screenshots em cada etapa para o teste visual.
Minha PWA precisa suportar offline para justificar testes visuais específicos?
Mesmo que sua PWA não funcione offline (estratégia "network only"), você precisa testar o que acontece quando a rede não está disponível. O usuário verá algo: uma página em branco, um erro do navegador, ou sua página de fallback. Seja o que for, essa visualização faz parte da experiência do usuário e merece um teste visual.
Qual é a diferença entre testar uma PWA e testar um aplicativo móvel nativo?
Testar uma aplicação nativa requer simuladores ou dispositivos físicos específicos de cada plataforma (iOS Simulator, Android Emulator). O teste de uma PWA pode ser realizado em grande parte com navegadores desktop configurados nos viewports corretos, tornando-o mais acessível e rápido. No entanto, certos aspectos (splash screen, safe areas, comportamento standalone no iOS) requerem verificações em ambientes reais ou próximos do real.
Como testar a splash screen se não tenho um dispositivo físico?
Não é possível testar a splash screen real sem um dispositivo ou emulador, pois ela é gerada pelo navegador no lançamento da PWA instalada. No entanto, você pode testar seus componentes: verifique visualmente se os ícones do manifest estão corretos em todos os tamanhos necessários, se a cor de fundo é coerente e se as imagens apple-touch-startup-image (para iOS) estão presentes e com boa qualidade.
As PWAs ainda são relevantes em 2026 com as app stores?
Absolutamente. Segundo um estudo da web.dev (Google), as PWAs oferecem taxas de conversão 36% superiores às dos sites móveis clássicos, principalmente graças à velocidade de carregamento e à experiência offline. Com a melhoria contínua do suporte a PWA no iOS e a abertura da União Europeia para navegadores de terceiros no iPhone (Digital Markets Act), as PWAs são mais relevantes do que nunca em 2026.
Para aprofundar
- Teste Visual para Ruby on Rails: Por Que as View Specs Não Bastam e Como o Teste Visual Preenche a Lacuna
- Desempenho Web e Teste Visual: O CLS É um Problema Visual, Não Funcional
Seus usuários não distinguem entre uma PWA e um aplicativo nativo. Eles veem um ícone na tela inicial, tocam nele e esperam que tudo funcione — com ou sem rede, com ou sem barra do navegador, com uma splash screen profissional e transições fluidas.
Se você desenvolve uma PWA mas a testa como um site, está traindo a promessa que fez ao oferecer a opção "Adicionar à tela inicial". PWAs são apps. Teste-as como apps.