Acordar el alcance y la persona que decide
Comience con el brief aprobado, el identificador de la versión, el entorno de destino y las URL que se reemplazan. Nombre al aprobador del cliente, al operador de la versión de la agencia y a un sustituto para cada uno. Acuerde cuándo estarán disponibles y qué canal de comunicación conservará la decisión.
Prepare una bandeja de entrada de prueba controlada, datos de formulario sintéticos, cuentas de prueba permitidas y una carpeta de evidencias con acceso restringido. Decida qué comprobaciones se hacen en ensayo y cuáles requieren el destino en vivo. Establezca un umbral de bloqueo del lanzamiento antes de probar: por ejemplo, consultas perdidas, acceso de administrador roto o diferencias de datos inexplicadas requieren rechazo.
Escribir una pequeña cuadrícula de resultados observables
Use una fila por prueba, con un identificador estable. Divida las filas cuando se necesiten distintas personas o evidencias. Los ejemplos siguientes son criterios que debe adaptar, no un registro de aceptación completo. Añada columnas de probador, resultado real, referencia de evidencia y decisión del aprobador a la copia de trabajo.
Desplace horizontalmente para ver todas las columnas de la tabla.
| Área | Resultado esperado | Evidencia útil |
|---|---|---|
| Formularios | Una consulta sintética llega una vez al destino acordado; una entrada no válida recibe una explicación utilizable. | Referencia de envío y recibo redactado. |
| Redirecciones | Cada URL antigua acordada llega a su reemplazo previsto sin bucles. | URL de origen, cadena de estados y URL final. |
| Acceso | El editor del cliente puede publicar dentro del alcance; la administración restringida sigue no estando disponible. | Notas de prueba específicas por rol. |
| Trabajos programados | El host previsto ejecuta la tarea a la hora acordada y produce la salida esperada. | Registro del programador y referencia de salida. |
| Datos | Los registros, cargas y relaciones acordados sobreviven a la migración. | Hoja de comparación y comprobaciones funcionales seleccionadas. |
| Aprobación | El aprobador designado registra excepciones aceptadas, rechazadas o aceptadas explícitamente. | Decisión vinculada a la versión probada. |
Seguir un formulario más allá de su mensaje de éxito
Pruebe un envío vacío, una entrada no válida y una consulta sintética válida. Use el teclado para llegar a los campos, entender sus etiquetas, corregir errores y enviar. La guía de formularios del W3C explica que las entradas obligatorias necesitan una identificación clara y que la validación del navegador no sustituye la validación en el servidor. Incluya ambas en el alcance de prueba del desarrollador.
Después, verifique el resultado posterior acordado con su responsable. Un mensaje de éxito del navegador por sí solo no demuestra la recepción en una bandeja de entrada o CRM. Confirme los valores de los campos, el destino y la gestión de duplicados. Mantenga los datos personales fuera de las capturas de pantalla. Repita una tarea adecuada como editor del cliente y compruebe que se deniega una operación restringida.
Comprobar la ruta, no solo la página de destino
Acuerde una lista de URL antiguas a nuevas, incluyendo enlaces importantes de campaña y parámetros de consulta requeridos. Registre la cadena de estados HTTP además de la página alcanzada. MDN distingue entre redirecciones permanentes y temporales y documenta diferencias en cómo los códigos de redirección gestionan los métodos de solicitud. Por tanto, el envío de un formulario redirigido necesita su propia prueba; abrir el destino con una solicitud de página normal no es suficiente.
Rechace bucles, dominios inesperados y destinos faltantes. Evite incluir cadenas de consulta confidenciales en la evidencia.
Dar a las tareas en segundo plano y a los datos sus propias comprobaciones
Para cada tarea programada, registre su finalidad, host, identidad de ejecución, zona horaria, programación, salida esperada y persona que recibe los fallos. Durante el ensayo, redirija los mensajes salientes a un destino controlado. Establezca cuándo el host antiguo deja de ejecutar la tarea y cuándo el nuevo host pasa a ser responsable, para que una migración no deje dos programadores activos.
Defina el corte de datos y compare los totales de registros acordados, los valores de campos seleccionados y los archivos cargados. Abra registros representativos a través de la aplicación para comprobar relaciones y permisos. Los recuentos por sí solos no bastan: totales iguales pueden contener registros diferentes. Registre cualquier dato histórico excluido deliberadamente y obtenga la decisión del cliente.
Ejemplo: un lanzamiento de catálogo que debe esperar
En este escenario ficticio, una agencia está trasladando el catálogo y el formulario de consulta de un taller. El aprobador del cliente acepta el contenido y las comprobaciones de redirección, pero una consulta sintética llega a un buzón obsoleto. La importación nocturna del catálogo también sigue habilitada en el host antiguo. El resultado se rechaza para el lanzamiento, con ambos fallos asignados al operador de la versión.
El operador corrige el destinatario y la titularidad del programador, y luego aporta evidencia nueva para esas filas y repite las comprobaciones afectadas de formulario y datos. El aprobador revisa el mismo identificador de versión antes de cambiar la decisión. Un recorte menor de imagen puede seguir siendo una excepción explícita con un responsable y una fecha límite si el cliente está de acuerdo; el silencio no es aceptación.
Verificar la decisión y mantener visibles sus límites
Antes de cerrar, confirme que cada fila requerida tiene un resultado, que cada fila fallida tiene una resolución o una excepción registrada, y que la decisión del aprobador identifica la versión y la hora. Si la compilación o la configuración cambia después, reabra las comprobaciones afectadas. Guarde evidencia concisa con un periodo de retención acordado y mantenga los detalles de acceso en los sistemas seguros del equipo.
Esta lista de comprobación establece la aceptación del proyecto dentro de su alcance declarado. No establece conformidad de accesibilidad, garantía de seguridad ni disponibilidad futura. Organice una revisión especializada donde el proyecto la requiera. A continuación, traslade la versión aceptada, las excepciones abiertas y los operadores nombrados al registro de responsabilidad continuada.
Fuentes y revisión
Las referencias técnicas se verificaron en septiembre de 12, 2026. Los ejemplos son ejercicios de planificación; la documentación de software referenciada no establece capacidades de servicio de PrivateHostLab.