Las pruebas de aplicaciones web (web application testing) son la verificación sistemática de aplicaciones que se ejecutan en el navegador — paneles SaaS, sistemas de e-commerce, herramientas en línea — en ocho dimensiones: lógica funcional, validación de formularios, compatibilidad entre navegadores, diseño responsive, rendimiento, seguridad y accesibilidad. Este artículo ofrece una lista de comprobación lista para copiar, con más de 40 verificaciones, para la aceptación previa al lanzamiento, la regresión de versiones y el smoke test de nuevas compilaciones.
Pruebas de apps web ≠ pruebas de sitios web
| Dimensión | Pruebas de sitio web | Pruebas de app web |
|---|---|---|
| Objeto típico | Web corporativa, landing pages, blog | Sistemas SaaS, paneles de administración, editores en línea |
| Profundidad de interacción | Navegación y envío de formularios | Sesiones con inicio de sesión, flujos de estado complejos, permisos, concurrencia |
| Enfoque de las pruebas | Contenido, SEO, aspecto visual, rutas de conversión | Lógica de negocio, corrección de datos, manejo de errores |
| Complejidad de estado | Baja (prácticamente sin estado) | Alta (sesiones, caché, múltiples roles) |
Si tu objetivo es una web de marketing, esta lista resulta demasiado exhaustiva: usa mejor la Website QA Checklist. Este artículo va dirigido a "aplicaciones" con inicio de sesión y lógica de negocio.
Antes de empezar a probar
- Define el alcance de las pruebas y la versión (registra el hash de commit o el número de build)
- Prepara una matriz de entornos: al menos 1 entorno de staging + un entorno de preverificación en producción
- Prepara una matriz de cuentas: usuario normal / administrador / sin iniciar sesión, al menos 1 cuenta de cada una
- Prepara los datos de prueba: valores normales + valores límite (cadenas muy largas, caracteres especiales, valores vacíos, archivos grandes)
- Elige la herramienta y el criterio de registro (plantilla de bugs: test case template)
La checklist de pruebas de aplicaciones web
A. Pruebas funcionales (flujos de negocio principales)
- Recorre de principio a fin el flujo registro → verificación por correo → inicio de sesión
- Restablece una contraseña olvidada e inicia sesión con la nueva
- Recorre una vez el camino feliz de cada flujo principal (comprar, crear, guardar)
- Prueba las ramas de excepción de cada flujo: cancelación a mitad, envío duplicado, recuperación tras perder la conexión
- Verifica el aislamiento de permisos: un usuario normal no accede a funciones de administrador (introduciendo la URL directamente)
- Comprueba la consistencia de datos: listas, detalles y contadores se actualizan de forma sincronizada tras cada acción
- Confirma que las páginas protegidas no son accesibles tras cerrar sesión (el botón atrás no salta la autenticación)
B. Validación de formularios y entradas
- Muestra un mensaje claro y bloquea el envío cuando falten campos obligatorios
- Valida formatos: correo, teléfono, fecha, rangos numéricos
- Prueba valores límite: longitud máxima, valor mínimo, 0, negativos, entradas larguísimas (1000+ caracteres)
- Comprueba que los caracteres especiales y los scripts (
<script>, emojis, fragmentos SQL) se tratan de forma segura - Evita envíos duplicados: un doble clic rápido en "Enviar" genera un solo registro
- Prueba la subida de archivos: restricciones de tipo, archivos enormes, archivos de 0 bytes, subidas interrumpidas
- Comprueba que el estado del formulario es coherente al usar atrás/adelante del navegador
C. Compatibilidad entre navegadores
- Chrome (última versión)
- Firefox (última versión)
- Safari (macOS + iOS)
- Edge (última versión)
- Vigila los puntos de diferencia habituales: selectores de fecha, descargas de archivos, comportamiento del scroll, maquetación CSS
D. Responsive y móvil
- Repasa los breakpoints: anchos de 1920 / 1366 / 768 / 375
- Opera la navegación, los modales y las tablas en el móvil (sin desbordamiento horizontal)
- Garantiza objetivos táctiles suficientemente grandes y alternativas táctiles para las funciones que dependen del hover
- Alterna entre vertical y horizontal (si aplica)
- Asegúrate de que los campos siguen visibles cuando aparece el teclado en pantalla
E. API y manejo de errores
- Abre los paneles Console y Network de DevTools, recorre los flujos principales y verifica que no haya errores en rojo
- Muestra un mensaje amable (no una pantalla en blanco ni un bloqueo) cuando una petición falla (sin conexión/500)
- Muestra estados de carga en las peticiones lentas; aplica debounce o cancela las peticiones duplicadas
- Guía con claridad al usuario cuando la sesión expira (redirige al login en lugar de fallar en silencio)
- Mantén la consola libre de excepciones no capturadas (Uncaught Error)
F. Rendimiento
- Cumple los objetivos de carga inicial (recomendado < 3s, LCP < 2.5s)
- Evita tirones en listas y páginas con muchos datos (prueba con volúmenes reales)
- Comprime las imágenes y usa lazy loading
- Vigila las fugas de memoria (la app se ralentiza de forma evidente tras un uso prolongado)
G. Fundamentos de seguridad
- Impide el acceso por URL o API a recursos protegidos sin sesión o sin permisos
- Transmite todos los datos sensibles por HTTPS en todo el sitio
- No muestres nunca las contraseñas en texto plano
- No incluyas tokens sensibles en las URL (o aplícales máscara y caducidad)
- No expongas stack traces ni detalles técnicos al usuario final en los mensajes de error
H. Accesibilidad y detalles
- Completa las acciones clave solo con el teclado (orden de Tab, Enter para enviar)
- Añade texto alt a las imágenes y asocia labels a los controles de formulario
- Mantén el contraste de color en WCAG AA o superior (4.5:1)
- Diseña los estados vacío, de carga y de error (nunca una pantalla en blanco)
Cómo registrar y dar seguimiento a los resultados
| Práctica | Qué significa |
|---|---|
| Adjuntar evidencia a cada defecto | Anota una captura señalando el punto de reproducción; graba la pantalla en los problemas de interacción |
| Capturar el contexto técnico automáticamente | Usa una herramienta que registre los errores de Console/Network (p. ej., BugCapturer) para no copiarlos a mano |
| Archivar de forma estructurada | Exporta la lista de defectos a Excel (ID/módulo/pasos/esperado/real/severidad/estado) |
| Hacer los resultados compartibles | Genera un enlace para compartir en lugar de enviar archivos cuando otros equipos deban confirmar |
La función de diagnóstico de BugCapturer resuelve los tres puntos intermedios de una vez: al hacer una captura o grabar la pantalla recopila automáticamente los errores de Console y Network, exporta un Excel de 12 columnas con un clic y genera enlaces para compartir sin instalación para desarrolladores o clientes. Los detalles están en la página de la función de diagnóstico y la estructura completa del informe, en How to Export Bug Reports to Excel.
Para la confirmación final antes del lanzamiento, organiza una ronda de pruebas de aceptación de usuario siguiendo la UAT Complete Guide y usa esta lista como hoja de ejecución.
FAQ
¿Cuánto tiempo llevan las pruebas de una aplicación web?
Depende del alcance: un smoke test de una versión nueva, 0,5–1 día; una regresión completa, 2–5 días; y un lanzamiento importante suele reservar 1–2 semanas (incluida la verificación de las correcciones). Recorrer los 8 grupos de esta lista toma unas 1–2 jornadas por persona.
¿Cómo repartir entre pruebas manuales y automatizadas?
Regla práctica: cubre primero A/B/C/D de forma manual (sobre todo en el primer lanzamiento) y, cuando se estabilicen, automatiza las rutas de regresión frecuentes (login, flujos principales). El grupo E (revisión de Console/Network) puede recopilarse con herramientas; la seguridad (G) conviene complementarla con escáneres profesionales y auditorías de código.
¿Qué relación hay entre esta lista y el plan de pruebas?
La lista responde "qué probar"; la plantilla de plan de pruebas (Test Plan Template) responde "quién prueba, en qué entorno, cuándo y con qué criterios de aprobación". Define primero el plan y luego ejecuta la lista: los dos documentos se usan juntos.
¿Cómo usa esta lista un equipo sin QA?
Reparte el trabajo: desarrollo autoevalúa A/B/E (lo técnico), producto acepta A/D (negocio y experiencia) y antes del lanzamiento se hace un bug bash conjunto de 2 horas (la organización, en la Bug Bash Guide). Registra todo con una plantilla que incluya capturas e información de diagnóstico para reducir el coste de comunicación.
Conclusión
La clave de las pruebas de aplicaciones web no es "esforzarse por probar mucho", sino cubrir todas las dimensiones y hacer cada resultado trazable: avanza por las ocho dimensiones —funcional, formularios, compatibilidad, responsive, errores, rendimiento, seguridad, accesibilidad— y archiva cada hallazgo como "captura anotada + diagnóstico de Console/Network + registro estructurado". Puedes copiar esta lista directamente en tu plan de pruebas como hoja de ejecución.
Lecturas recomendadas: Website QA Checklist · Test Plan Template · UAT Complete Guide