Una lista de pruebas web facilita la verificación sistemática; no promete encontrar todos los defectos. Su valor consiste en que el equipo comprenda el alcance, los resultados esperados y el riesgo restante. Una sola lista no puede servir igual de bien a un sitio de noticias, un portal bancario y un panel de administración interno.
Adapta los elementos al producto y a la entrega antes de ejecutar. Cambiar un formulario de pedidos exige una profundidad distinta de corregir un texto del pie de página. Las comprobaciones siguientes ofrecen una base: selecciona las aplicables y añade riesgos específicos del cambio.
Prepara el contexto de prueba
Registra la versión, el entorno, las áreas modificadas, los roles, los datos de prueba y los navegadores admitidos. Identifica el recorrido crítico: ¿qué resultado lleva a los usuarios al sitio y qué fallo sería especialmente costoso?
Cada elemento necesita un resultado y evidencias. Usa los estados «aprobado», «defecto», «bloqueado», «no probado» y «no aplicable», con explicaciones. Una prueba omitida no cuenta como aprobada. Prepara un entorno y datos seguros para pagos, correos y eliminaciones de prueba.
Comprueba la carga y la navegación
- →Abre la página principal y las páginas clave directamente por URL: se carga el contenido correcto y funcionan los recursos necesarios.
- →Actualiza una página anidada: servidor y cliente conservan la ruta correcta sin errores inesperados.
- →Navega hacia atrás y adelante: la UI restaura un estado coherente y no repite accidentalmente una acción.
- →Abre una dirección inexistente: una página de error clara permite continuar y la respuesta HTTP se corresponde con la finalidad del recurso.
- →Comprueba menús, enlaces internos y navegación a servicios externos: no hay callejones sin salida, dominios incorrectos ni bucles de redirección.
Considera tanto las sesiones nuevas como las existentes. Un sitio recién abierto y una pestaña que lleva mucho tiempo abierta pueden recibir distintas versiones de recursos y estados.
Comprueba el escenario principal de negocio
Recorre el flujo completo desde la entrada hasta el resultado y verifica después que se haya guardado realmente. Un mensaje de «éxito» por sí solo no confirma un cambio de datos.
En una tienda significa encontrar un producto, usar el carrito, finalizar la compra y consultar el pedido. En una base de conocimiento significa encontrar y leer un artículo, seguir contenido relacionado y obtener una URL correcta para compartir. Usa roles y datos realistas: un administrador puede eludir restricciones que afectan a usuarios normales.
Comprueba formularios y datos
- →Los valores vacíos, habituales y límite se gestionan según el contrato; los errores ayudan a corregir la entrada.
- →El botón y Enter provocan un envío coherente y los clics repetidos no duplican una operación.
- →Tras el rechazo del servidor, se conservan los valores válidos y hay una forma clara de reintentar.
- →Los textos largos, caracteres cirílicos, distintas configuraciones regionales y formatos de fecha no corrompen los datos.
- →Las cargas y descargas de archivos cumplen los requisitos de tipo, tamaño, nombre y acceso.
Compara los datos introducidos, la solicitud, la respuesta y el estado recuperado después. Esta cadena ayuda a identificar pérdidas de precisión o normalizaciones inadvertidas.
Comprueba inicio de sesión, roles y sesiones
Confirma que iniciar y cerrar sesión, la caducidad y la reautenticación siguen la política del producto. Prueba una URL protegida sin iniciar sesión y una operación con un rol sin el permiso necesario.
Con cuentas preparadas, comprueba el acceso al objeto de prueba de otro usuario mediante UI y API. Ocultar un botón no sustituye el control de acceso del servidor. Tras cambiar de usuario, la aplicación no debe mostrar datos de la cuenta anterior desde su propio estado ni desde una caché utilizada incorrectamente.
Comprueba errores, comportamiento de red y recuperación
Ralentiza la red, interrumpe una solicitud, reproduce un error de servidor previsto y devuelve una respuesta vacía. Espera un estado claro, un indicador de carga que termine y una forma definida de continuar.
Los resultados inciertos son especialmente importantes: el servidor puede haber guardado un pedido sin que el cliente reciba la respuesta. Reintentar no debe crear silenciosamente un segundo pedido. Comprueba la coherencia del servidor y la protección prevista contra duplicados. Usa Console y Network para diagnosticar, pero evalúa el resultado por el comportamiento y los datos del producto.
Comprueba presentación y accesibilidad
Selecciona navegadores y tamaños de la matriz de compatibilidad. Completa la acción crítica en una ventana estrecha, con contenido largo y zoom aumentado. Los paneles fijos y el teclado no deben cubrir las acciones necesarias.
Recorre el flujo con teclado; comprueba foco visible, etiquetas de campos, errores comprensibles y nombres accesibles de botones. Usa un lector de pantalla cuando sea necesario. Las comprobaciones automáticas aportan señales adicionales, pero no demuestran que todos los procesos sean accesibles.
Comprueba visibilidad pública y ajustes de entrega
En un sitio público, comprueba título, descripción, canonical, reglas de robots, sitemap y redirecciones esperadas. En un servicio privado importan más las restricciones de acceso correctas. Evita aplicar requisitos de indexación a las áreas privadas de cuentas.
Comprueba la configuración de producción: dominios de API, enlaces, recursos y ausencia de stubs de prueba o secretos de diagnóstico. Tras desplegar, realiza una prueba smoke breve con datos autorizados. Limita las pruebas de carga y destructivas al entorno designado y al alcance acordado previamente.
Ejemplo práctico: entrega del proceso de compra
Supongamos que cambiaron el formulario de dirección y el cálculo de entrega. Prioriza completar la compra, los límites de la dirección, el cambio de método de entrega y el reintento tras agotarse el tiempo.
- 1.Crea un pedido de prueba con una dirección habitual. Espera un registro con la dirección, el importe y el método de entrega correctos.
- 2.Introduce una dirección larga en un teléfono y corrige un error. Los mensajes y el botón deben seguir siendo accesibles con el teclado abierto.
- 3.Cambia la dirección antes de terminar el cálculo. Debe aplicarse la última selección, no una respuesta retrasada.
- 4.Repite la confirmación tras simular un fallo de respuesta. Espera un estado coherente sin duplicados.
- 5.Comprueba la consulta del pedido con otro rol de prueba. Deben aplicarse las reglas de acceso.
Selecciona los elementos restantes según las dependencias afectadas y el historial de defectos, no simplemente para completar toda la lista.
Finalizar la ejecución
En el informe, vincula los defectos a los elementos de la lista e indica entornos cubiertos, bloqueos y áreas sin probar. Distingue «no se encontraron defectos conocidos» de «no hay riesgo»: las pruebas no pueden demostrar lo segundo.
Los errores habituales incluyen aplicar la misma profundidad a todas las entregas, omitir resultados esperados y marcar en verde comprobaciones bloqueadas. Una buena lista permite decidir sobre una entrega a partir de evidencias y limitaciones declaradas.
Lecturas adicionales
- →MDN: introducción a las pruebas entre navegadores
- →W3C WAI: comprobaciones sencillas
- →OWASP: guía de pruebas de seguridad web
- →MDN: caché HTTP
Una hoja de entrega web basada en evidencias
Usa una tarea concreta, como enviar un formulario de contacto ficticio. Acuerda las reglas de campos, el comportamiento de éxito y los navegadores admitidos antes de probar. Las filas siguientes especifican observaciones; forman una hoja compacta para la entrega, no una auditoría completa de seguridad o accesibilidad. Registra los resultados reales por separado de las expectativas.
Área Acción Observación esperada Evidencias que recopilar
Funcionalidad Enviar un formulario válido Un envío aceptado y confirmación clara ID de solicitud + UI
Validación Enviar sin el correo obligatorio Error específico; sin éxito; solicitud inválida gestionada según contrato UI + registro de solicitudes
Teclado Completar la tarea con Tab/Shift+Tab/Enter Foco visible; controles accesibles; sin trampas de teclado Vídeo
Etiquetas Inspeccionar nombres accesibles de entradas El nombre describe su objetivo; error asociado a su campo Árbol de accesibilidad
Diseño adaptable Usar tamaños estrechos/amplios acordados Sin controles recortados; contenido utilizable Tamaño de ventana + captura
SEO Obtener el HTML de la página pública Idioma, título, canonical y política de indexación correctos Encabezados + extracto HTML
Red Interrumpir antes/después del envío Sin falso éxito; recuperación segura sin duplicar el envío Traza de red
Datos Leer el envío aceptado Los valores guardados coinciden con la entrada y la política de acceso Evidencia del registro sin datos sensiblesEsta observación de ejemplo es hipotética: si el botón muestra «Sent» y la solicitud devuelve un error del servidor, registra el estado, la marca de tiempo y el estado de la UI; no afirmes que el mensaje quedó guardado. A la inversa, que se agote el tiempo no demuestra que el servidor rechazara la escritura. Aclara el resultado antes de reintentar.
Las herramientas de QA Hub pueden ayudar con evidencias concretas: el analizador de URL explica parámetros de consulta, el formateador JSON hace legible la estructura de respuestas, el comparador JSON contrasta cuerpos esperados y reales y los códigos HTTP sirven de referencia. No deciden si se cumple un requisito del producto. Termina indicando fallos conocidos, alcance sin probar, responsables y una decisión sobre el riesgo de la entrega.