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, responsible person, 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.
Pre-launch QA accepts test evidence, not looks fine
Launch QA is not browsing the homepage once. You need to test the user path, payment path, fulfillment path, and data path one by one, then keep screenshots or order IDs. If the only proof is someone saying it was checked, the team will not know where to debug when launch traffic exposes a break.
| Test path | Must work | Stop this if it fails |
|---|---|---|
| Purchase path | Mobile browsing, add to cart, checkout, payment, order email | Stop ads and public launch |
| Fulfillment path | Order enters admin, shipping, tracking, refund flow | Stop large-volume order intake |
| Data path | GA4, pixel, UTM, order value, and event records | Stop scaling decisions based on data |
Completion standard
Finish at least one test order, one refund test, one full mobile-path recording or screenshot set, and confirm the matching backend data.
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, responsible person | Every issue has a responsible person, status, and retest time |
Worked ecommerce scenario: pre-launch QA for a 20oz tumbler
Assume you are launching a 20oz tumbler. Ads promise 2-5 day delivery and free shipping over $49, and the first traffic will come from Meta and Google. Launch QA is not only checking whether the homepage looks polished. It connects the promise entry, order path, and data path: what buyers see, what Shopify records, and what GA4/Pixel/CAPI records as purchase must reconcile.
| Path | Evidence to inspect | Common wrong move | Next action |
|---|---|---|---|
| Promise entry | PDP, Shipping policy, and checkout show the same delivery timing and free-shipping threshold | Only checking homepage visuals and skipping the primary-market address until checkout shows high shipping | Use a primary US address to capture cart, checkout, shipping, tax, and policy screenshots |
| Order path | Test order number, payment screenshot, customer email, staff notice, refund record, and inventory change | Only checking that the payment button appears without confirming admin order or email delivery | Add the order number and refund record to copyable lesson notes as launch evidence |
| Data path | GA4 DebugView, Meta Pixel/CAPI testing, and Google Ads conversion diagnostics show purchase, value, currency, and transaction_id | Starting traffic because Shopify has an order while GA4 and ad events show no purchase | Fix Pixel/CAPI, UTM, purchase parameters, and thank you / order status tracking before judging scale |
Launch Blocker Triage Lab: do not let real buyers become your testers
Launch QA is not just a list of pending issues. First decide whether the issue blocks payment, order capture, fulfillment promise, data judgment, or support access. Problems that stop real buyers from ordering cannot launch. Problems that create refunds, questions, or complaints must be fixed before launch. Small experience issues that do not affect purchase or promises can move into the first-week fix pool.
| Signal | Wrong move | Correct call | First evidence |
|---|---|---|---|
| Mobile payment button is covered by a popup or chat widget | Use desktop proof and call QA done | No-go: fix the widget, then rerun a mobile test order | Mobile recording, device, test-order result, widget name |
| Shopify has a test order, but GA4 or ad testing shows no purchase | Start a small budget and wait for reports | Hold: data is not accepted, so do not use it for scaling calls | Order number, DebugView, pixel/tag test screenshot, purchase parameters |
| Primary-market address shows high shipping, no delivery, or unclear duties | Launch first and explain when buyers ask | Must-fix: repair shipping rules, page promise, and policy wording | Primary-market address screenshot, shipping/duty display, PDP promise, shipping policy |
| Thank you / order status tracking or app pixel compatibility is unclear | Payment works, so tracking can wait | Hold or soft launch: confirm checkout/accounts editor scope, app compatibility, and tracking state | Checkout configuration, thank you/order status screenshots, app pixel status |
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.
- Responsible person: 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.
Define CAPI and attribution before checking data
CAPI means Conversions API. It lets the server send order, cart, and checkout signals to ad platforms instead of relying only on the browser Pixel. You usually see it in Meta Events Manager, Shopify apps, server-side tracking, or system-integration settings. If CAPI and Pixel duplicate or miss orders, the ad system learns from the wrong order quality.
Attribution means assigning order credit to an ad, keyword, content piece, or channel. You see different attribution views in GA4, Google Ads, Meta Ads, Shopify reports, and UTM reports. If purchase, UTM, or order value is incomplete, you may scale traffic that looks good but does not contribute profit.
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 redirect 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.
Official QA boundary: accept launch 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. If you do not have an order number, payment or refund record, email screenshot, mobile proof, and event screenshot, the QA is not accepted yet.
| Official boundary | How this lesson uses it | Evidence before release |
|---|---|---|
| Shopify test orders | Use a test order to verify checkout, order processing, inventory, shipping, email notifications, taxes, refunds, and admin order state. | Test order number, success page, admin order, customer email, refund record, and inventory-change screenshot. |
| Shopify checkout editor | Checkout, thank you, order status, and customer accounts share an editor boundary, and customization scope differs by plan. When checkout friction appears, classify it as a setting, app, plan, or development issue first. | Checkout configuration, thank you / order status screenshots, app state, and editable-scope decision. |
| GA4 ecommerce reports | GA4 ecommerce reports depend on events such as view_item, add_to_cart, begin_checkout, purchase, and required parameters. After the test order, reconcile order ID, value, currency, and transaction_id. | DebugView / Realtime screenshot, purchase parameters, UTM test link, and Shopify order screenshot. |
Copyable lesson notes: launch QA acceptance record
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. Do not finish this lesson by writing "I checked everything." Leave a record that another person can review and continue.
Your copyable notes should include these 6 fields
- Current pressure: Mobile payment, test order, shipping promise, GA4/Pixel/CAPI, policy entry, or support entry that blocks launch.
- First evidence: Order number, mobile recording, DebugView, Pixel/CAPI screenshot, primary-market shipping screenshot, email screenshot, and responsible person.
- This-week action: Fix blockers, rerun test order, repair policy/shipping, fix purchase parameters, and freeze launch-day changes.
- Stop action: Before test order, mobile proof, or purchase event exists, do not run public traffic, scale, or change several core settings.
- Review window: Within 24 hours review orders, failed payments, email, support, and purchase; within 72 hours review exceptions.
- Next route: Support playbook, fulfillment setup, or system integration depending on the biggest blocker.
When you share this note with the next operator, the point is not proving that you checked. The point is making it clear whether traffic can start, what must not change, and what the first review should inspect.
Launch-day freeze table: stabilize the paths that can cost money
The launch risks that create immediate losses are usually shipping, payments, policies, tracking, and app costs rather than theme color. On launch day, protect the paths you already accepted, then read the first real orders and exceptions.
| Freeze first | Why it matters | First-day review |
|---|---|---|
| Theme rewrites, popups, chat widgets, checkout apps | These changes can cover mobile buttons, alter checkout, or invalidate the QA proof you just collected. | Mobile recordings, add-to-cart / checkout taps, failed payments, and where users get stuck. |
| Shipping, duties, discounts, return promises | These promises affect orders, refunds, support, and ads, so they should not be rewritten while traffic is starting. | Primary-market orders, shipping surprises, coupon failures, refund/cancel requests, and support questions. |
| Pixel/CAPI, GA4, UTM, thank you / order status tracking | Tracking changes affect first traffic decisions. Without purchase evidence, do not use reports to scale. | purchase, value, currency, transaction_id, ad test events, and Shopify order reconciliation. |