Text version of this lessonExpand
Pre-launch QA is not a final click-through. It is a regression test before traffic: pages, payment, shipping, email, data, policies, and support must be tested through real paths.
Run pre-launch regression through real user paths
Many stores discover after launch that mobile buttons break, failed-payment emails are missing, GA4 has no purchase, or policy links are hard to find.
This lesson separates QA into user path, order path, data path, and exception path. Each path needs device, screenshot, owner, and fix result.
Decision lens for this lesson
- Regression test: Rechecking the critical path after changes to confirm launch ability is still intact.
- User path: The full experience from entry page to product, cart, checkout, and support.
- Exception path: Non-ideal cases such as failed payment, out-of-stock, address error, refund, and support inquiry.
Lesson output: pre-launch regression sheet。Use this output to decide whether the lesson is truly complete.
Lesson output: launch QA issue log
Turn launch QA from a memory list into a table that closes issues.
| QA area | What to record | Close standard |
|---|---|---|
| Pages and navigation | Broken pages, dead links, mobile layout issues, wrong CTAs | Retest on desktop and mobile after fixing |
| Checkout and payment | Test order, failure message, refund path, email notification | At least one full test order can be reviewed |
| Data and support | Event firing, order status, support entry, owner | Every issue has an owner, status, and retest time |
Why a Final Store Check Matters
Everything you set up earlier, entity, payments, storefront, logistics, compliance, and systems, must be validated in one real customer path. Looks correct in admin is not enough.
What QA Is Supposed to Achieve
- Catch visible mistakes before users do.
- Confirm the full funnel works end to end.
- Make sure the team has one clear view of launch readiness.
Run a basic readiness scan first
Before manual QA, open the Store Launch Readiness Scanner, enter the store domain, and let it check public pages, policy links, contact signals, mobile performance, key links, and basic tracking signals. The report does not replace manual testing. It gives you the first issue list.
Basic setup steps
Page-Level Checks
Frontend Checklist
- Homepage, product pages, collection pages, FAQ, policy pages, and contact pages all load correctly.
- Navigation and footer links are valid.
- Product title, pricing, variants, images, and stock state display correctly.
- Mobile layout remains usable and readable.
- Language, currency, and market presentation match your intended market.
Checkout Must Be Tested as a Real Path
Checkout QA Sequence
Shipping, Email, and Tracking Need to Be Checked Together
Mobile Must Be Tested Separately
Mobile Checks
- Primary CTA is visible and tappable on first screen.
- Product image, price, shipping promise, and trust signals remain readable.
- Checkout fields and country selectors work smoothly.
- Popups or sticky UI do not block core actions.
Final Launch Checklist
Before You Go Live
- Core pages and policy pages complete
- Payment and shipping logic tested
- Email and order notifications working
- Analytics events verified
- Desktop and mobile reviewed
- At least one realistic test order completed
Do Not Launch a Broken Funnel
- If checkout, notifications, or support handling still break, do not launch just because the store looks finished.
- Your first real visitors should not be your QA team.
Execution Advice
The most effective QA workflow is a simple checklist table, not memory. Walk through every core page and customer path deliberately, then fix issues before traffic scaling starts.
QA table fields
- Path: page, checkout, email, shipping, tracking, or support flow.
- Issue: what failed and on which device, market, or browser.
- Owner: who fixes it and when it must be retested.
- Acceptance: what proves the path is ready for launch.
Tracking and attribution need separate launch acceptance
Many teams test pages and payments but forget that analytics and ad systems are also part of the launch path. If `view_item`, `add_to_cart`, `begin_checkout`, `purchase`, Pixel/CAPI, or UTM naming breaks after launch, budget can drift before the team notices.
Data and attribution QA order
Mobile QA must check interaction, not only pages
The expensive mobile failures are often input, scrolling, popups, address fields, sticky buttons, and payment handoff issues, not whether the page opens. Desktop success does not prove the mobile order path is ready.
Mobile issues that are easy to miss
- Country, province, postal code, and phone fields behave differently across markets.
- Newsletter popups, chat widgets, or sticky bars cover checkout buttons.
- Payment buttons move below the fold after the keyboard opens.
Test failure paths, not only successful checkout
A single ideal test order does not reveal what real customers will hit. Walk through failed payment, invalid address, out-of-stock, expired discount, missing email, and unreachable support paths before launch.
Failure-path checklist
- Failed payment shows a clear next step instead of a dead end.
- Invalid addresses and unavailable regions explain what the customer can change.
- Out-of-stock and expired promotion states do not leave misleading promises on the page.
- Support entry points work when the order cannot be completed.
Launch QA needs final acceptance through a real order path
Shopify test order documentation states that test orders can verify checkout, order processing, inventory, shipping, email notifications, and tax settings. Pre-launch QA should simulate a customer path from site entry to notification instead of only checking that pages load.
Final launch acceptance
- Home, collection, product, cart, checkout, policy, and contact paths are accessible.
- Mobile order completes, and shipping, tax, discount, payment, and refund are recorded.
- Customer notifications, staff notifications, GA4 events, and ad conversion events fire.
- Freeze non-essential apps, theme rewrites, and payment setting changes on launch day.
Lesson closeout: launch QA handoff packet
If the desktop homepage looks good but the mobile product-page button is covered, ad traffic will expose a QA problem, not an ad problem.
Bring this evidence before handoff
- Scenario: If the desktop homepage looks good but the mobile product-page button is covered, ad traffic will expose a QA problem, not an ad problem.
- Evidence: Keep one real path, one failure risk, one owner, and one acceptance screenshot or record.
- Action: Keep one main next action and define when it will be reviewed.
- Handoff: Before first traffic, pass page checks, test order, email screenshots, GA4/pixel events, policy entry, support entry, and unresolved issue list.
Before first traffic, pass page checks, test order, email screenshots, GA4/pixel events, policy entry, support entry, and unresolved issue list.
Operating calibration: test the settings that can cost real money first
The launch risks that create immediate losses are usually shipping, payments, policies, tracking, and app costs rather than theme color. Treat each checklist item as a real transaction test: can the store take payment, ship, refund, send email, and record GA4 plus ad conversions correctly?
- Test domestic, international, and remote shipping addresses instead of trusting the default rate table.
- Place a test order and verify payment, refund, email notifications, order status, and support access.
- Freeze non-essential apps before launch so fees and page speed do not grow before conversion is proven.
Cross-platform calibration: prove the promise, product, and order path together
The content-to-purchase path gives a practical launch standard: people do not move from homepage to revenue in one jump. They see a promise, click a product, verify price and policy, then order. Run launch QA across that chain.
- Any promise used in ads, posts, or organic content needs matching proof on the product, policy, and checkout pages.
- After publishing products, check inventory, shipping, price, discount, and return rules so high-intent traffic does not hit basic setup friction.
- Test orders should cover visit, product click, add to cart, checkout, payment, notification, and support access.