Puntos clave
- Las PWA no son simples sitios web: tienen estados visuales específicos (offline, standalone, instalación, splash screen) que las pruebas web estándar ignoran
- La experiencia de usuario de una PWA instalada se juzga con los estándares de las aplicaciones nativas, no de los sitios web
- La prueba visual debe cubrir las transiciones entre los modos online y offline, el renderizado en modo standalone y los elementos específicos como el splash screen y los prompts de instalación
- Sin cobertura visual de estos estados, estás entregando una aplicación que parece nativa pero que en realidad es un sitio web defectuoso
Una Progressive Web App (PWA) es definida por el W3C como «una aplicación web que utiliza las tecnologías web modernas — especialmente los Service Workers, el Web App Manifest y HTTPS — para ofrecer a los usuarios una experiencia fiable, rápida y atractiva, comparable a la de una aplicación nativa, directamente desde el navegador o tras la instalación en el dispositivo» (W3C, especificación del Web App Manifest).
Esta definición es técnicamente precisa. Pero pasa por alto lo esencial: desde el punto de vista del usuario, una PWA instalada no es un sitio web. Es una aplicación. Aparece en el dock, en la barra de tareas, en el app switcher. Tiene su propio splash screen, su propia ventana, su propio comportamiento cuando se pierde la red.
Y ahí es exactamente donde radica el problema. Si tus usuarios perciben tu PWA como una aplicación, la juzgan con las exigencias de una aplicación. Pero si la pruebas como un simple sitio web, dejas categorías enteras de bugs visuales sin detectar.
Las PWA Tienen Estados Visuales Que los Sitios Web No Tienen
El estado online: el falso amigo
El estado online es el que todo el mundo prueba. Es tu PWA en un navegador, con una conexión de red estable, comportándose exactamente como un sitio web clásico. Todo funciona, todo se muestra, los datos se cargan.
La trampa es creer que probar este estado es suficiente. Es como probar una aplicación móvil solo en Wi-Fi en tu oficina y considerar que la cobertura es adecuada. El estado online es el punto de partida, no el destino.
El estado offline: la verdadera prueba de madurez
Cuando una PWA pierde la conexión de red — o cuando el usuario la abre en modo avión — el Service Worker toma el relevo. Las páginas cacheadas se sirven desde el almacenamiento local. Los datos no sincronizados se gestionan localmente. Las funcionalidades que requieren red se degradan.
Desde el punto de vista visual, el estado offline es un campo de minas. Esto es lo que puede salir mal y que pasa sistemáticamente desapercibido:
Las páginas no cacheadas muestran una página de error. Si tu estrategia de caché no cubre todas las rutas, el usuario ve una página en blanco, un error del navegador o una página de fallback. ¿Has diseñado esa página de fallback? ¿La has probado visualmente? ¿En todos los viewports?
Las imágenes no se cargan. Tu caché contiene el HTML y el CSS, pero las imágenes no cacheadas muestran un placeholder roto, un icono de enlace roto o, peor aún, un espacio vacío que rompe el layout. La prueba visual es la única forma fiable de verificar que el estado offline es visualmente aceptable.
Los componentes dinámicos se degradan. Un gráfico que necesita datos en tiempo real, un feed de noticias, un chat integrado — en modo offline, estos componentes deben mostrar un estado degradado explícito y visualmente coherente. No un spinner infinito, no un contenedor vacío, no un mensaje de error técnico.
Los indicadores de estado de red aparecen (o no). Si tu PWA muestra un banner «Estás sin conexión» en la parte superior de la página, ese banner forma parte de la experiencia de usuario. Su apariencia, posicionamiento e interacción con el resto del layout deben probarse visualmente.
El splash screen: los primeros milisegundos importan
Cuando un usuario lanza tu PWA instalada, lo primero que ve no es tu página de inicio. Es el splash screen, generado automáticamente por el navegador a partir de los datos de tu Web App Manifest (nombre, icono, color de fondo).
Este splash screen suele ser el hijo olvidado del diseño. Y eso es un error. Define la primera impresión de tu aplicación en cada inicio. Si el icono está pixelado, si el color de fondo no coincide con el tema de tu app, si el texto está truncado, el usuario percibe inmediatamente una discontinuidad que erosiona la confianza.
El splash screen es particularmente traicionero porque su apariencia depende del navegador y del SO. Chrome en Android lo genera de forma diferente a Safari en iOS. Los tamaños de icono esperados no son los mismos. La gestión de márgenes y centrado varía. Necesitas capturas visuales en las plataformas que quieres cubrir.
El prompt de instalación: el momento de conversión
El prompt de instalación — ese banner o modal que invita al usuario a «Añadir a la pantalla de inicio» — es un momento de conversión crítico. Es el equivalente al botón «Descargar» en una app store. Su apariencia visual influye directamente en la tasa de instalación.
Muchas PWA usan un prompt personalizado (interceptando el evento beforeinstallprompt) en lugar del prompt nativo del navegador. Este prompt personalizado es un componente de tu aplicación. Debe probarse visualmente como cualquier otro componente — en todos los viewports, todos los temas, todos los contextos.
Pero el prompt nativo varía según el navegador y la versión. No controlas su apariencia, pero sí controlas lo que sucede alrededor: el contenido de la página de fondo, el posicionamiento de tus elementos, el comportamiento cuando el prompt empuja el contenido hacia abajo. Todo esto merece una verificación visual.
El modo standalone: la interfaz sin chrome del navegador
Cuando tu PWA está instalada y se lanza desde la pantalla de inicio, se abre en modo «standalone»: sin barra de direcciones, sin pestañas, sin botones de navegación del navegador. La aplicación ocupa toda la pantalla disponible (excepto la barra de estado del sistema).
Este cambio de entorno tiene implicaciones visuales directas.
El espacio disponible cambia. Sin la barra de direcciones, tu aplicación dispone de 50 a 80 píxeles adicionales en altura. Si tu layout se basa en alturas fijas o cálculos de viewport (100vh), el renderizado puede ser notablemente diferente en standalone frente al navegador.
La zona de safe area entra en juego. En dispositivos con notch o Dynamic Island, la zona de contenido segura no es la misma en modo standalone. Los elementos posicionados en la parte superior o inferior de la pantalla (headers fijos, barras de navegación, FABs) pueden quedar parcialmente ocultos si las safe areas no se gestionan correctamente.
La navegación cambia. Sin el botón «atrás» del navegador (especialmente en iOS), tu aplicación debe proporcionar su propia navegación. Si un usuario puede quedarse en una página sin forma de volver, es un bug UX grave — y la prueba visual puede detectarlo verificando la presencia sistemática de elementos de navegación.
Las interacciones con la barra de estado del sistema. El color de tu barra de estado (definido en el manifest o mediante la meta tag theme-color) debe armonizar con tu header. Un header blanco con una barra de estado negra crea una ruptura visual antiestética.
El Problema de las Pruebas Web Estándar
Solo prueban un estado
La gran mayoría de las suites de pruebas — incluidas las pruebas visuales — solo prueban el estado online en un navegador. Es el estado por defecto, el más simple de configurar y el más estable. Pero también es el estado que más se parece a un simple sitio web.
Si solo pruebas este estado, estás probando la versión menos exigente de tu PWA. Verificas que tu aplicación funciona en condiciones ideales. Es necesario, pero insuficiente.
Ignoran el ciclo de vida de la PWA
Una PWA tiene un ciclo de vida que los sitios web no tienen. La instalación, la actualización del Service Worker, la sincronización en segundo plano, la vuelta a estar online tras un período offline — cada una de estas transiciones puede provocar estados visuales inesperados.
Cuando el Service Worker se actualiza mientras el usuario usa la aplicación, puede aparecer un banner «Nueva versión disponible — Recargar». La apariencia de este banner, su posicionamiento, su interacción con el contenido — todo esto debe probarse.
Cuando la aplicación vuelve a estar online tras un período offline, los datos se sincronizan. Durante esta sincronización, la interfaz puede mostrar estados de carga, indicadores de progreso, conflictos de datos. Estos estados visuales transitorios suelen descuidarse y suelen estar rotos.
No reproducen el contexto standalone
Abrir tu PWA a pantalla completa en un navegador no es lo mismo que abrirla en modo standalone. Las dimensiones son diferentes, la gestión de las safe areas es diferente, el comportamiento del overscroll es diferente. Una prueba ejecutada en Chrome DevTools con un viewport simulado no reproduce fielmente el entorno real de una PWA instalada.
Cómo Probar Visualmente una PWA Correctamente
Mapea tus estados visuales
Antes de configurar tus pruebas, enumera explícitamente todos los estados visuales de tu PWA. Como mínimo, debes cubrir:
El estado online en modo navegador. Es tu baseline web estándar. Cada página, cada viewport.
El estado online en modo standalone. Las mismas páginas, pero en el contexto de instalación. Verifica las diferencias de layout relacionadas con la ausencia del chrome del navegador.
El estado offline — páginas cacheadas. Cuando el usuario accede a una página disponible en caché sin conexión, ¿qué ve? ¿Los datos están completos? ¿Las imágenes están presentes?
El estado offline — páginas no cacheadas. Cuando el usuario accede a una ruta no cacheada sin conexión, ¿la página de fallback es visualmente correcta? ¿Ofrece un camino de vuelta al contenido cacheado?
La transición de online a offline. ¿El banner offline aparece correctamente? ¿Los componentes dinámicos se degradan visualmente de forma elegante?
La transición de offline a online. ¿La resincronización es visible? ¿Los datos actualizados se muestran sin artefactos visuales?
El splash screen. En las plataformas objetivo (Android Chrome, iOS Safari, Samsung Internet), ¿el splash screen es visualmente correcto?
El prompt de instalación. ¿Tu prompt personalizado (si tienes uno) es visualmente correcto en todos los contextos?
Automatiza los cambios de estado de red
Para probar el estado offline, simula la pérdida de red programáticamente. El Chrome DevTools Protocol permite simular el modo offline, y herramientas como Playwright soportan nativamente la manipulación de condiciones de red.
La secuencia típica: cargar la página online, verificar visualmente, cortar la red, recargar o navegar, verificar visualmente el estado offline. Esta secuencia debe automatizarse y ser reproducible.
Prueba el modo standalone sin dispositivo físico
Usar la opción de lanzamiento de Chrome en modo «app» (ventana sin chrome del navegador) es el enfoque más pragmático. No es idéntico a una PWA realmente instalada, pero es lo suficientemente cercano como para detectar regresiones de layout relacionadas con la ausencia de la barra de direcciones.
Para las safe areas, verifica visualmente los elementos posicionados con env(safe-area-inset-top) o env(safe-area-inset-bottom) con los valores correspondientes a tus dispositivos objetivo.
Las Especificidades de iOS: Un Mundo Aparte
Digámoslo claramente: Safari en iOS es el navegador más problemático para las PWA. Y probablemente sea la plataforma más importante para tus usuarios.
A pesar de avances significativos desde iOS 16.4 (que introdujo las notificaciones push para las PWA), Safari sigue por detrás de Chrome en soporte PWA. El splash screen se gestiona de forma diferente. El modo standalone tiene comportamientos específicos. La gestión del viewport y de las safe areas es más estricta.
Esto significa que tus pruebas visuales deben incluir Safari iOS como objetivo explícito, no como algo secundario. Las diferencias de renderizado entre Chrome Android y Safari iOS para una misma PWA suelen ser sustanciales y sorprendentes.
Según los datos de StatCounter para 2025, Safari representa aproximadamente el 27 % del mercado mundial de navegadores móviles. Ignorar sus especificidades PWA es ignorar a una cuarta parte de tus usuarios potenciales.
Lo Que Delta-QA Aporta a las PWA
Delta-QA simplifica considerablemente la prueba visual de PWA gracias a su enfoque no-code. No necesitas escribir scripts para simular los diferentes estados de tu PWA — configuras tus escenarios visualmente.
La capacidad de Delta-QA para probar en diferentes viewports es particularmente relevante para las PWA, que deben funcionar igual de bien en una pantalla de smartphone en modo standalone que en una pantalla de escritorio en un navegador. Una sola herramienta cubre todo el espectro.
Y dado que las PWA se actualizan con frecuencia (las actualizaciones son transparentes, sin pasar por una app store), la cadencia de pruebas debe ser alta. La integración de Delta-QA en tu pipeline CI/CD garantiza que cada despliegue se verifica visualmente antes de llegar a tus usuarios.
FAQ
¿No son suficientes las pruebas visuales estándar para una PWA?
No. Las pruebas visuales estándar cubren el estado online en un navegador. Para una PWA, eso corresponde al estado menos representativo de la experiencia real del usuario. El estado offline, el modo standalone, el splash screen, el prompt de instalación — son estados visuales específicos de las PWA que las pruebas web estándar ignoran. Si solo pruebas el estado online, dejas la mayoría de los riesgos visuales de la PWA sin cubrir.
¿Cómo se simula el estado offline en pruebas automatizadas?
Puedes usar las capacidades del Chrome DevTools Protocol (CDP) para simular la pérdida de red programáticamente. Frameworks de pruebas como Playwright ofrecen métodos nativos para esto. La secuencia típica: carga la página normalmente, corta la red mediante la API, luego navega o recarga para observar el comportamiento offline. Captura screenshots en cada paso para la prueba visual.
¿Mi PWA necesita soportar offline para justificar pruebas visuales específicas?
Aunque tu PWA no funcione offline (estrategia «network only»), necesitas probar qué pasa cuando la red no está disponible. El usuario verá algo: una página en blanco, un error del navegador o tu página de fallback. Sea lo que sea, esa vista forma parte de la experiencia de usuario y merece una prueba visual.
¿Cuál es la diferencia entre probar una PWA y probar una aplicación móvil nativa?
Probar una aplicación nativa requiere simuladores o dispositivos físicos específicos de cada plataforma (iOS Simulator, Android Emulator). La prueba de una PWA puede realizarse en gran parte con navegadores de escritorio configurados en los viewports adecuados, lo que la hace más accesible y rápida. Sin embargo, ciertos aspectos (splash screen, safe areas, comportamiento standalone en iOS) requieren verificaciones en entornos reales o cercanos a lo real.
¿Cómo probar el splash screen si no tengo un dispositivo físico?
No puedes probar el splash screen real sin un dispositivo o emulador, ya que lo genera el navegador al lanzar la PWA instalada. Sin embargo, puedes probar sus componentes: verifica visualmente que los iconos del manifest son correctos en todos los tamaños requeridos, que el color de fondo es coherente y que las imágenes apple-touch-startup-image (para iOS) están presentes y tienen buena calidad.
¿Las PWA siguen siendo relevantes en 2026 con las app stores?
Absolutamente. Según un estudio de web.dev (Google), las PWA ofrecen tasas de conversión un 36 % superiores a las de los sitios web móviles clásicos, principalmente gracias a la velocidad de carga y a la experiencia offline. Con la mejora continua del soporte PWA en iOS y la apertura de la Unión Europea a navegadores de terceros en iPhone (Digital Markets Act), las PWA son más relevantes que nunca en 2026.
Para profundizar
- Rendimiento Web y Prueba Visual: El CLS Es un Problema Visual, No Funcional
- Prueba Visual React Native: El Móvil, el Hijo Olvidado de la Prueba Visual
Tus usuarios no distinguen entre una PWA y una aplicación nativa. Ven un icono en su pantalla de inicio, lo tocan y esperan que todo funcione — con o sin red, con o sin barra del navegador, con un splash screen profesional y transiciones fluidas.
Si desarrollas una PWA pero la pruebas como un sitio web, estás traicionando la promesa que hiciste al ofrecer la opción «Añadir a la pantalla de inicio». Las PWA son apps. Pruébalas como apps.