23 de octubre de 2026 · Redacción de tech-expert.moscow
Determinar primero qué debía entregarse exactamente
La expresión «base de datos operativa» puede referirse a cosas distintas: el esquema de las tablas, un conjunto de registros de prueba, una copia de los datos de producción o una instancia del sistema ya configurada. Por ello, la comprobación comienza por las especificaciones técnicas, los anexos al contrato, el procedimiento de entrega acordado y la correspondencia sobre la composición del resultado. Hace falta una referencia concreta: qué datos y funciones deben estar disponibles tras el despliegue, de qué periodo y en qué entorno.
Conviene elaborar una lista de los materiales esperados e indicar, para cada uno, el archivo, enlace o acceso efectivamente recibido. Se documentan por separado la fecha de entrega, la forma de recepción y la versión del proyecto. Esto ayuda a distinguir la ausencia de un componente de la imposibilidad de abrirlo o de una discrepancia con el contenido acordado. La mera existencia de una carpeta llamada backup no confirma que contenga una copia de seguridad adecuada.
El código fuente, el esquema y los datos cumplen funciones distintas
El código describe la lógica de la aplicación. El esquema de la base de datos define la estructura de almacenamiento. Las migraciones modifican esta estructura de forma sucesiva. Los datos iniciales pueden crear roles de usuario, estados, ajustes o catálogos. Los registros de producción contienen la información acumulada durante la explotación. Estas partes están relacionadas, pero una no sustituye a otra.
Por ejemplo, las migraciones pueden crear correctamente tablas vacías y, después, la aplicación puede mostrar la página de inicio de sesión. Esto aún no confirma que se hayan transferido los documentos, el historial de operaciones y los archivos. También puede suceder lo contrario: se entregaron los datos, pero la versión del código espera otros campos. En ese caso, la causa del error está relacionada con la compatibilidad de los conjuntos, y no necesariamente con la ausencia de la base de datos.
Qué componentes comprobar junto con la base de datos
- Contenido de la exportación. Esquema, registros, secuencias, funciones necesarias y otros objetos; restricciones a determinadas tablas o periodos.
- Versiones. Sistema gestor de bases de datos, extensiones, entorno de ejecución de la aplicación y versión documentada del código fuente.
- Usuarios y permisos. Qué roles necesita la aplicación y qué permisos prevén las instrucciones de instalación.
- Almacenamiento de archivos. Documentos cargados, imágenes y otros objetos a los que hace referencia la base de datos.
- Configuración y dependencias. Direcciones de servicios, colas de tareas, planificador, índice de búsqueda y requisitos de las integraciones externas.
- Instrucciones. Procedimiento de compilación, restauración, arranque y comprobación; lista de parámetros de entorno admitidos.
Los secretos y las contraseñas de producción no deben incluirse en correspondencia de acceso público ni publicarse junto con el código fuente. Para el estudio se acuerda la transmisión protegida de la información necesaria o una comprobación en un entorno controlado. Si se utiliza una copia anonimizada, es importante describir qué información se ha sustituido y si esto puede afectar a la función comprobada.
Por qué la existencia de un archivo SQL no equivale a una restauración correcta
El formato y los parámetros de exportación son importantes. Por ejemplo, en PostgreSQL una exportación ordinaria de una sola base de datos no incluye todos los objetos compartidos del clúster: los roles y los espacios de tablas requieren un tratamiento separado. Una exportación que contiene solo el esquema no incluye registros de usuario. Por ello, el tamaño del archivo comprimido o la extensión del archivo solo ofrecen información preliminar sobre la composición de la entrega.
La comprobación de la restauración debe tener en cuenta los registros y la finalización de la operación. Si la herramienta continuó ejecutándose después de producirse errores, algunos objetos pudieron quedar sin restaurar. Que la interfaz se inicie tampoco sustituye a la comprobación de los datos. Se necesitan acciones de control acordadas de antemano: abrir un documento concreto, encontrar un registro de un periodo conocido, realizar un cálculo o generar un informe con los datos de partida esperados.
Cómo realizar la comprobación conservando los materiales originales
- Conservar el conjunto recibido en su estado original, elaborar un inventario de archivos y registrar las circunstancias de recepción.
- Crear una copia de trabajo independiente para el estudio. No utilizarla para sustituir el sistema de producción activo.
- Documentar las características del entorno de pruebas y compararlas con los requisitos del proyecto.
- Comprobar las instrucciones de restauración, los errores, las advertencias y los objetos realmente creados.
- Ejecutar los escenarios acordados y registrar los resultados de cada paso, incluidos los datos introducidos.
- Enumerar por separado las acciones para corregir o completar el conjunto y comprobar su efecto sobre el resultado.
Antes de ejecutar scripts de instalación y volcados desconocidos, es necesario evaluar técnicamente su contenido y la forma segura de ejecutarlos. La restauración se realiza en un entorno dedicado con accesos limitados. Esto también permite distinguir las propiedades del conjunto entregado de las particularidades del servidor en funcionamiento, donde pueden haberse acumulado cambios posteriores a la entrega.
Cómo describir las discrepancias detectadas
En lugar de una observación general como «la base de datos no funciona», conviene preparar una tabla con la función esperada, la condición inicial, el material comprobado, la secuencia de acciones, el resultado real y el registro que lo acredita. Si no se abren los archivos adjuntos, deben comprobarse tanto los registros de la base de datos como la existencia de los archivos correspondientes, sus rutas y sus permisos de acceso. Si falta el historial, hay que determinar qué periodo abarca la copia aportada.
Cada conclusión se vincula a una versión concreta de los materiales. El arranque correcto tras añadir nuevos archivos no demuestra automáticamente que el conjunto inicial estuviera completo. Del mismo modo, un fallo en una versión inadecuada del servidor no confirma por sí solo un defecto del código entregado. El estudio debe mostrar las condiciones en las que se observa el resultado.
Qué materiales preparar para el perito
Entregue las especificaciones técnicas, el inventario de entrega, el archivo del código fuente o el acceso acordado al repositorio, la copia recibida de la base de datos, las instrucciones y los mensajes de error. Adjunte una lista de los escenarios que antes funcionaban o que están previstos en los requisitos, e indique qué lo acredita. Si se mantiene el acceso al servidor anterior, acuerde previamente cómo documentar su estado.
Las sumas de comprobación ayudan a verificar que los archivos no se han modificado entre las etapas de conservación y estudio. Por sí solas no acreditan la autoría, la fecha de creación ni la conformidad del conjunto con el contrato. El estudio técnico permite determinar la composición, la compatibilidad y la reproducibilidad del funcionamiento a partir de los materiales aportados; valorar las consecuencias contractuales exige examinar por separado los documentos y las circunstancias de la controversia.
Preguntas para el estudio
- ¿Qué componentes de software y datos contiene el conjunto entregado y qué materiales faltan para comprobar las funciones acordadas?
- ¿Son compatibles entre sí las versiones del código fuente, el esquema de la base de datos y los datos aportados?
- ¿Es posible desplegar el sistema siguiendo las instrucciones entregadas en el entorno previsto en las especificaciones técnicas?
- ¿Qué errores concretos se producen durante la restauración y la ejecución de los escenarios de control, y cuáles son sus causas técnicas?
- ¿Qué componentes o acciones adicionales se necesitan para reproducir las funciones previstas?