Magento Testing Checklist: What to Test Before Every Release

A Magento testing checklist is the list of concrete, pass-or-fail checks you run on staging before a change reaches production. Run it before every release, security patch, version upgrade and extension install - and before configuration changes to payment, shipping, tax or caching, which break checkouts just as often as code does. It covers the storefront paths that make money, the admin flows that fulfil orders, the integrations that move data and the infrastructure underneath.

When I review Testing and QA in a Magento audit, I look at three things: how much automated coverage exists (unit, integration, functional), how much regression risk sits in the critical flows, and whether quality gates run in CI before every deploy. Many stores have little of the first, a lot of the second and none of the third. This checklist is the safety net until the automation catches up - and the specification for what to automate first.

How much to test for each type of change

Not every change needs the full pass. Match the depth to the risk:

Storefront critical paths

Test on mobile and desktop, as a guest and as a logged-in customer.

• Search - keyword, misspelt and zero-result queries return sensible results; autocomplete responds.
• Layered navigation - filters apply, combine and clear; counts match the results shown.
• Category pages - sorting, pagination and product counts are correct.
• Configurable products - every option combination updates price, image and stock status.
• Bundle and grouped products - bundle prices recalculate; grouped quantities add to the cart correctly.
• Cart and mini-cart - add, update quantity and remove; the mini-cart refreshes without a page reload; a guest cart merges on login.
• Checkout with every payment method - each method in sandbox mode, including a 3-D Secure challenge, a declined card and a cancelled redirect back to the store.
• Checkout with every shipping method - domestic, international and free-shipping thresholds; carrier rates appear.
• Coupons and cart price rules - valid, expired and usage-limited codes; stacking and priority behave as configured.
• Customer account - register, log in, reset password, order history, address book, wishlist.
• Transactional emails - order, invoice, shipment, credit memo and password reset emails arrive with correct totals, branding and links.

Admin and back-office checks

• Order lifecycle - place an order, then invoice it, ship it with tracking and refund it with a credit memo; totals and statuses match at every step.
• Admin-created orders and reorders - common in B2B and they use different code paths from the storefront.
• Catalogue edits - save one product of each type; price, stock and image changes reach the storefront.
• Imports - run your product, price and stock imports with a realistic file, plus one malformed row to check error reporting.
• Price rules - catalogue price rules apply after the rule indexer runs; cart rules apply at checkout.
• CMS - pages, blocks, widgets and Page Builder content save and render.
• Cache and index management - both admin screens load, flush and show the expected states.
• Admin users and 2FA - restricted roles still see only what they should; 2FA prompts every admin user.

Integration tests, including failure and retry

• ERP order export - each new order arrives exactly once, with correct totals, tax, shipping, discounts and customer data.
• Stock and price sync - an ERP or PIM update reaches the storefront in the expected window; a zero-stock product cannot be oversold.
• Payment webhooks and IPN - authorise, capture, refund and failure notifications update the order; a duplicated notification does not create a second invoice.
• Shipping rate APIs - live rates return; a carrier timeout shows a fallback or a clear message instead of a broken checkout.
• PIM and CRM feeds - products, customers and consents sync in the directions you designed.
• Failure and retry - point each endpoint on staging at a dead URL and confirm messages queue, retry, log and alert instead of disappearing.

The last item is the one most teams skip. Happy-path integrations pass on almost every store; what decides whether you lose orders is how the export behaves after a ten-minute ERP outage.

Multi-store, multi-currency, tax and translations

• Store views - each loads with the right base URL, theme, language and catalogue; the store switcher keeps the cart.
• Currency - display currency, rate updates and rounding; the payment is charged in the expected currency.
• Tax - prices show including or excluding tax as configured per store; tax on shipping is right; storefront, order and invoice totals match.
• Translations - static content is deployed for every locale in use (bin/magento setup:static-content:deploy with each locale code); no untranslated strings in checkout.
• RTL and local formats - right-to-left layouts, dates, addresses and phone formats where relevant (see UAE gateways, VAT and RTL).

Infrastructure health checks

• Cron - the cron_schedule table shows recent success rows and no pile-up of missed or error jobs.
• Message queue consumers - the consumers in bin/magento queue:consumers:list are running (via the cron consumers runner or a process supervisor) and queues are draining.
• Indexers - bin/magento indexer:status shows nothing invalid, every indexer in its intended mode and no growing backlog.
• Full-page cache and Varnish - a repeat request to a category or product page is a cache hit; no block with cacheable="false" slipped into a layout (one such block makes the whole page uncacheable).
• Redis - cache and session instances have memory headroom; evicted_keys in redis-cli info is not climbing.
• OpenSearch - cluster health is green and the catalogsearch_fulltext indexer rebuilds cleanly.
• Logs - var/log/exception.log, var/log/system.log, var/report/ and the PHP-FPM and web server logs show no new errors.
• Deploy mode - bin/magento deploy:mode:show reports production.

Performance smoke test

Measure the same pages on the same staging, with a warmed cache, before and after the change. The comparison matters more than the absolute numbers.

• TTFB on key templates - home, category, product, search results and cart, both cached and uncached.
• Core Web Vitals - Lighthouse on mobile for LCP, CLS and Total Blocking Time; real-user INP follows from field data after release. Google's "good" thresholds are LCP up to 2.5s, INP up to 200ms and CLS up to 0.1.
• Checkout steps - time the shipping and payment steps; slow rate APIs show up here first.
• Asset weight - JavaScript and CSS per template did not jump.

A regression here is usually a symptom, not the cause. If the numbers move, the Magento performance audit traces them to the query, plugin or cache hole behind them, and why is my Magento store slow covers the usual suspects.

SEO regression checks

• Robots - robots.txt and the default meta robots (Content, Design, Configuration) are not the staging NOINDEX,NOFOLLOW.
• Canonicals - category and product pages point at the clean URL.
• hreflang - on multi-language stores, alternates still render and point at the right store view.
• XML sitemap - regenerates and lists live, indexable URLs only.
• Structured data - Product, Offer and BreadcrumbList markup validates in Google's Rich Results Test.
• Redirects - URL rewrites survived; changed URL keys have 301s; no redirect chains.

For a deeper pass, the Magento SEO audit covers faceted navigation and crawl budget as well.

Security checks

• Patch level - bin/magento --version matches the latest security release for your version line in Adobe's security bulletins.
• Admin URL and 2FA - a custom admin path (bin/magento info:adminuri), 2FA enforced, no shared admin accounts.
• File permissions - nothing world-writable in the web root; app/etc/env.php is not reachable over HTTP.
• Dependencies - composer audit reports no known security advisories.
• Secrets - no API keys or credentials committed with the release.

Which automated tests does Magento 2 support?

These are the main automated testing layers in Magento 2, each with its own place in the codebase:

bin/magento dev:tests:run runs the PHPUnit-based layers by type (for example unit, integration or static). The Functional Testing Framework (MFTF) is Adobe's official end-to-end framework: tests are written in XML, generated into Codeception tests and run in a real browser. It is still actively maintained and Adobe runs its MFTF tests against Marketplace extension submissions. Many merchant teams find it heavy to maintain for their own flows and write their critical-path suites in Playwright or Cypress instead. Either choice is fine. What matters is that the suite exists and runs before every deploy.

CI quality gates to run before every deploy

A quality gate is a check that blocks the deploy when it fails. These are the ones I expect to see:

Staging parity is the gate teams most often fake. If staging runs a different PHP version, no Varnish or a two-year-old database, a green run proves very little. On production, keep the post-deploy smoke test read-only - home, category, product, search, add to cart, reach checkout - unless you have a safe test payment method.

Test data: anonymised production copy, never real customers

Realistic data finds bugs that fixtures never will: odd product configurations, legacy customer groups, orders with ten coupons. The right source is a copy of the production database, anonymised before it leaves production. Tools such as elgentos/masquerade replace names, emails, addresses and phone numbers with fake data from a YAML rule set, and you can add rules for third-party tables.

When to bring in an audit

If you work through this checklist and find that most of it is manual, that nobody can say which integrations retry, or that staging does not match production, the problem is the delivery process rather than any single bug. Testing and QA is part of every Magento audit I run: I measure the automated coverage you have, map the regression risk in your critical flows and check which quality gates actually block a deploy. Audits start from $1,650.

If the gaps are already clear and you need the process built, project delivery covers setting up CI gates, staging parity and release routines, from $1,400. For a broader self-check, start with the Magento 2 audit checklist; if an upgrade is on the horizon, read Magento upgrade readiness first, because test coverage decides how much manual regression the upgrade will need.