Cómo probar PrestaShop 9.2 RC1 en un entorno de pruebas aislado

Un entorno de versión candidata debe ser lo bastante realista para revelar incompatibilidades y estar lo bastante aislado para que un error no pueda convertirse en un pedido, envío o campaña reales. Copiar una base de datos de producción a otro nombre de host no logra por sí solo ese aislamiento.

El anuncio de RC1 indica a los testers que usen una instalación nueva y señala que Update Assistant no ofrece una ruta de actualización de beta a RC1 ni de RC1 a la versión final. A fecha de 26 de septiembre de 2026, se trata de una evaluación de una versión preliminar, no de un ensayo de actualización de producción con una ruta de continuación garantizada. Instrucciones oficiales de prueba de RC1.

El procedimiento siguiente crea un entorno desechable y una pista de pruebas. No explica cómo migrar una tienda de la versión 8 a la versión 9.

Para cada dependencia incorporada al entorno de pruebas, solicite pruebas de compatibilidad del módulo con PrestaShop 9.2 en vez de confiar únicamente en una versión máxima declarada.

Aislar los efectos secundarios antes de introducir los datos de la tienda

Enumere todos los sistemas con los que la tienda puede contactar: entrega de correo, proveedores de pago, servicios de envío, plataformas de marketing, servicios de búsqueda, analítica, conexiones ERP e integraciones programadas. Incluya las devoluciones de llamada y los procesos en segundo plano, no solo los ajustes visibles de los módulos.

Cree credenciales separadas o configuraciones de sandbox documentadas cuando estén disponibles. Dirija el correo a un receptor de pruebas. Impida que las operaciones de envío y marketing lleguen a destinatarios reales. Si una integración carece de un sandbox seguro, desactive sus efectos externos y documente qué comportamiento no puede probarse.

Use controles de acceso para mantener privado el entorno. Las directivas para buscadores por sí solas no restringen el acceso ni protegen los datos de clientes. Limite quién puede acceder a la tienda de pruebas y quién puede administrarla.

Compruebe también los eventos entrantes. Una URL de devolución de llamada copiada o una cuenta de proveedor compartida con producción pueden hacer que un entorno consuma eventos destinados a otro. Dé una identidad clara a cada entorno y verifique la configuración del proveedor antes de habilitar una integración.

Si después usa datos derivados de producción, minimícelos y anonimícelos mediante su proceso aprobado. Un catálogo realista rara vez necesita correos, direcciones o credenciales de clientes reales. Conserve la coherencia relacional para que la anonimización no genere fallos artificiales.

Demostrar que el material de recuperación es utilizable

Las copias de seguridad siguen siendo relevantes aunque la versión candidata empiece desde cero. Conserve el material de recuperación de la tienda estable mediante su proceso operativo habitual y capture por separado la base de referencia de la candidata para poder restablecer los tests.

Una instantánea utilizable combina la base de datos con los archivos y la configuración correspondientes. Las versiones de módulos, las referencias multimedia y el estado de la base de datos pueden volverse incoherentes si se capturan en momentos sin relación. Registre qué contiene la instantánea y cómo se creó.

Restaure la base de referencia de la candidata en otra instancia desechable o punto de restablecimiento antes de confiar en ella. Verifique que se abre la interfaz de administración, que existen los productos de prueba y que los efectos externos siguen aislados. La existencia de un archivo de copia de seguridad no demuestra que pueda restaurarse correctamente.

No use la instalación candidata para sobrescribir una base de datos de producción con el fin de «probar el esquema». Mantenga las credenciales y rutas de la base de datos del experimento lo bastante diferenciadas para detectar con más facilidad los errores habituales del operador.

Escriba el procedimiento de restablecimiento antes de los tests destructivos. Un restablecimiento predecible hace reproducibles las pruebas posteriores y evita contaminar progresivamente cada test con los datos del anterior.

Establecer una base de referencia limpia de RC1

Use el artefacto oficial de la versión adecuado para la distribución que pretende evaluar. Registre el artefacto descargado, la versión y cualquier verificación de suma de comprobación disponible. Distinga un paquete de instalación de una copia del código fuente que requiere su propio proceso de compilación.

Instale en una base de datos nueva. Registre las versiones del entorno de ejecución y de la base de datos sin convertir la evaluación en un ejercicio genérico de alojamiento. El objetivo es saber qué se ha probado y compararlo con el entorno compatible previsto.

Antes de añadir personalizaciones, realice una breve comprobación de referencia: acceso al Back Office, vista de un producto, creación de un carrito y un pedido sencillo en sandbox si la configuración de pago instalada lo permite. Guarde la instantánea resultante y el inventario de versiones.

Registre explícitamente los indicadores de funcionalidades. Su estado predeterminado forma parte del entorno de pruebas. Si un caso posterior habilita una página migrada u otra función experimental, el informe debe indicarlo en lugar de atribuir todo el comportamiento únicamente a la versión del núcleo.

Nunca suponga que la instalación correcta de la candidata crea una ruta de actualización a la versión final. Trate su base de datos como datos de prueba desechables salvo que instrucciones oficiales posteriores establezcan expresamente otro proceso compatible.

Introducir dependencias en grupos controlados

Añada el tema y los módulos según los flujos a los que afectan. Una secuencia útil es presentación de la tienda, dependencias del proceso de compra, extensiones del Back Office e integraciones en segundo plano. Así resulta más fácil atribuir un fallo recién introducido.

Mantenga un registro de dependencias:

Si un componente no declara compatibilidad con la versión 9.2, señale esa incertidumbre. Puede investigarlo igualmente en pruebas, pero la ausencia de fallos en un test corto no es un compromiso de soporte de su mantenedor.

Las sobrescrituras personalizadas merecen especial atención. Registre qué cambian y por qué. Una personalización que deje de activarse puede eliminar silenciosamente una regla de negocio mientras la página sigue funcionando.

Cubrir el ciclo de vida de la tienda más allá del proceso de compra

El proceso de compra es crítico, pero no es toda la tienda. Una candidata puede aceptar un pedido y aun así fallar durante una importación, una edición administrativa o una conciliación programada.

Para las operaciones de catálogo, cree y edite productos, combinaciones y contenido traducido relevantes para la tienda. Use restricciones representativas y valores inusuales pero válidos. Para las importaciones, pruebe un lote pequeño, un fallo de validación y un reinicio en vez de cargar inmediatamente todo el catálogo.

Para las tareas programadas, confirme el contexto de tienda previsto y que los procesos de prueba no puedan llamar a servicios de producción. Ejecute una tarea dos veces si la ejecución duplicada supone un riesgo relevante. Observe si la segunda ejecución reconoce de forma segura el trabajo ya completado.

Para las API, conserve muestras de esquemas y respuestas de las operaciones que realmente consumen sus clientes. No suponga que todos los puntos de acceso están instalados solo porque la versión del núcleo sea nueva. Registre las versiones de los módulos de recursos junto a la del núcleo.

Para multitienda, use valores de prueba distintos en al menos dos tiendas e inspeccione ambas después de una escritura. Para las rutas y el contenido traducidos, pruebe los idiomas que el negocio publica realmente. Incluya un idioma del empleado distinto del predeterminado cuando las extensiones del Back Office usen etiquetas o mensajes traducidos.

Termine con las operaciones posteriores al pedido: generación de documentos, cambios de estado, gestión de envíos y transferencia a la integración externa. Cada caso debe tener un resultado de negocio esperado, no solo una pantalla esperada.

Informar de las regresiones para que otra persona pueda reproducirlas

Un informe útil contiene un conjunto de prueba mínimo, versiones exactas, indicadores activos, secuencia de acciones, resultado esperado y resultado real. Adjunte registros depurados o capturas de pantalla solo cuando aclaren el problema.

Intente reproducir el fallo desde la base de referencia limpia con el conjunto mínimo de dependencias necesarias. Esto no significa retirar el módulo afectado si es esencial para el problema. Significa eliminar configuraciones ajenas que ocultan el desencadenante.

Distinga una regresión de una suposición no compatible. Si una integración privada depende de un selector indocumentado, el informe debe indicar esa dependencia. Si una operación documentada devuelve un resultado incorrecto en una instalación limpia, muéstrelo directamente.

Mantenga la información sensible de seguridad fuera de los informes públicos de incidencias. Un ejemplo sintético mínimo suele ser más útil que un extracto de base de datos de producción. Siga el canal de comunicación adecuado del proyecto para los problemas de seguridad en vez de publicar detalles de explotación en un informe ordinario de compatibilidad.

Conservar una ficha de los datos de prueba

Para cada conjunto de prueba importado, registre su origen, fecha de preparación y finalidad. Anote qué datos se sintetizaron, qué relaciones se conservaron y qué identificadores externos se sustituyeron. Esto ayuda a explicar los fallos causados por un conjunto poco realista en lugar de por la candidata.

Un catálogo con todos los productos en stock no puede probar el comportamiento de artículos no disponibles. Un conjunto de clientes de un único país no puede revelar reglas de entrega dependientes del destino. Una copia multitienda que solo contenga valores compartidos no puede demostrar el aislamiento. Seleccione diferencias representativas deliberadamente en lugar de copiar volumen por sí mismo.

Guarde la ficha del conjunto de prueba junto al inventario del entorno. Cuando otro tester reconstruya el entorno más adelante, debe poder recrear las condiciones importantes sin recibir una base de datos de producción. Esto también facilita reducir los informes de errores enviados al proyecto a un ejemplo mínimo seguro.

Si un conjunto de prueba cambia durante la investigación, asigne un identificador nuevo al conjunto revisado. De lo contrario, dos informes que dicen usar la misma base de referencia pueden contener condiciones iniciales diferentes y generar comparaciones engañosas.

Cerrar la evaluación deliberadamente

El resultado debe señalar qué pasó, qué falló, qué no se probó y qué sigue sin ser compatible. Asigne a cada problema bloqueante un responsable y una referencia de reproducción.

Antes de retirar el entorno, conserve las pruebas necesarias para volver a probar. Exporte las definiciones de los conjuntos de prueba, el inventario de versiones y los resultados depurados. Revoque las credenciales temporales de integración y desactive la actividad programada para que una instalación de pruebas abandonada no siga contactando con servicios externos.

Cuando llegue una candidata posterior o una versión estable, cree una nueva base de evaluación según sus instrucciones oficiales y repita los casos afectados por los cambios. No arrastre silenciosamente un resultado correcto de una configuración diferente de módulos o indicadores.

El valor de las pruebas RC es obtener conocimiento temprano y reproducible. Una instalación cuidadosamente aislada puede revelar exactamente qué requiere trabajo y mantener la tienda de producción y sus clientes fuera del experimento.

Para conocer el contexto de la plataforma subyacente, consulte nuestra guía de actualización segura de PrestaShop 8 a 9 y aplique las comprobaciones específicas de versión anteriores a la instalación que esté evaluando.