# Shopify QA Checklist: Catch Issues Before the Client Does > A shopify qa checklist for agency projects: functional, merchant-facing, content, mobile, performance, and regression checks to run before every review. _Published: 2026-09-18 ยท CommerceCopilot_ ## The most expensive bug is the one the client finds Every agency has lived this sequence: the build is done, the review link goes out, and the first reply from the client is a screenshot of something broken. Not something subtle. Something like a cart drawer that does not open on iPhone, or a collection page where the sale badge overlaps the product title. The work behind the link might be excellent, but the client's first impression is now the bug, every subsequent review gets read more skeptically, and a Shopify QA checklist exists to make sure that screenshot never gets taken. The checklist matters not because your developers are careless, but because "the developer clicks around before sending the link" is not a QA process. It is a memory test, and memory tests fail exactly when projects get busy, which is exactly when clients are watching most closely. This post is the checklist we would want every Shopify project to pass before a client sees it, organized by the kind of failure each section catches, with the copy-paste version at the end. ## What a Shopify QA checklist has to cover Generic web QA advice covers forms, links, and browsers. Shopify projects fail in more specific places: the theme editor, app conflicts, checkout, and the gap between how a page looks with demo content and how it looks with the client's real catalog. A checklist that misses those is a web project QA checklist wearing a Shopify label, and it will pass builds that fail in the client's hands. The sections below cover both layers. ### Functional checks: walk the money path first Start with the path that produces revenue, because a broken announcement bar is embarrassing and a broken add-to-cart button is an incident. Walk the full journey as a customer: land on the homepage, reach a collection, open a product, pick a variant, add to cart, edit the cart, and go through checkout. On Shopify, you can complete that last step without spending money: the built-in Bogus Gateway simulates transactions, and stores on Shopify Payments can enable test mode and use Shopify's test card numbers instead. One warning that belongs in every agency's process notes: while a payment provider is in test mode, real customers cannot place live orders, so on a live client store either schedule that window deliberately or test checkout on a development store instead. While you are on the product page, test the unhappy variants too: a sold-out variant, a variant with its own image, a product with one option versus three. Variant selection logic is one of the most common places a theme customization quietly breaks. ### Merchant-facing checks: open the theme editor This is the category agencies skip most often, because the build looks finished in the browser. But on an Online Store 2.0 theme, the client's team will live in the theme editor: reordering sections, editing settings, swapping images. A section that renders perfectly with the settings the developer chose, and collapses when a merchant hides one block or writes a longer heading, is not done. So test the build the way a merchant will use it. Open the editor and change every setting your new sections expose. Hide optional blocks. Write a headline twice as long as the demo one. If a setting breaks the layout, either fix the layout or remove the setting; shipping a control that breaks the page is worse than not shipping the control. ### Content and state checks: real data is uglier than demo data Builds get developed against friendly content: short product titles, square images, full collections. Client catalogs are not friendly. Check the layouts that demo data never exercises: a product title that wraps to three lines, a collection with two products, a product with no reviews yet, prices in the tens of thousands, and image aspect ratios that do not match the design. Then check the empty and edge states: empty cart, empty search results, a 404, an out-of-stock product page. These are pages clients stumble into during review precisely because they click around less predictably than your team does. ### Mobile and browser checks Most Shopify storefronts see the majority of their sessions on phones, so mobile is not the secondary pass, it is the primary one. Test on at least one real iOS device and one real Android device, not just a resized desktop window: browser dev tools do not reproduce safe-area insets, sticky-element behavior over the keyboard, or how a cart drawer feels under a thumb. Then cover the current versions of Safari, Chrome, and Firefox on desktop. Safari on iOS deserves particular attention, since it is both the browser your client's customers are most likely using and the one where layout bugs most often hide. ### Performance checks: numbers, not impressions "It feels fast on my machine" is not a check. Google's Core Web Vitals give you concrete thresholds to test against: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1, with Google assessing real-user data at the 75th percentile. Run the pages you touched through PageSpeed Insights before and after the change, and treat a meaningful regression as a bug, not a footnote. The most common Shopify-specific offenders are apps that inject render-blocking scripts and oversized images uploaded straight from the client's asset folder. ### Regression checks: what you did not touch The bug that erodes client trust fastest is the one in a part of the site the project was never about, because it makes the client wonder what else broke. Theme code is shared: a change to a snippet, a CSS utility, or a settings schema can ripple into templates nobody opened. Before review, spot-check the highest-traffic pages you did not work on, and re-run the money path even if the project was "just" a homepage section. If an app was added or updated, check the pages where its widgets render. ## The checklist The copy-paste version. Run it against the preview link before the client gets it. - Walk homepage to checkout as a customer, completing a test order through the Bogus Gateway or Shopify Payments test mode (never leave test mode on a live store longer than the test). - Test variant selection: sold out, multiple options, variant-specific images and prices. - Add, edit, and remove cart line items; confirm totals and any discount logic. - Open the theme editor and exercise every new setting and block, including hiding optional ones. - Preview with real catalog data: long titles, odd image ratios, small collections, missing content. - Check empty states: cart, search results, 404, out-of-stock product. - Test on a real iPhone and a real Android device, plus current Safari, Chrome, and Firefox on desktop. - Run touched pages through PageSpeed Insights; investigate any Core Web Vitals regression. - Spot-check high-traffic pages outside the project scope, and re-run the money path. - Confirm analytics, tracking pixels, and any connected apps still fire after the change. ## Why QA fails as a process, not a skill Almost nobody disputes the checklist above. The failure is organizational: at most agencies QA has no owner, no defined trigger, and no defined pass bar, so it happens when someone remembers and to whatever depth the deadline allows. The fix is boring and effective: QA runs on every review link, someone specific owns it, and "done" means the checklist passed, not that the developer feels confident. The other half of the fix happens before the build starts. A checklist can verify that a page works; it cannot verify that a page is right unless the ticket said what right means. QA quality is downstream of [acceptance criteria specific enough to check off](/blog/how-to-write-development-tickets), and those are downstream of a [scoping process that resolved ambiguity before anyone quoted the work](/blog/shopify-project-scoping). If your tickets say "improve the product page," no checklist will save the review. This is the sequencing CommerceCopilot is built around. The Business Analyst agent turns discovery notes, calls, and Slack threads into tickets with structured acceptance criteria, so every piece of work carries its own definition of done. The QA agent it hands off to then runs automated browser testing against the storefront before a review link goes out, working from a [connected store](/docs/shopify) so it tests the theme a customer actually sees rather than a local approximation. The checklist stops being a memory test because it stops depending on memory. ## FAQ ### Does a generic web project QA checklist work for Shopify? Partially. A general web project qa checklist covers the universal layer: links, forms, responsive layouts, browsers, and performance, and all of that applies to a Shopify build. What it misses is the platform layer: theme editor settings, variant logic, app conflicts, checkout testing through test orders, and the merchant workflows that break after handoff. Use the general list as a floor, not the whole process. ### When should QA happen in a project? At two points, not one. Per ticket, against that ticket's acceptance criteria, so bugs get caught while the context is fresh and the fix is cheap. Then again before every client review link, as a full pass over the money path and regressions, because individually passing tickets can still combine into a broken page. QA that only happens at the end of the project catches everything at the moment fixes are most expensive. ### Who should own QA at a small agency? Someone who did not build the change. It does not need to be a dedicated QA hire; at a five-person agency it is usually a second developer or the project lead. The requirement is fresh eyes plus a written checklist, because the person who built a feature tests the paths they built, not the paths a customer or merchant will actually take. ### Should you run QA on the live store or a preview theme? On a preview wherever possible: an unpublished theme on the client's store gives you their real catalog, apps, and settings without customer exposure, and a development store works when you need to test checkout freely. Reserve live-store testing for the final smoke test after publishing, and if you must test payments on a live store, keep the test-mode window short and deliberate, since customers cannot check out while it is on. --- Canonical page: https://www.commercecopilot.ai/fr/blog/shopify-project-qa-checklist