01 / Make the catalogue a launch deliverable
Agree who owns product names, descriptions, images, prices, stock information and variant data. A theme can be ready while the catalogue still contains sample text, mismatched images or unclear options. Those are customer-facing launch issues, not just content tasks to finish later.
Pick representative products for testing: a simple item, an item with several variants, an unavailable item and a product with a delivery restriction. Confirm that the selected size, colour or pack changes the appropriate information and stays selected in the cart.
Write descriptions that answer practical questions. What is included? How is the item used? What dimensions or compatibility details matter? Where a claim needs evidence, the merchant should supply that evidence before publication. Clear product information can prevent an unsuitable purchase more effectively than another promotional badge.
02 / Review the customer journey on a real phone
Start from the page a visitor will actually land on. That might be a product or collection rather than the homepage. Check that the image, price, availability and main purchase action are understandable before asking someone to explore further.
Try search and navigation with realistic product names. Use filters where they exist, change the selected variant, add an item, change its quantity and remove it. Inspect both the cart drawer and full cart page if the theme provides both.
Test with the keyboard open and on a smaller screen. Sticky purchase controls, cookie settings and chat buttons should not cover important messages. Keyboard navigation and visible focus are useful checks even when most purchases are expected to happen on touchscreens.
A store that looks impressive in a desktop screenshot can still be difficult to buy from. Record a short description of each failure, its device and the exact product or variant involved so the development team can reproduce it.
03 / Agree the checkout and delivery rules
Document the intended payment methods, shipping destinations, delivery charges, applicable discounts and any purchase restrictions. The developer should implement agreed rules; they should not invent the business policy during theme development.
Test a supported destination and an unsupported destination, a single-product basket and a mixed basket, and a valid discount if one will be available. Compare the displayed totals with the merchant’s expected results. Treat tax and legal wording as items for the merchant and its appropriate advisers to confirm.
Place clear shipping, return and contact information where a shopper can find it. Confirm that the displayed policies match the actual fulfilment process. If the store will serve multiple countries, check currency, market availability and delivery messaging for each supported journey instead of assuming one default test covers every market.
04 / Follow a test order beyond checkout
Use Shopify’s supported testing options and the payment provider’s current instructions. A simulated payment can help validate checkout without processing a real purchase. Coordinate test mode carefully: a payment provider in test mode cannot take live customer orders.
After the order is created, check the order details, selected variants, shipping choice, notification content and the merchant’s next action. If a warehouse, courier or inventory system is connected, agree a safe test process with that provider. A storefront confirmation does not prove that every external integration received the order correctly.
Label QA records clearly and keep them out of sales and advertising-success totals. Record which payment scenario was tested and which was not. A successful simulated order is evidence about that tested workflow, not a promise that every future payment will succeed.
Before opening the store, confirm the production payment configuration and repeat the agreed launch checks. Make one named person responsible for the final switch and for confirming that the store is no longer in its temporary testing state.
05 / Give migration and search their own checklist
If an existing site is being replaced, collect important old URLs before launch. Map retired product, collection and content pages to relevant destinations. Sending every old link to the homepage can leave visitors without the item or information they expected.
Test redirects after deployment, including the final destination and unnecessary redirect chains. Shopify’s built-in redirect system has reserved-path and active-page limitations; review the platform documentation for the exact routes in your migration. Check market-specific paths separately where they are part of the store.
Also review page titles, product descriptions, image alternatives, internal navigation and the sitemap. Keep a record of what changed so post-launch checks can distinguish a broken route from an intentional catalogue decision. Redirects and metadata are useful controls, but they cannot guarantee that search rankings remain unchanged during a migration.
06 / Hand over ownership, not just a login
The merchant should know who controls the store, domain, payment configuration and third-party subscriptions. List app costs and ownership separately from the development fee. Use appropriate staff or collaborator access rather than passing shared passwords around a project.
A handover should show how to edit a product, change availability, inspect an order, update delivery information and ask for help. Record the launch version and recovery steps. Restoring a theme does not automatically undo changes to orders, apps or store settings.
For each issue, record the expected behaviour, actual result, evidence, owner and next action. Use “passed,” “failed” and “not tested.” An unavailable test is not a pass.
Separate launch blockers from later improvements. A broken payment journey, wrong purchase total or missing order handoff needs a different response from a small spacing issue. Agree that distinction before the final review so the launch decision does not become a discussion about which screenshot looks best.
07 / Put the checks into the project scope
For Shopify development in Delhi, use this checklist to agree responsibilities alongside theme design and development. A new store, redesign and migration have different risks, even when the storefronts look similar.
If the platform is still being chosen, discuss the catalogue, ordering process, integrations and ongoing ownership first. Our ecommerce website development in Delhi page explains the service scope, while a project discussion can establish which checks apply to the actual business.
Platform references
Check the linked documentation for current platform behaviour and limitations.
Prepared with AI assistance. These are planning and QA guides, not claims about measured project results.
From the checklist to your project
Let’s make the next step clear.
Share what you want to build or improve. We’ll discuss the requirements and an appropriate scope.




