≡En resumen
- El web testing cubre mucho más que «que no dé error»: funciones, navegadores, velocidad, accesibilidad y seguridad.
- Las pruebas end-to-end simulan a un usuario real en el navegador; Playwright, Cypress y Selenium son las herramientas más usadas.
- Automatiza lo repetitivo y crítico (login, carrito, formularios) y deja la exploración y la usabilidad a personas.
- Las Core Web Vitals y las WCAG 2.2 dan umbrales objetivos para probar rendimiento y accesibilidad.
- Probar no termina al publicar: cada actualización de plugins, tema o código necesita su regresión.
01 ¿Qué es el web testing?
Es una parte del quality assurance (QA) aplicada a la web, que tiene retos propios: decenas de combinaciones de navegador, sistema y tamaño de pantalla, contenido que cambia a diario, dependencias externas (pagos, analítica, chat) y usuarios que llegan con conexiones lentas o tecnologías de apoyo.
Qué se prueba
Que cada función hace lo que debe, se ve bien, carga rápido, es accesible y no expone datos.
Cuándo
Durante el desarrollo, antes de cada publicación y de forma periódica en producción.
Quién
Desarrolladores (pruebas unitarias), perfiles QA (funcionales y E2E) y usuarios reales (usabilidad).
02 Tipos de pruebas web
| Tipo | Qué comprueba | Ejemplo |
|---|---|---|
| Funcional | Que formularios, enlaces, búsquedas y procesos hacen lo previsto | El formulario de contacto llega al CRM |
| Cross-browser y dispositivos | Que se ve y funciona igual en Chrome, Safari, Firefox, Edge y móviles | El menú se abre en Safari de iPhone |
| Rendimiento y carga | Velocidad de carga y comportamiento con muchos usuarios | La web aguanta el tráfico del Black Friday |
| Accesibilidad | Uso con teclado, lector de pantalla, contraste y textos alternativos | Se puede comprar sin ratón |
| Seguridad | Vulnerabilidades como inyección, control de acceso roto o configuraciones inseguras | Un usuario no puede ver pedidos ajenos cambiando la URL |
| Regresión | Que lo que funcionaba sigue funcionando tras un cambio | Actualizar un plugin no rompe el checkout |
| Usabilidad | Que las personas entienden y completan las tareas | Cinco usuarios intentan reservar una cita |
La compatibilidad entre navegadores sigue siendo fuente de errores, sobre todo en Safari para iOS, donde todos los navegadores del iPhone han usado históricamente el motor WebKit. Las pruebas con personas reales se explican en la ficha de test de usabilidad.
03 Herramientas E2E: Playwright, Cypress y Selenium
Las pruebas end-to-end (E2E) automatizan un navegador para recorrer la web como lo haría un usuario. Las tres herramientas de referencia son de código abierto y en septiembre de 2026 seguían publicando versiones con regularidad: Playwright 1.63, Cypress 16.1 y Selenium 4.49.
| Herramienta | Origen y licencia | Navegadores | Puntos fuertes |
|---|---|---|---|
| Playwright | Microsoft, Apache 2.0 | Chromium, Firefox y WebKit | Esperas automáticas, varias pestañas y dominios, trazas y vídeo; API en JS/TS, Python, Java y .NET |
| Cypress | Cypress.io, MIT | Chrome, Edge, Electron y Firefox | Muy buena experiencia de depuración en tiempo real; centrado en JavaScript |
| Selenium | Proyecto de código abierto desde 2004, Apache 2.0 | Todos los principales vía WebDriver | Estándar W3C WebDriver, muchos lenguajes y granjas de navegadores |
1) Abre la página de inicio. 2) Busca «zapatillas». 3) Entra en el primer producto y elige la talla 42. 4) Añade al carrito. 5) Comprueba que el contador del carrito muestra «1» y que el total incluye el IVA. En Playwright eso son unas diez líneas de código que se ejecutan en cada cambio, en los tres motores de navegador, en menos de un minuto.
04 Pruebas de rendimiento y Core Web Vitals
Google mide la experiencia de carga con las Core Web Vitals y publica umbrales concretos: un LCP de 2,5 segundos o menos, un INP de 200 milisegundos o menos (sustituyó al FID en marzo de 2024) y un CLS de 0,1 o menos. Para comprobarlo se combinan datos de laboratorio (Lighthouse) y de usuarios reales (informe CrUX o Search Console). Los detalles de medición están en la ficha de test de velocidad.
| Métrica | Qué mide | Umbral bueno |
|---|---|---|
| LCP | Cuándo se pinta el elemento principal | ≤ 2,5 s |
| INP | Rapidez de respuesta a las interacciones | ≤ 200 ms |
| CLS | Saltos inesperados del diseño | ≤ 0,1 |
Las pruebas de carga (con herramientas como k6 o JMeter) van un paso más allá: simulan cientos o miles de usuarios a la vez para encontrar el punto en que el servidor se degrada. Si los resultados son malos, el trabajo de optimización de la velocidad web suele empezar por imágenes, caché y scripts de terceros.
05 Pruebas de accesibilidad y de seguridad
La referencia para probar accesibilidad son las pautas WCAG 2.2 del W3C. Las herramientas automáticas (axe, Lighthouse, WAVE) detectan problemas como contrastes insuficientes o imágenes sin texto alternativo, pero una parte importante de los criterios exige revisión manual: navegar solo con teclado y probar con un lector de pantalla. En España y la UE, además, la Ley Europea de Accesibilidad obliga a muchas tiendas online y servicios digitales; lo explicamos en qué exige la ley de accesibilidad web.
- ✓Navega por toda la web solo con el teclado y comprueba que el foco se ve.
- ✓Pasa un analizador automático de accesibilidad en las plantillas principales.
- ✓Revisa cabeceras de seguridad (HTTPS, HSTS, Content-Security-Policy).
- ✓Prueba permisos: usuario anónimo, cliente y administrador.
- ✓Escanea dependencias y plugins en busca de vulnerabilidades conocidas.
06 Cómo organizar el testing de una web paso a paso
-
1
Lista los recorridos críticos
Identifica qué no puede fallar nunca: comprar, pedir presupuesto, reservar, iniciar sesión.
-
2
Define la matriz de navegadores
Elige navegadores y dispositivos según tu analítica real, no según suposiciones.
-
3
Automatiza lo crítico
Escribe pruebas E2E para los recorridos clave y ejecútalas en cada cambio desde tu integración continua.
-
4
Añade controles de calidad
Incorpora Lighthouse, un analizador de accesibilidad y un escáner de dependencias al mismo proceso.
-
5
Prueba en un entorno de staging
Valida cada actualización en una copia de la web antes de publicarla.
-
6
Vigila producción
Monitoriza disponibilidad, errores de JavaScript y Core Web Vitals de usuarios reales.
En webs con WordPress, la mayoría de roturas llegan con actualizaciones de plugins o del tema; por eso las pruebas de regresión forman parte de un buen plan de mantenimiento web. En proyectos a medida, las integramos desde el primer día en el trabajo de nuestra empresa de desarrollo web.
Preguntas frecuentes sobre Web Testing
Es el conjunto de pruebas que comprueban que una web funciona, se ve bien en todos los navegadores, carga rápido, es accesible y es segura.
Las principales son funcionales, de compatibilidad entre navegadores, de rendimiento y carga, de accesibilidad, de seguridad, de regresión y de usabilidad.
Depende del equipo. Playwright destaca por cubrir Chromium, Firefox y WebKit con esperas automáticas; Cypress por su depuración; Selenium por su compatibilidad con muchos lenguajes.
Las automatizadas repiten comprobaciones rápidas y fiables en cada cambio; las manuales detectan problemas de criterio, diseño y usabilidad que un script no ve.
Con una matriz basada en tu analítica y pruebas en navegadores reales o emulados, ya sea con Playwright en local o con servicios de granjas de navegadores en la nube.
En cada cambio de código o actualización de plugins, y de forma periódica en producción con monitorización de disponibilidad y rendimiento.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗