A successful installation message confirms one step, but approving the change depends on whether the store works correctly. A module can appear in the back office and still cause problems in the cart, shipping calculations or a task that runs hours later.
That is why every installation or update should have a validation checklist. It should cover the module's purpose, the paths shoppers use and the store's integrations. The approach below organizes these checks without turning real customers or orders into test subjects.
Prepare staging and a way back
Run the initial checks in staging: an environment separate from the public store, with representative settings and restricted access. Prefer fictional data. If a real copy is essential, minimize or anonymize personal data and protect access.
Record the versions of the store, module, theme and PHP. Review the requirements and release notes. PrestaShop lets modules declare a compatibility range, but that information does not replace testing the combination used by your store. Official module reference.
Before making the change, confirm that you have a usable backup and a rollback procedure. If the database changes, replacing the old files alone may not undo everything. Define who decides to stop the deployment and how to preserve data received after the backup.
Follow the path from product to checkout
Start with scenarios that represent your catalog: a simple product, a size or color combination, an unavailable item and a discounted product, where applicable. Check images, price, availability and what happens when items are added or removed.
In the cart and checkout, check:
- quantity changes and updated totals;
- applying and removing discount codes;
- address, shipping, taxes and delivery restrictions;
- registered customer login and guest checkout, if enabled;
- error messages, required fields and mobile navigation.
Compare expected and actual results, including rejected inputs. An invalid address should produce understandable guidance without leaving the shopper stuck. Also confirm that going back a step does not unexpectedly erase information or change the total without explanation.
Validate payments without moving money
Use only the provider's documented sandbox or test mode, with test credentials and payment methods. Do not place a real order to “check it quickly.” Stripe, for example, documents simulations that do not move money in its testing environment. Stripe testing documentation.
Cover successful, declined, canceled and pending payments, according to the available features. Check that the provider's response matches the order status in staging. Observe what happens when the shopper closes the page before returning to the store.
If the integration uses webhooks, keep test endpoints and secrets separate from production. Validate signatures, repeated events and delays only in the isolated environment. Stripe warns that events may arrive more than once or out of order. Stripe webhook documentation.
Never resend production events for this exercise. Also isolate ERP, tax document issuance, carriers, external inventory and messaging: a fictional order must not generate a real tax document, shipping label, shipment or message to a customer.
Look for regressions beyond the main feature
A regression is something that worked before and stops working after a change. Even a display module needs testing on pages that share scripts, styles or components.
Open search, categories, product pages, customer accounts and the back office. Check menus, filters and forms. Repeat the main journeys using the theme and devices the store actually supports. If there are multiple languages, currencies or stores, include samples of those contexts.
Do not expose debug mode publicly. Analyze errors in a controlled environment and remove personal data and secrets from evidence shared with support.
Check integrations and scheduled tasks
Some problems appear only when an automated task runs. List the scheduled tasks, including cron jobs, related to the module, such as inventory synchronization, catalog imports, status updates or file generation.
In staging, use simulated services or dedicated test endpoints. Check schedules, time zones, permissions and execution logs. Assess the result of a controlled repeat without triggering live tasks or duplicating external operations.
Record which tasks were tested and which depend on a specific time window. “Not run” needs to remain visible: the absence of an error in the back office does not prove that the task worked.
Compare performance under equivalent conditions
Measure affected pages before and after the change, keeping the environment, data and cache conditions comparable. Observe response times, errors and additional requests. A single measurement does not justify a performance promise or a definitive diagnosis of slowness.
Avoid improvised load testing on the public store or third-party APIs. If a significant difference appears, investigate its source in a controlled environment before releasing the change.
Approve the change with evidence
For each scenario, record the expected result, actual result, environment, date and person responsible. Block the release if there are discrepancies in totals, payments, data or essential functions.
After an authorized deployment, perform a limited, non-destructive production check, review logs and observe the first scheduled runs. Keep the rollback plan accessible, without automatically restoring a backup over new orders.
If your team needs to organize this process, talk to AGTI about maintenance and technical validation for your PrestaShop store. A checklist tailored to the operation helps you use evidence to decide when an update is ready.