Why is QA So Important in Ecommerce Websites?
I think when some people hear the term ‘QA’ they are inclined to interpret it as ‘perfection guaranteed’. As most of us are aware, perfection is rare, and something as complex as a website will never be entirely free from bugs - or the risk of bugs developing over time.
Therefore QA is best thought of as damage limitation and an ongoing maintenance process. Although this might not seem as alluring as the promise of a perpetually pristine website, the inclusion of a robust QA process will significantly reduce the number of bugs your Shopify website is likely to have.
As well as spotting bugs, QA helps identify the specific circumstances in which a bug occurs as well as suggesting improvements regarding UX (the user experience) and UI (the user interface).
In the context of ecommerce, QA is important because it
Avoids lost sales due to errors or bugs
Enhances user trust and satisfaction
Protects sensitive data (like payment and personal information)
Supports business growth and scalability
What Do We Test On Ecommerce Websites?
QA tests against any specifications the client provides, as well as comparing the developed website to what the designers intended, along with general expectations for a retail website, and Shopify standards. The core of testing involves imitating customer behaviour - not only how store-owners would like them to behave on the site, but also unexpected behaviours (often referred to as ‘destructive testing’).
As there is usually common ground between different online stores (and especially Shopify stores), the suite of tests performed are suggested by the subject - the given page or feature. Tests can be broadly categorised as visual and practical.
The most crucial aspect of testing is the customer journey - arriving on the homepage, adding products to the cart, then progressing to the checkout. After all, most people visiting a Shopify website expect to be able to shop!
Basic behaviours tested for include checking the correct number of products (at the correct price) is added to the cart, that the cart subtotal updates accurately, that when the relevant button is clicked the user is taken to the checkout, that the number on the Cart icon in the Header area matches the total number of products in the cart etc. Whilst checking off these expected behaviours we must also be on the lookout for unexpected results.
Including more content and functionality on a page raises the number of potentially conflicting variables.
Is the correct size variant added to the cart?
Is the correct size variant added to the cart after a different one has already been added?
If the correct size has been added, is it in the right colour?
Did the swatch colour on the page update to match?
QA cannot undertake every test case imaginable. Even with a relatively simple website, the various combinations of possible actions add up quickly. Some bugs will only present themselves in very specific circumstances following a long or improbable sequence of events. As with scientific testing in general, a case could be tested and found to be satisfactory for every one of a thousand tests - but if the testing continued, every subsequent test may prove a failure.
A website is a complex machine in constant use, with parts being changed, removed or introduced over time - sometimes with surprising results!
Examples of Common Ecommerce QA Issues
1. Broken Checkout Process
Issue: Customers can’t complete purchases due to missing steps, failed payment integrations, or unresponsive buttons.
Cause: Incomplete validation, third-party API errors (like payment gateways), or browser-specific bugs.
Impact: Direct revenue loss and high cart abandonment rates.
2. Poor Mobile Responsiveness
Issue: Layouts break or become unusable on mobile devices (e.g., buttons overlap, text cuts off).
Cause: Inadequate responsive design testing across screen sizes.
Impact: Bad user experience for mobile shoppers (who often make up 60%+ of traffic).
3. Slow Page Load Times
Issue: Pages take too long to load, especially product and checkout pages.
Cause: Unoptimised images, bloated code, excessive third-party scripts.
Impact: Increases bounce rate and hurts SEO rankings and conversions.
4. Search or Filter Functions Not Working Correctly
Issue: Product search returns irrelevant results or filters don’t apply correctly.
Cause: Faulty back-end logic, indexing issues, or JavaScript errors.
Impact: Frustrates users, reduces product discoverability, and lowers sales.
5. Inconsistent Inventory or Pricing Display
Issue: Products show incorrect stock levels or different prices across pages.
Cause: Sync issues between front-end and inventory or pricing systems.
Impact: Customer complaints, lost trust, and potential legal issues for pricing errors.
QA Processes and Frameworks We Follow
When Does QA Get Involved?
QA will typically become involved in the process once the Developers have completed a page or feature. This could be as part of a website Radiant is building for a client, or it could be for one of our Ongoing Success clients, whose website we may not have developed, but are now helping to improve.
(The other instance in which QA will generally become involved is when a client has experienced a bug on their website. In this event, QA often begins by attempting to reproduce the bug and record any important details.)
Once the developer has completed the required task, they add details on how to access the correct theme and page or area of the site, and forward it to me.
How Do We Test?
I have a list of browsers, mobile phones and tablets representing what an average online shopper might use, and I work through the same series of tests on each one.
Many tests will be applicable to most tasks, whereas some will require tests more specific to their category and others may require bespoke tests to be undertaken.
Often new pages or features will require a review against the designs, for example checking that font qualities like size and colour are as intended, and making sure the layout and shapes used are correct.
Not all QA testing takes place on the frontend of the website. The specifications of a page or feature often require the developer to create or modify client-facing parts of the Shopify backend - elements the client is expected to be able to interact with in order to change the layout or content. In these instances QA will check that the relevant components have been included in the Shopify customiser and admin pages and that they work as intended.
How Do We Collect, Report and Fix Bugs?
Each bug found is written up as a short report in its own subtask. All the details the developer will need to locate the bug themselves are included - typically things like what page or pages the issue happens on, where on the page, perhaps the steps the user must take for the bug to occur, and screenshots and videos to illustrate the problem. All these subtasks are collected under one umbrella task, making it easy to check off each bug as it is resolved.
When the subject of the task has undergone the relevant tests on all platforms it is returned to Client Services for review before being handed back to the developers. They will then attempt to resolve the bugs based on the information provided by QA.
Once they have worked through all the bugs on the task it is returned to QA, who then attempt to reproduce the issues. If the bug is fixed the subtask can be closed - if not, further notes are added to the subtask. Any new issues discovered at this stage are added as their own subtasks.
Occasionally the developer will come up against an obstacle preventing them from resolving a bug. In these instances QA will attempt to find further information to aid them, or work with the developer and Client Services to find a solution, or at least a decent compromise when a technical solution really is totally impractical.
If all the bug subtasks are closed then the page or feature is considered ready to be published or deployed. If any bug subtasks on the task remain open, the task is sent back to the developer for further work and the process is repeated until all issues can be closed.
Tools and Software Used by QA
Browserstack
This allows the user to simulate how a webpage behaves on various mobile phones and tablets. (Although this is a useful tool, it does not always match what is seen on a physical device.)
VPN (Tunnel Bear)
This tool allows me to convince my desktop computer or mobile phone that I am in a different part of the world. It is used to test functionality specific to the user accessing a website from a different country.
Google Inspect
This is a browser tool that helps me check the qualities of fonts, or on rarer occasions whether a certain piece of code is present on the page.
Loom
Loom allows me to make videos straight from my screen on the desktop, which I can then share as simple links. I use a similar tool to record videos on mobile too.
Page Ruler
This tool is useful for checking the size of visual elements, and the distance between them.
In summary, QA is not just a step in the design and development process - it’s part of our culture at Radiant, and represents our commitment to quality. If you work with Radiant for a new website build, or for us to help optimise your existing website, rest assured that our rigorous and robust QA processes will be applied to all the work we do. If you’d like to speak to us about a website project or ongoing services, get in touch with our team here.
