Launch QA is not a quick browse. It is turning critical paths into evidence.
This lesson first sorts issues into pause launch, fix before launch, can fix after launch, and watch after launch, then turns pages, payment, shipping, email, data, policies, support, mobile, and exception paths into one launch regression sheet. Without order number, screenshots, event records, review lead, and retest status, QA is not done.
The previous lesson leaves a shipping promise and exception matrix: a named market and SKU with its representative checkout rate, handling/transit wording, first-scan and tracking evidence, duties wording, exception boundary, and pause action.
That matrix tells you what to test, butit does not prove that a real buyer can complete payment and an order, or prove carrier performance, a duties outcome, payment settlement, or launch approval. The same promise still has to pass the current purchase, order, email, data, and support paths.
This lesson turns it into a launch regression evidence board: choose a path, keep the proof, then take the next Go, Soft launch, Hold, or No-go action;a record or selected card is not launch approval.
Reviewing the homepage is not launch QA
Post-launch failures usually are not about whether the homepage looks good. They happen in mobile buttons, failed checkout, shipping surprises, missing email, missing GA4 purchase, hidden policy entry, or unreachable support. Launch QA accepts evidence, not vibes.
User path
Home, collection, product, cart, checkout, policies, and contact entry work on mobile.
Mobile/desktop screenshots or recording with device, market, browser, and test time.
Wrong CTA, blocked mobile button, or missing policy entry means no public traffic yet.
Click the path you worry about most. The panel shows what must pass, what evidence to keep, and what should stop if it fails; this choice is automatically added to the final copyable lesson notes.
Launch a 20oz tumbler without making first ad traffic your QA team
Assume you are launching a 20oz tumbler. Ads promise 2-5 day delivery and free shipping over $49, with first traffic from Meta and Google. Launch QA has to connect promise entry, order path, and data path: buyer-facing promises, Shopify order records, and GA4/Pixel/CAPI purchase events must reconcile.
Promise entry
Order path
Data path
The scanner is an entry point, not the conclusion
The readiness scanner can surface obvious gaps in public pages, policies, contact entry, mobile performance, and basic tracking. It cannot replace real purchase testing. Scan first, then manually test order, refund, data, and exception paths.
- 1Confirm production domain and HTTPS are accessible.
- 2Make sure homepage is not passworded, placeholder, or unfinished.
- 3Open policies, contact page, and primary product page.
- 4Run the scanner first, then use the report to guide manual QA.
After opening the scanner, do not stop at a score. Choose the closest issue type from the report; the panel shows what fields to bring back, what proof still needs manual testing, and what to write into copyable notes.
Policy and trust-entry gaps
The report flags missing, broken, or unreachable privacy, refund, shipping, contact, or footer links.
Bring failed URL, page type, HTTP status, screenshot time, and review lead back to the QA table.
Manually open the pages on mobile and confirm buyers can find the same promise from product page, footer, and checkout.
Write back whether the policy gap blocks launch, fixed links, retest time, and whether soft launch is allowed.
After choosing, read its evidence and Stop condition first.A selected path is not a release conclusion.Only after the same market/SKU promise appears in an order, email, data, or exception record can you decide whether to collect proof, Hold, or continue testing.
The scanner is not one score. Seven release gates need separate calls.
The common launch mistake is treating a mostly passing scanner as permission to combine payment, mobile, tracking, policies, SEO, speed, and support entry into one “good enough” call. Split them. Each release gate has a scanner signal, manual proof, Go condition, Hold condition, and copyable-note write-back. Choose the weakest gate and use the selected result panel for the release call.
The scanner report only tells you where to look first.It cannot turn one score into proof that payment, order, mobile, event, or support paths pass.The final launch call still needs an order ID, mobile recording, event screenshot, email sample, and manual retest.
Payment release gate
The scanner can flag payment entry, HTTPS, key-link, and checkout-path risk, but it cannot prove a real payment succeeded.
Run a test order on a real primary-market phone and keep order number, payment status, failed-payment screenshot, and refund or cancellation record.
Test order, successful payment, order email, order status page, and refund/cancellation path all have proof.
Payment button is blocked, redirect stalls, tax/shipping changes unexpectedly, or the order succeeds without an admin record.
Write payment gateway, test-order number, failure point, retest time, and who watches failed payments on launch day.
The final launch call is not another page review. Four lanes decide together.
Scanner reports, test orders, mobile proof, and event screenshots are only evidence sources. The launch call needs one release decision sheet for public surface, checkout/order, tracking/events, and operations/support. Click the lane that feels weakest; the panel shows Go condition, Hold condition, evidence, confirming lead, and what to watch in the first hour.
Public surface lane
When a real visitor arrives from ads, organic search, or the homepage, can they see one consistent product promise, policy entry, and contact path?
Homepage, main collection, primary PDP, footer policies, contact entry, and mobile hero all load, and promises do not conflict.
Policy 404, shipping/return promise conflict, primary PDP still uses placeholder media, or mobile CTA is blocked.
Production domain, primary-market mobile recording, policy URLs, primary PDP hero screenshot, and retest time after fix.
Page/content lead confirms promises; operations lead confirms public entry.
In the first hour, inspect public entry, 404s, mobile hero, and support entry; do not redesign the theme.
Do not just tick the checklist. Decide which faults break ordering.
The final manual check is not reading the table again. It sorts each issue into three actions: fix today and retest, delay and retest, or pause launch. Click the blocker closest to your store; the panel organizes buyer risk, symptom, three actions, and the proof to keep.
Choose the riskiest issue first. This is not asking for a perfect store. It separates what can be fixed today, what needs delayed retest, andwhat directly breaks payment, ordering, promises, or complaints and must pause launch.
Checkout and payment
The buyer reaches the last step but cannot pay, card fails, PayPal does not return, or discount/tax changes. That loses orders directly.
Only one desktop order was tested. Mobile Apple Pay, Shop Pay, PayPal, coupon, tax, and refund path were not tested.
Fix today: payment button hidden, coupon wrong, address copy unclear, or backup payment disabled. After fixing, place one small mobile order immediately.
Delay and retest: payment review, payout hold, tax/currency config change, checkout app, or extension affecting checkout.
Pause launch: primary payment cannot collect, real mobile checkout cannot finish, or refund/cancel path has no confirmation.
Mobile recording, test order ID, payment status, refund/cancel record, discount and tax screenshots.
Write back to payment release gate, Payment Test Order Runbook, and launch QA copyable lesson notes.
Place at least one test order and keep the full trail
Shopify test-order docs include checkout, order processing, inventory, shipping, email notifications, and taxes in the validation scope. The point is not placing a fake purchase; it is proving the chain from entry to order status and refund record.
Click only the paths you actually tested. Do not select everything to make progress look good: the checked count goes into copyable lesson notes and will expose which paths were only verbally accepted.
Issues must close: evidence, review lead, and retest are required
QA is not listing issues. It decides what can ship and what must stop.
A payment issue and a helper-copy issue do not carry the same priority. Before launch, sort issues into Blocker, Must-fix, Can-ship, and Watchlist so the team is not trapped by a pile of pending notes.
Click the tier closest to the current issue. Then put the impact, rule, review lead, and retest method into the QA table; the final copyable notes record your selected tier.
Blocker: do not launch
Payment fails, order misses admin, mobile checkout breaks, core policy is hidden, or production domain is unavailable.
Anything affecting order, payment, fulfillment promise, or support entry cannot ship.
The review lead must be someone who can change settings or coordinate the fix, not a watch note.
After the fix, rerun the same path and attach screenshot, order number, or event record.
When launch QA finds a problem, decide whether real buyers would become your testers
A QA issue should not be left as pending. First decide whether it affects payment, order capture, fulfillment promise, data judgment, or only a small post-launch improvement. These scenarios train launch-blocker judgment.
Click the scenario closest to your store. Then read the tempting wrong move, correct launch call, and first evidence on the right before deciding No-go, Hold, Must-fix, or post-launch watch.
Desktop test order succeeds, but a popup or chat widget covers the payment button on mobile checkout.
Launch anyway, tell buyers to close the popup, or attach only desktop screenshots to the QA table.
No-go. Unstable mobile payment is a launch blocker. Disable or retune the blocking widget, then rerun a mobile test order.
Mobile recording, device/browser, checkout screenshot, test-order result, and the blocking widget name.
Do not run public traffic and do not replace mobile acceptance with desktop proof.
Write back to mobile path, issue tier, review lead, retest screenshot, and launch decision.
QA must end in Go, Soft launch, Hold, or No-go
The risky state before launch is not there are issues. It is there are issues but no one makes the call. Convert evidence and issue triage into four decisions: public traffic, limited traffic, fix before launch, or no launch. First traffic should not be a blind test.
Go: ready for public traffic
Test order, mobile checkout, email notice, refund path, GA4 purchase, policy entry, and support entry all have proof.
Open the first public traffic batch with a small budget and a clear observation window. Do not scale on day one.
Do not rewrite theme, payment, shipping, pixels, or key apps at the same time, or QA evidence becomes stale.
Within 24 hours, review orders, failed payments, support tickets, email delivery, and purchase events. Within 72 hours, review exceptions.
Soft launch: limited traffic
Critical purchase path passes, but Watchlist items remain, such as market-specific shipping conversion, email inboxing, or support load.
Open only core markets, a small SKU set, and small budget to validate real orders and support load.
Do not open all markets, all ad sets, or promo promises. Do not treat Watchlist as fixed.
Review checkout drop, failed payments, shipping inquiries, refund reasons, and event completeness daily.
Hold: fix before launch
Must-fix items remain: they may not block payment, but they increase refunds, inquiries, complaints, or bad data.
Continue scoped retesting, fix copy, add policy entry, and rerun mobile and order paths.
Do not send public traffic or use unaccepted data to judge ad scaling.
On the same day after the fix, retest the same path and attach new screenshot, order number, or event record.
No-go: do not launch
A Blocker exists: payment fails, order misses admin, mobile checkout breaks, production domain is unavailable, or support/policy entry is missing.
Only fix blockers, roll back risky changes, and rerun critical-path regression.
Do not launch, do not run traffic, and do not let real buyers discover blockers for you.
A blocker must be closed by its review lead and retested on the same path by a second person.
In the last 2 hours, stop improvising and make each click, confirmer, and proof visible
Many new stores fail not because nobody checked, but because launch day keeps changing theme, apps, shipping, and tracking. This launch room checklist splits the final 2 hours into five windows: who clicks, who confirms, what proof to keep, and which moves stay frozen. Click a time window to see the execution rule and write it into copyable notes.
Run it from top to bottom. The point is not more checklist items; it is a clicker, confirmer, and proof for each item. Without proof, do not open first traffic.
Open the launch room and pause risky changes
The launch lead closes temporary change lanes for theme, apps, payment, shipping, and pixels, leaving only blocker fixes open.
A second person confirms production domain, password page state, primary product, policy entry, and support entry.
Save screenshots of home, product page, policy entry, support entry, current theme version, and app list.
Unless fixing a blocker, do not change theme structure, add apps, or rewire payment and tracking.
Turn launch-room clicks into device, market, cleanup, and observation records
Use Go, Soft launch, Hold, or No-go for the release call, and also record the scope that is often missed: which device, browser, market, and representative address were tested; how the test order or test state will be cleaned up; and what to watch during the first 24 and 72 hours. These records do not grant release permission.
Primary-market mobile checkout
Record the real phone model, operating system, browser, and available payment method. Do not let desktop developer tools replace every mobile readback.
Limit this to the primary market and representative address you intend to open. Do not turn one address into proof that every country, region, or postal code can check out.
From entry page through product, cart, checkout, payment, thank you, order status, email, and Shopify order, record same-path evidence.
If payment, main SKU, address, shipping, tax, or confirmation page cannot complete, pause public traffic for that path and rerun the same device and address after repair.
During the first 24 hours, watch failed payment, duplicate orders, order email, and support entry; at 72 hours, review whether exceptions repeat.
Block launch
Official pages help review current platform capability and boundaries. They do not replace readback of the real admin, payment, market, theme, app, or device. Official pages checked: 2026-07-26.
Shopify test orders
Scope: Use it to confirm that test orders can check checkout, order processing, inventory, shipping, email notifications, and tax settings, and to review whether the test method affects real ordering.
Lesson use: This lesson puts the test order in one device, market, order, and cleanup record. It does not turn one simulation into a release conclusion.
Shopify test-order documentationShopify cancel, archive, and delete orders
Scope: Use it to check cancellation, refund, inventory, notification, archive, or deletion availability and follow-up impact in the real admin. Available actions depend on order state and payment method.
Lesson use: Treat test-order cleanup as an action that needs admin readback instead of requiring one universal action on real orders.
Shopify order-cancellation documentationShopify web performance reports
Scope: Use it to understand that Shopify admin performance reports can show Core Web Vitals across desktop and mobile experiences and that report data can be delayed.
Lesson use: Record performance reports separately from the real-device path. Do not write a historical report, one score, or simulated result as an immediate user-experience guarantee.
Shopify web-performance documentationShopify theme accessibility practices
Scope: Use it to remind that theme accessibility practices need actual keyboard, focus, content, and assistive-technology review. One check does not prove complete accessibility.
Lesson use: This lesson only brings keyboard and critical-path review into launch evidence. It makes no accessibility compliance conclusion.
Shopify theme accessibility documentationChoose an approach and check whether it records real test scope and evidence first, then returns to the existing decision sheet for a Go, Soft launch, Hold, or No-go call.
Record only non-sensitive information needed for this check. Do not enter customer names, full addresses, order numbers, payment data, account credentials, full recording links, or internal-account screenshots.
This record stays only in this browser or your local download. It does not write to Shopify.
Define CAPI and attribution before accepting the data path
Beginners often get stuck in data QA not because reports are hard, but because they do not know where a term appears, who reads it, and what breaks when it is wrong. Define these two terms before checking purchase events.
CAPI
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.
Where you see it: You usually see it in Meta Events Manager, Shopify apps, server-side tracking, or system-integration settings.
What breaks: If CAPI and Pixel duplicate or miss orders, the ad system learns from the wrong order quality.
attribution
Attribution means assigning order credit to an ad, keyword, content piece, or channel.
Where you see it: You see different attribution views in GA4, Google Ads, Meta Ads, Shopify reports, and UTM reports.
What breaks: If purchase, UTM, or order value is incomplete, you may scale traffic that looks good but does not contribute profit.
Before ads, prove GA4 and ad events are not empty
GA4 ecommerce events are not correct just because the page looks good. At minimum, see view_item, add_to_cart, begin_checkout, and purchase in DebugView or event testing, and confirm purchase parameters such as transaction_id, value, currency, and items are present.
view_itemBuyer viewed a product.
item_id / item_name is not missing.
add_to_cartBuyer added item to cart.
value, currency, and items match cart.
begin_checkoutBuyer started checkout.
Items, value, coupon, and source clues remain.
purchaseOrder completed.
transaction_id, value, currency, and items must be complete.
Mobile is not a smaller desktop. It has its own failure modes.
Mobile conversion often breaks in inputs, keyboard, popups, address fields, sticky buttons, payment redirects, and return path. Desktop success does not prove mobile readiness.
Click only items you tested on a real device or mobile viewport. The mobile checked count is written into copyable notes; if there is no recording or screenshot, do not check it.
Testing only successful checkout misses where real buyers get stuck
Choose the exception path you worry about most. The selected result panel shows how to test and what acceptance means; this choice enters the final copyable notes so you do not test only successful orders.
Buyer sees clear guidance and can retry or switch payment method.
No dead end, and support knows how to look up the failed order.
If there is no evidence, do not mark it checked
You reviewed home and product pages, but have no test order number, mobile checkout screenshot, or GA4 purchase record. What is the right decision?
Launch day needs stable paths, not more decoration
On launch day or first-traffic day, do not stack major changes. Every theme, payment, tax, shipping, app, or pixel change can invalidate the evidence you just collected.
Do not redesign home, product, pre-checkout path, or mobile structure on launch day.
Unless fixing a blocker, do not change multiple real-order settings at once.
Before conversion is proven, avoid adding fees, scripts, and page-speed load.
Pause event-structure changes after acceptance so first data is usable.
The QA table tells you what to fix next
Exception paths lack a response path
Turn refunds, lost parcels, missing emails, failed payments, and inquiries into a support response path.
Build support response pathTurn this lesson into launch QA copyable notes
Do not end with I checked everything. This section automatically includes your selected regression path, issue tier, blocker scenario, mobile count, exception path, and next route; then you add current pressure, first evidence, this-week action, stop action, review window, and next route.
Current regression path: User path - Wrong CTA, blocked mobile button, or missing policy entry means no public traffic yet. Checked critical paths: 2/6 Issue tier: Blocker: do not launch - Anything affecting order, payment, fulfillment promise, or support entry cannot ship. Launch blocker scenario: Mobile payment button is blocked - No-go. Unstable mobile payment is a launch blocker. Disable or retune the blocking widget, then rerun a mobile test order. 2-hour launch room: T-120 minutes Open the launch room and pause risky changes - Unless fixing a blocker, do not change theme structure, add apps, or rewire payment and tracking. Store Launch Readiness Scanner write-back: Policy and trust-entry gaps - Write back whether the policy gap blocks launch, fixed links, retest time, and whether soft launch is allowed. Scanner release gate: Payment release gate - Write payment gateway, test-order number, failure point, retest time, and who watches failed payments on launch day. Launch release decision sheet: Public surface lane - In the first hour, inspect public entry, 404s, mobile hero, and support entry; do not redesign the theme. Final manual launch check: Checkout and payment - Payment affects revenue. Do not release it just because the button appears clickable. Launch evidence matrix: Primary-market mobile checkout - Block launch Launch evidence gates: 0/5 Launch evidence decision: ___ Test target and current opening scope: ___ Device, browser, and market readback: ___ Evidence location and issue severity: ___ Test-order and test-state cleanup: ___ Current decision and pause condition: ___ First 24 / 72 hour observation: ___ Mobile acceptance: 1/4 Exception path: Failed payment - No dead end, and support knows how to look up the failed order. Quick check feedback: No quick check answer selected yet Next route: Exception paths lack a response path - Turn refunds, lost parcels, missing emails, failed payments, and inquiries into a support response path. Current pressure: ___ First evidence: ___ This-week action: ___ Stop action: ___ Review window: ___ Launch release decision sheet: ___ Final manual check conclusion: ___ Next route: ___