¿Está la web lista para publicarse? Una checklist de pruebas para la empresa

«¿Está lista la web?» normalmente recibe una respuesta subjetiva: parece que sí. Las pruebas sirven para sustituir esa sensación por una lista de comprobaciones hechas, cada una con un resultado y un responsable, y con una distinción clara entre los defectos que impiden la publicación y los que se corrigen después. Sirve tanto a la empresa como al proveedor, porque cierra el proyecto sin colas infinitas de avisos.

No es una revisión de diseño. No se discute si el color gusta: se verifica que los recorridos funcionen, que los contenidos digan la verdad y que las solicitudes lleguen a su destino.

Prueba recorridos, no páginas

Abrir todas las páginas una por una da una falsa seguridad: las páginas se ven, los recorridos se rompen. Un recorrido es una secuencia que un visitante real realiza de verdad.

• Busco tu nombre, llego a la home, busco un servicio, leo la ficha, pido información.
• Llego a una página interna desde un enlace recibido, sin pasar por la home: ¿entiendo dónde estoy y cómo seguir?
• Quiero el número de teléfono desde el móvil: ¿cuántos toques hacen falta para encontrarlo y marcarlo?
• Soy un cliente y busco el soporte o el área privada.

Cada recorrido hay que probarlo en al menos un móvil real y en un ordenador, no solo estrechando la ventana del navegador. El móvil tiene el teclado que cubre media pantalla, el dedo ancho como diez píxeles y una red que a veces no está: tres cosas que no se ven en un monitor de oficina. Prueba también con una conexión lenta y con el móvil girado.

El acta de pruebas

Una herramienta sencilla y suficiente: una tabla con una fila por prueba. Evita la discusión más frecuente de final de proyecto, «esto lo habíamos dicho» contra «no estaba en el alcance». Algunas filas de ejemplo.

Las columnas que importan son las dos últimas. Unas pruebas sin un nombre junto a cada fila no se hacen: se posponen hasta que alguien decide publicar de todos modos.

Contenidos, enlaces y destinos de las solicitudes

La parte menos técnica es la que genera más bochorno, porque afecta a lo que la empresa declara sobre sí misma.

• Textos de prueba que se han quedado en la página, imágenes genéricas en lugar de las tuyas, nombres de personas que ya no trabajan contigo.
• Contactos, horarios y datos societarios: hay que leerlos quien los conoce, no quien los ha maquetado.
• Documentos descargables: que sean la última versión y que no contengan tarifas o datos que no quieres que sean públicos.
• Enlaces internos y externos: los que van a webs de terceros hay que volver a probarlos, porque una web externa puede haber cambiado de dirección mientras trabajabais.
• Destinos de las solicitudes: cada formulario puede escribir a una cuenta distinta. Pruébalos todos, uno por uno, comprobando también el correo no deseado.
• Textos legales e informativos: no son contenido de relleno y no se copian de otra web.

Las llaves de casa: accesos, copias de seguridad, restauración

Antes de la publicación conviene aclarar quién posee qué. Ahora cuesta poco; dentro de tres años, con un proveedor distinto, puede bloquear todo un proyecto.

• El dominio a nombre de la empresa, con el acceso al panel de gestión en tus manos.
• Los accesos a la web, al espacio donde está alojada y a las herramientas de medición, existentes también a nombre de una persona interna y no solo del proveedor.
• Si están previstas copias de seguridad: dónde están, con qué frecuencia se hacen, hasta cuándo llegan hacia atrás y —la pregunta que nadie hace— quién ya ha probado a restaurar una.

Una copia de seguridad nunca restaurada es una hipótesis, no una garantía. La prueba se hace una vez, sobre una copia de trabajo, antes de necesitarla.

Bloqueante o aplazable

No todos los defectos impiden la publicación, y tratarlos todos como urgentes hace que la fecha se retrase sin motivo. Bastan tres niveles.

1. Bloqueante: la web dice algo falso, una solicitud no llega, una página importante no se abre, un dato confidencial es visible, un recorrido de contacto o de compra se interrumpe. No se publica.
2. Por corregir justo después: defectos visibles que no impiden usar la web, como un pie de foto equivocado, una imagen de calidad escasa, un espaciado fuera de sitio en un modelo de móvil.
3. Por valorar: peticiones surgidas durante las pruebas que en realidad son contenidos o funciones nuevas. Hay que escribirlas y discutirlas, no colarlas en el lanzamiento.

El tercer punto es el que salva el proyecto. Gran parte de los retrasos nace de peticiones nuevas presentadas como defectos.

Cuándo no se publica, y cuándo se publica de todos modos

Lo que esta guía no cubre

Aquí se trata la aceptación de una web antes de publicarla. Las pruebas de un proceso de gestión —datos migrados, permisos, procedimientos que sustituyen una forma de trabajar— siguen reglas distintas y requieren pruebas sobre los datos reales, no sobre un entorno de prueba. También los controles de accesibilidad y la recogida de requisitos antes de empezar se tratan en otro lugar.