DEV Community: EHUB IT Web Solution

Test a Shopify Store as an Order Workflow, Not a Collection of Screens

Nehal Gulati — Mon, 26 Oct 2026 10:12:54 +0000

A storefront review often starts with screenshots: the homepage, a collection grid, and a product page. Those screens matter, but a customer buys through a sequence. A release needs to be reviewed as that sequence, including the work that happens after checkout.

The useful question is not simply whether each page loads. It is whether a person can choose the right item, understand the total, complete checkout, and receive the information the merchant needs to fulfil the order.

Build a small test matrix before reviewing the theme

Choose representative products rather than testing only the easiest item. A compact matrix might include:

Case	What to inspect	Evidence to retain
Product with variants	Selected option, image, price, availability	Variant and resulting cart line
Unavailable item	Purchase controls and availability message	Product state and storefront result
Multi-item cart	Quantities, discounts, shipping eligibility	Cart and checkout totals
Supported destination	Applicable shipping options	Test destination and options shown
Unsupported destination	Clear delivery restriction	Expected message
Cancelled checkout	A safe route back to the store	Customer-visible result

Use the merchant's actual rules to decide expected results. Do not label a behaviour a bug merely because another store handles it differently.

Record the theme version or release identifier, device, browser, test data, expected behaviour, and observed behaviour. A screenshot with no product, variant, or release context is difficult to reproduce later.

Separate visual review from purchasing review

During visual review, inspect product imagery, readable pricing, variant labels, focus states, and mobile overflow. Then repeat the journey using a keyboard and a real mobile device where available.

During purchasing review, check that the chosen option survives into the cart. Change quantities, remove an item, return to a product, and try the drawer and full-cart page if both exist. Confirm that the final price, delivery information, and applicable discounts match the agreed business rules.

Avoid measuring success through a single ideal journey. A product that behaves correctly on its own may expose a different shipping or discount outcome when combined with another item.

Verify the order after the confirmation screen

Shopify provides supported ways to simulate payment. Its test-order documentation explains the available options and requirements. Customers cannot place live orders through a payment provider while it is in test mode, so coordinate testing and restore the live configuration deliberately.

For each representative test, inspect the resulting order, variant details, shipping selection, notification content, and operational handoff. Where an inventory or fulfilment integration is involved, use its sandbox or the provider's agreed testing process. A storefront confirmation does not establish that an external warehouse received the order correctly.

Keep simulated orders clearly labelled. They are QA records, not revenue, customers acquired, or evidence of a successful advertising campaign.

Treat migration URLs as a separate release item

Before changing URLs, export or document important existing paths and map each retired path to a relevant destination. Test the mapping after deployment rather than assuming a completed import means the redirects work.

Shopify's built-in redirects have limitations: a source that still resolves to an active page will not behave like a broken URL, and certain reserved paths cannot be redirected. Consult the current redirect documentation for the paths involved in your migration.

For each important mapping, capture the old URL, response status, and final destination. Look for loops and unnecessary chains. Test market-specific routes individually when language or regional paths are in use. Do not send every retired product to the homepage simply to avoid a visible error.

Give the merchant a release decision they can understand

Use three outcomes: passed, failed, and not tested. Assign an owner and a next action to unresolved items. A test that could not run is not a pass.

Before launch, agree which failures prevent release and which can be scheduled later. Broken purchasing, incorrect totals, or a missing operational handoff need a different response from a minor spacing issue. Preserve a known working theme and record the recovery steps, but remember that reverting a theme does not automatically undo order, app, or configuration changes.

The EHUB Shopify store launch checklist provides additional context for agreeing catalogue and market requirements before this test plan is written.

A release becomes easier to support when its acceptance evidence describes an entire order journey, with clear limits on what was actually verified.

Published by EHUB. Prepared with AI assistance.

A Mobile Enquiry Form Is a Small State Machine

Nehal Gulati — Mon, 26 Oct 2026 10:11:43 +0000

A form can look finished while its most important behaviour is still undefined. What happens when the network fails? What does a second tap do? Does the success message mean the server accepted the enquiry, or only that JavaScript ran?

Treating the form as a small state machine makes those questions easier to answer. This walkthrough covers a contact form, but the same approach works for demo requests and project enquiries.

Start with four states

Use idle, submitting, success, and error. Browser validation happens before the submit handler runs. The handler then moves into submitting; only the server response determines whether it can move into success.

State	Submit button	Message	User input
Idle	Available	Brief instructions	Editable
Submitting	Disabled	Sending	Preserved
Success	Available	Request accepted	Clear only after acceptance
Error	Available	Actionable retry message	Preserved

A disabled button reduces accidental double taps. It does not provide server-side duplicate protection: that requires an idempotency mechanism or another deliberate backend rule.

Keep the HTML useful before JavaScript

Give every field a visible label. Use autocomplete tokens to make mobile input less tedious. A telephone field helps the keyboard, but it does not establish that a number is valid or reachable.

<form action="/enquiries" method="post" id="enquiry-form">
  <label for="contact-name">Your name</label>
  <input id="contact-name" name="name"
         autocomplete="name" required maxlength="100">

  <label for="contact-phone">Phone number</label>
  <input id="contact-phone" name="phone" type="tel"
         autocomplete="tel" required maxlength="30">

  <label for="project">What would you like to build?</label>
  <textarea id="project" name="project"
            rows="3" required maxlength="2000"></textarea>

  <button type="submit">Send enquiry</button>
  <p role="status" aria-live="polite" id="form-status"></p>
</form>

The action is illustrative: a real application needs a matching server route. That route should support ordinary form submission as well as the enhanced JSON response. Add the application's CSRF protection, server validation, abuse controls, and appropriate privacy information before deployment.

Define what acceptance means

For an enhanced request, establish a response contract such as:

{ "accepted": true }

The server should return this only after it has durably recorded or queued the enquiry according to the application's design. An accepted enquiry is not proof that an email reached an inbox, a salesperson responded, or a sale occurred.

const form = document.querySelector('#enquiry-form');
const button = form.querySelector('button[type="submit"]');
const status = document.querySelector('#form-status');
let submitting = false;

form.addEventListener('submit', async (event) => {
  event.preventDefault();
  if (submitting) return;

  submitting = true;
  button.disabled = true;
  status.textContent = 'Sending your enquiry…';

  try {
    const response = await fetch(form.action, {
      method: 'POST',
      headers: { Accept: 'application/json' },
      body: new FormData(form)
    });
    const result = await response.json();

    if (!response.ok || result.accepted !== true) {
      throw new Error('Enquiry was not accepted');
    }

    status.textContent = 'Your enquiry has been received.';
    form.reset();
  } catch {
    status.textContent =
      'We could not confirm receipt. Please check your connection or contact us.';
  } finally {
    submitting = false;
    button.disabled = false;
  }
});

fetch() does not reject just because the server returns an HTTP error. The explicit response.ok check matters. Malformed or unexpected JSON also goes through the error path here.

A lost response creates an awkward case: the server might have accepted the request even though the browser cannot confirm it. Preserve the input and use honest wording. For stronger retry guarantees, implement a server-recognised idempotency key rather than assuming a second request is safe.

Test the unsuccessful paths too

Before launch, check an empty submission, invalid input, a slow response, a server error, and a rapid double tap. Verify keyboard navigation, visible focus, readable labels, and a success message announced without moving focus unexpectedly. Use synthetic contact details in a test environment.

If analytics is added, place the enquiry event after confirmed acceptance and honour the site's measurement preferences. Do not put contact details or the free-text message into an analytics payload. A button click should remain a separate interaction event.

For the business-side decisions behind the fields, the EHUB mobile enquiry-form planning guide covers what to agree before implementation.

Technical references: HTML forms and Fetch response handling.

Published by EHUB. Prepared with AI assistance.