Shopify launch QA checklist

QA does not begin when the store looks finished. It begins when customer journeys, data, commercial rules and integrations are stable enough to test repeatedly. Without that entry gate, the team is not accepting a release. It is continuing design and development through a bug tracker.

Useful Shopify launch QA answers four questions: what must work, under which conditions, who verifies it and what evidence closes the test? The same discipline applies to a new build, redesign or migration. It also stops teams from treating a visual detail as equal to a defect that blocks orders, payments, analytics or indexing.

Shopify recommends placing a test order to check checkout, order processing, inventory, shipping, email and taxes as configured for the store. Its launch preparation guidance also covers domains, sales channels, notifications, policies and removal of password protection. Those resources provide the platform baseline. Project QA still needs to cover the store's business model, integrations, markets, content and ownership.

Make the release testable first

An unstable environment produces contradictory results. Set an entry gate before client acceptance testing begins.

• The test scope is documented, including exclusions.
• The release candidate has a date, tag or build identifier.
• Reference data is loaded: products, variants, inventory, pricing, promotions, test customers and content.
• Required external services use a test environment or a controlled configuration.
• Test accounts and payment methods are available without sharing secrets in tickets.
• In-scope markets, currencies, languages, domains and shipping rules are known.
• Each journey has an owner, and the go or no-go authority is named.
• The team agrees what evidence looks like: screenshot, video, test order ID, anonymized log or export.

BlackSwan runs internal QA before client acceptance when it is included in scope. The client should not be the first person to find basic delivery defects. Client acceptance can then focus on business rules, content, operations and cases that only the merchant can validate.

Organize QA around journeys, not pages

Checking each page on desktop and mobile is not enough. An order crosses the product page, cart, checkout, payment, Shopify Admin, notifications and sometimes an ERP, OMS or 3PL. QA must follow the whole journey.

Several people may contribute to one test, but one owner needs to close it. Otherwise tickets stay in "needs checking" until launch day.

1. Buying journeys and commercial rules

Start with journeys that create or change an order. Use a representative matrix rather than an exhaustive combination set that nobody can maintain.

Catalog and product

• Expected products are published to the correct channels and markets.
• Titles, descriptions, media, variants, prices and availability match the approved source.
• Option selection loads the correct variant and updates price, media, availability and URL where required.
• Unavailable products follow the approved rule: blocked purchase, pre-order or a dedicated message.
• Metafields and metaobjects used by templates are populated or handle missing values safely.
• Automated and manual collections contain the expected products in the intended order.
• Search, filters and sorting return coherent results.
• Bundles, subscriptions, gifts, samples or personalization are tested when they are in scope.

Cart and promotions

• Add, remove and quantity changes recalculate the cart correctly.
• Quantity limits and availability rules are enforced.
• Eligible discounts apply under the intended conditions.
• Incompatible discounts do not stack by mistake.
• Shipping thresholds, gifts and benefits use the correct market and currency.
• Cart messages remain accurate after every change.
• The cart persists or resets as intended across domains, languages and sessions.

Checkout and payment

• Checkout receives the correct lines, quantities, discounts, addresses and attributes.
• Expected payment methods appear for eligible cases.
• A successful transaction creates an order with the expected statuses.
• A declined payment shows a useful message and does not create a false confirmation.
• Tests cover priority addresses, currencies and delivery methods.
• Displayed tax and totals match rules approved by the responsible experts.
• Confirmation and order status pages show the expected information.
• Test orders are identifiable and canceled or removed according to the agreed procedure.

Never put real card details in a screenshot or ticket. Shopify documents different test-order methods depending on payment provider and store configuration. Choose the method that fits the store and understand its side effects before running it.

2. Shipping, tax, inventory and operations

The storefront can show the right result while Shopify Admin or a connected system receives the wrong data. QA needs to verify the write and then read it back at the destination.

• Every priority shipping zone returns the intended rates and services.
• Out-of-zone addresses get the approved response.
• Product, weight, value and location restrictions are tested.
• Delivery estimates come from approved rules and do not create an uncontracted promise.
• Tax configuration is reviewed by the merchant or its qualified advisor. QA confirms implementation, not legal compliance on its own.
• Opening inventory is reconciled by variant and location.
• An order reduces or reserves the correct quantity according to the chosen flow.
• Cancellation, refund or return has the expected effect on order and inventory.
• Fulfillment and shipment statuses move through in-scope systems.
• Customer notifications use the correct language, data and working links.

For every integration, define a correlation key between Shopify and the external system. The test should connect an order, customer or product with its corresponding records without exposing personal data in the QA report.

3. Accounts, content and accessibility

• Sign-in, access recovery, order history and addresses follow the selected account model.
• Returns, cancellations and contact requests reach the correct tool when in scope.
• Account, order, shipping and refund emails use the correct language and working links.
• Every priority template is tested with short, long, incomplete and translated content.
• Images, video, headings, buttons, forms and error states use approved content.
• Keyboard access, focus, zoom, contrast and screen readers are checked against the project's chosen standard.

Test reusable components with edge cases. A design-system defect can spread across the whole store.

4. Mobile, browsers and performance

Run priority journeys on the agreed browser, device and screen-size matrix. Check touch controls, mobile keyboards, modals, media, JavaScript errors and critical network failures. For every performance test, keep the URL, date, device, network, tool and consent context. Our Shopify performance and Core Web Vitals page explains the wider method.

5. SEO and migration checks

A password-protected store, wrong canonical or broken redirect set can undermine launch work. Give SEO its own gate.

• Titles and meta descriptions on priority templates follow approved rules.
• One relevant H1 is present where the template requires it.
• Canonicals point to the intended URLs.
• Robots rules and meta robots match the public environment.
• The sitemap contains the expected published resources.
• Priority internal pages can be reached through crawlable links.
• Structured data is valid and matches visible content.
• Hreflang connects the correct language and market variants.
• Removed or consolidated pages follow the documented decision.
• The redirect plan is imported, exported and tested.
• The canonical domain, Search Console properties and monitoring plan are ready.

For migrations, keep the Shopify redirect plan as a separate register. Launch QA confirms it was implemented. It does not replace URL-by-URL mapping.

6. Analytics, consent and marketing

Seeing an event in a console does not make the data reliable. Check when it fires, which parameters it sends, whether it is unique and how consent affects it.

• Test and production environments use the intended identifiers.
• Page views and priority commerce steps appear in the target platform.
• One action does not fire duplicate purchase or add-to-cart events.
• Amounts, currencies, products, quantities and discounts match the test order.
• Campaign parameters persist according to the measurement plan.
• Consent state changes whether affected tools load or send data.
• Consent withdrawal or amendment follows the approved behavior.
• Advertising pixels are tested without prohibited data.
• Marketing forms display the correct notice and store the intended preference.
• Analytics and acquisition owners approve the in-scope measurement plan.

Technical testing cannot establish legal compliance by itself. The merchant and its advisors approve copy, purposes, retention periods and legal basis. The project team verifies that the approved configuration behaves as intended.

7. Markets, languages and domains

A check completed only from France, in French and in euros does not validate an international rollout.

Build a matrix for each priority market with domain, language, currency, catalog, pricing, availability, payment method, shipping, tax, consent and notifications. Test each approved combination with a controlled address and order.

• The correct domain serves the correct storefront.
• Market selection persists or changes according to the agreed rule.
• Translations cover theme copy, content, email and error messages.
• Catalog and pricing match the market.
• Unavailable products do not reappear through search or direct links.
• Payment methods and shipping rates follow intended eligibility.
• Cross-domain links keep a valid destination.
• Canonicals and hreflang do not mix variants.
• Local teams approve the content and rules they own.

Shopify documents domain and international-domain management. Check the documentation during the project because Admin labels and available capabilities can change.

8. Security, access and launch operations

• Individual accounts have the access they need without shared credentials, and temporary access has a removal date.
• Secrets do not appear in code, tickets, screenshots or public documents.
• The runbook says who monitors orders, payments, inventory, integrations, errors and traffic.
• Rollback or compensating actions are documented for covered risks, within the scope set out in the contract.
• Password protection is removed only at the agreed point in the runbook.

Every issue needs enough information to reproduce it without a meeting: ID, version, environment, preconditions, steps, observed result, expected result, severity, owner, evidence and retest. Commercial priority and technical severity are not always the same, so the triage model needs to hold both.

Set a go or no-go gate

The final decision is not a count of open tickets. It considers their effect and the controls available.

Run a short review with the owners. Present blockers, unexecuted tests, accepted risks and the monitoring plan. A checked box without evidence is weaker than a closed test with a test-order ID and confirmed destination read-back.

Launch-day checklist

• The approved release candidate is the version being published.
• Content, handle, data and configuration freezes are active under the runbook.
• Test orders and accounts were handled according to procedure.
• Domain and certificates respond as intended.
• Priority redirects are active.
• Robots rules, meta robots, canonicals, hreflang and sitemaps are checked on the public domain.
• A control order is placed through priority journeys.
• Analytics events are observed one final time.
• Integrations receive and return the expected statuses.
• E-commerce, support, operations and engineering teams know the monitoring channel.
• Planned dashboards and alerts are open.
• The launch log records each action, time, owner and result.

Keep testing after publication. Monitor orders, payments, inventory, HTTP errors, integrations, analytics and SEO signals at the cadence defined in the runbook. Go-live does not close QA. It starts observation under real traffic.

Frequently asked questions

How much time should Shopify launch QA take?

There is no universal duration. It depends on the number of journeys, markets, integrations, commercial rules and reviewers. Estimate the effort from the test matrix, correction time and retesting. A timeline without that scope would be misleading.

Who should run acceptance testing?

The agency or delivery team runs technical and functional QA within its contracted scope. The merchant approves content, business rules, operations and obligations it owns. SEO, analytics, payment and integration partners review their areas. One owner closes each test.

Can a store launch with open defects?

Some non-blocking issues can remain when the risk, temporary measure, owner, due date and monitoring are accepted. A defect affecting payment, totals, security, orders or another critical function normally needs correction and retesting before go-live.

Is one test order enough?

No. It verifies one scenario. The matrix needs representative markets, payment methods, shipping rules, promotions, statuses and integrations. Shopify recommends placing a test order, while the project must define the cases that represent its operating model.[1]

Prepare your Shopify launch

We build QA into delivery through internal checks, an acceptance matrix, named owners, evidence and a launch runbook within the agreed scope. Your team can see blockers and decisions before the store goes public.

Discuss your Shopify migration or launch