Shopify Development QA Checklist for Agencies
A theme change or feature build that looks finished on one screen can still break checkout on mobile, conflict with an existing app, or quietly drop organic traffic through lost redirects. This is a literal, run-through-it checklist for the pass that should happen before anything goes live on a client's store.
Why This Runs Before Every Launch
Most post-launch Shopify issues aren't big, dramatic bugs — they're small gaps that a structured pass would have caught: a broken checkout step on one device, an app conflict that only shows up on the collection page, a missing redirect. None of this requires exotic testing tools, just a consistent list that gets run every time, on staging, before the client sees it.
1. Theme & Visual QA
Check the actual rendered pages, not just the templates that were directly edited — theme changes (global CSS, section settings, snippets) often touch more of the site than the task description implied.
- Home, collection, product, cart, and any custom page templates checked on desktop, tablet, and mobile widths
- Tested in at least two browsers (Chrome and Safari, at minimum, since iOS Safari behaves differently from desktop)
- Navigation, footer, and any global sections checked on pages that weren't the direct target of the change
- Empty states checked — empty cart, no search results, sold-out product — not just the “happy path”
- Font loading, spacing, and image aspect ratios checked at actual production sizes, not just in the theme editor preview
- Any animations or interactive elements tested for behavior on touch devices, not just mouse hover
2. Cart & Checkout Flow
This is the highest-cost place for a bug to slip through, since it sits directly between the customer and a completed sale. Test the full path end to end, not just the page that was changed.
- Add to cart tested from product page, quick-add (if used), and collection page grid, for at least one simple and one variant product
- Cart drawer or cart page: quantity updates, item removal, and subtotal recalculation all confirmed correct
- Discount codes and any active promotions applied and confirmed to calculate correctly
- Full checkout completed with a real test order through to the thank-you page
- Shipping method and tax calculation checked, especially if the change touched cart or checkout customizations
- Any custom cart or checkout scripts (upsells, free-shipping bars, gift notes) confirmed still functioning after the change
3. Existing App Compatibility
Theme and code changes can silently break an app that was working fine before, especially apps that inject their own scripts or sections into the theme. Confirm nothing installed on the store regressed.
- Reviews, loyalty, subscription, and upsell apps checked for correct display and function on affected pages
- Any app that injects into cart or checkout retested specifically, since these are the most common conflict points
- Browser console checked for new JavaScript errors introduced on pages touched by the build
- Email, SMS, or marketing pixel integrations confirmed still firing (page view, add-to-cart, and purchase events)
4. Page Speed
A visually correct page that loads noticeably slower than before is still a regression, even if nothing looks broken. Check speed on the actual pages that changed, not just the homepage.
- Core Web Vitals checked on the affected template(s) before and after the change, using a real page-speed tool
- New images confirmed to be compressed and served at an appropriate size, not full-resolution originals
- Any new third-party scripts checked for render-blocking behavior and loaded async/deferred where possible
- Mobile speed checked specifically, not just desktop — mobile is usually the larger share of Shopify storefront traffic
5. SEO Basics
SEO regressions from a launch are often invisible at launch time and only show up in traffic data days later. Catching them in QA instead of in a ranking report is far cheaper.
- 301 redirects confirmed for any URLs that changed, especially on a theme or URL-structure change
- Title tags and meta descriptions checked on affected templates — confirm dynamic tags still populate correctly per page
- Heading structure (a single H1 per page) confirmed intact after any template restructuring
- Structured data (product, breadcrumb, FAQ schema) validated if the change touched a templated page type
- XML sitemap and robots.txt confirmed unaffected, unless the change was specifically meant to update them
6. Rollback Plan
Every launch should have a defined way back, decided before launch — not improvised after something goes wrong in front of the client.
- Previous live theme duplicated and kept untouched as a known-good fallback before publishing the new one
- Anyone who can access the theme editor knows which theme is the rollback and how to republish it
- Any database-level or app-configuration changes documented separately, since a theme rollback alone won't undo those
- A named person responsible for monitoring the site immediately after launch and authorized to make the rollback call
This checklist is a useful baseline regardless of who's doing the build. If you're briefing a developer — in-house or outsourced — on a project, pairing this with a clear project brief up front reduces how much of this list turns up issues in the first place.
Need extra hands to get a launch through QA on schedule?
FAQ
Have a Shopify Project Your Team Can't Handle Right Now?
Send us the details — designs, a client brief, or an existing store that needs work — and we'll review it and get back to you with a technical scope.