Small mobile
Check around 360–390px, long titles, sale prices, sticky controls and the mobile keyboard.
Resources
A repeatable pre-deployment checklist for Shopify themes.
Combine automated checks, engineering review and a real storefront preview before publishing.
Direct answer
A pre-deployment checklist for Liquid, HTML, schemas, assets, translations, performance and review.
A complete Shopify theme QA checklist before deployment
Theme QA is not a single pass/fail test. It combines automated validation, storefront review and business-context checks. Use the short list for routine changes and the full checklist when a change affects product purchase behavior, navigation, tracking or several templates.
Before code changes
Define what success means before testing
Scope
- The request describes an observable customer or operational outcome.
- Affected templates and customer journeys are identified.
- The current behavior is recorded with screenshots, video or measurements where useful.
- Known app dependencies and customizations are listed.
- The change has explicit exclusions so unrelated work is not introduced.
Environment
- The correct store and staging theme are selected.
- The staging source is current enough for the proposed work.
- The reviewer knows which live version the change is based on.
- Production publication authority is assigned to a specific person or role.
Code integrity
Liquid, JSON and theme-editor checks
Liquid and references
- Modified Liquid parses without syntax errors.
- Referenced snippets, sections and assets exist.
- Variables are checked for blank or missing values where necessary.
- Loops and conditional branches do not create duplicate IDs or invalid markup.
- Translations use valid locale keys instead of hard-coded text when localization is expected.
JSON and schema
- JSON templates remain valid JSON.
- Section schema remains valid and setting IDs are unique.
- Existing merchant-configured section and block settings are preserved.
- Defaults do not unexpectedly override existing storefront configuration.
- App blocks and theme app extensions remain available where expected.
Customer journey
Test the states customers actually encounter
Product and cart
- Default and non-default variants can be selected.
- Price, compare-at price, media and availability update correctly.
- Sold-out and unavailable states are understandable.
- Subscription or selling-plan products still work.
- Add to cart, cart drawer, quantity changes and removal work.
- Discount messaging does not promise behavior the checkout cannot deliver.
Discovery and accounts
- Navigation menus and mobile menus open, close and remain keyboard accessible.
- Search returns results and empty states correctly.
- Collection filters, sorting and pagination still work.
- Customer login, account links and forms still submit correctly.
- Localization, currency and market selectors continue to work where enabled.
Visual QA
Review more than one perfect viewport
Responsive defects often appear only when content is unusually long, images are missing or browser controls reduce the available viewport. Test representative breakpoints and deliberately difficult content.
A visual review should include interaction states, focus states and overlays, not only the first static screen.
Tablet
Check intermediate layouts where desktop and mobile rules can overlap unexpectedly.
Desktop
Check wide and laptop-sized screens, not only a large design monitor.
Content stress
Check missing media, long translations, many variants, long navigation labels and large account names.
Performance
Confirm the change did not introduce an obvious regression
Assets and execution
- No unnecessary third-party script or external asset was added.
- JavaScript listeners are not registered repeatedly after section reloads.
- New assets are loaded only where they are needed.
- Images have appropriate dimensions, formats and loading behavior.
- The browser console does not show new errors during key journeys.
User experience
- The largest visible content does not load later because of the change.
- New interactive controls respond without obvious delay.
- Space is reserved for media and dynamic components to reduce layout movement.
- Sticky and fixed elements do not block important content or controls.
Discoverability and access
Protect SEO and accessibility fundamentals
SEO
- The intended H1 and heading hierarchy remain understandable.
- Canonical, robots and hreflang behavior are unchanged unless deliberately modified.
- Structured data remains valid and reflects visible content.
- Internal links remain crawlable and do not depend only on JavaScript.
- No accidental noindex, hidden content or duplicate metadata was introduced.
Accessibility
- Interactive elements are reachable and usable with a keyboard.
- Focus is visible and moves predictably through dialogs and menus.
- Buttons use meaningful labels and form fields retain accessible names.
- Images and icons have appropriate alternative text or are correctly decorative.
- Color, motion and error messages remain understandable without relying on one visual cue.
Approval packet
Record evidence before production
| Evidence | Why it matters |
|---|---|
| Request and interpreted scope | Confirms the implementation solves the intended problem |
| Files changed | Makes the exact technical surface clear |
| Preview URL | Lets the merchant inspect the real staging state |
| Checks passed and warnings | Separates verified facts from remaining uncertainty |
| Approver and approval time | Creates attributable control over publishing |
| Deployment and verification record | Shows what reached production and whether it behaved as expected |
| Rollback conditions | Prevents a later reverse operation from overwriting newer work blindly |
15-point release check
Use this shorter list for routine well-defined change
- Correct store, theme and scope confirmed.
- Liquid and JSON validation passed.
- Theme settings and app blocks preserved.
- Variant, sold-out and subscription states checked where relevant.
- Cart and primary conversion path checked.
- Mobile, tablet and desktop reviewed.
- Long and missing-content states reviewed.
- No new console errors.
- No obvious performance regression.
- SEO metadata and structured data preserved.
- Keyboard and focus behavior checked.
- Files changed and preview URL recorded.
- Warnings and remaining uncertainty shown.
- Exact artifact approved by an authorized person.
- Production verified after release.
QA responsibilities
Automated checks and human review answer different questions
Automation should remove repetitive validation and make evidence consistent. It should not produce false certainty about subjective design, business logic or integrations it cannot fully observe.
The best approval packet combines automated results with a short list of manual scenarios selected from the actual scope.
| Automated evidence can verify | Human review is still needed for |
|---|---|
| Liquid and JSON validity | Whether the requested experience is commercially correct |
| Missing files and prohibited targets | Visual hierarchy, brand quality and content accuracy |
| Known dangerous patterns and new console errors | Unusual app, market and customer-state behavior |
| The exact files included in the changeset | Whether remaining warnings are acceptable |
| That a staging write and preview were produced | Whether the merchant is ready to authorize production |
Test planning
Build a small test matrix from risk, not from every possible page
Testing every URL is rarely practical. Choose representative states that exercise the changed behavior and its dependencies. A product-page change might need one simple product, one multi-variant product, one sold-out product and one subscription product rather than fifty similar products.
Add markets, customer accounts or device states only when the implementation can affect them. The goal is broad risk coverage with a well-defined review plan.
| Dimension | Representative states |
|---|---|
| Product | Simple, variants, sold out, subscription or bundle where relevant |
| Viewport | Small mobile, tablet transition, laptop and wide desktop |
| Content | Long title, sale price, missing image, long translation |
| Customer | Guest, logged in, market or currency variation when affected |
| Interaction | Initial load, variant change, add to cart, section reload and back navigation |
Definition
A shopify theme qa checklist needs a clear engineering definition.
The guide explains acceptance criteria, Liquid and JSON structure, HTML, schema, assets, translations, performance and interactions so the reader can distinguish a reliable workflow from a generic code suggestion.
Inspection
Map the current state before changing files.
Review acceptance criteria, Liquid and JSON structure, HTML, schema, assets, translations, performance and interactions, identify the affected templates and document dependencies or assumptions.
Scope
Use tooling plus storefront review and release evidence.
The implementation should be small enough to review, explicit enough to test and isolated from unrelated storefront work.
Validation
Combine structural tooling with a working storefront preview.
Automated checks catch defined failure classes; mobile, desktop, content extremes and interactions still require inspection.
Approval
Record the diff, evidence, approver and release decision.
Production should change only after the staged result and remaining risks are understandable.
Boundary
Avoid treating a successful build as proof of every visual or business outcome.
The guide preserves uncertainty and routes complex work to experienced engineers instead of offering a false guarantee.
Continue exploring
Related TaskerArmy pages
Primary references
Sources used for this comparison
Capabilities change over time. These links point to the alternative provider’s own current documentation and should be reviewed during future updates.
Next step
Connect the store. Start with evidence.
Connect your store to compare the guidance with findings from your own theme.