QA

Launching a new ecommerce site? Here’s how to do your QA right

Are you planning to launch a new ecommerce site? Refresh your existing one? New sites are always exciting, to both site owners and customers and with the right approach to QA, you can ensure that your customers have a positive experience when they visit your brand new online store. I have tried to point out areas (on a high level) that we should focus on for the functional QA and recommendations for them (if any) by also stepping into the shoes of an end-user.

Where QA Fits within the New Ecommerce Site Lifecycle

There are six software development lifecycle phases (SDLC) when building any new website: discovery, design, develop, demo, deployment and ongoing maintenance. QA (Internal QA) fits within the demo phase, and it gets the lion’s share of the timeframe. When Something Digital works with clients, we dedicate a large portion of the project timeline to QA within the demo phase.

Why so much time? QA covers a lot of ground; we need to test use cases, log issues, and retest them once the developers fix the issues found (issue resolution). In an agile environment, QA encompasses a few cycles of testing, issue resolution and retesting depending on the length and scope of the project.

User acceptance testing (UAT), also known as user experience testing (UXT), is also part of the QA phase. This is when we test whether or not the site experience matches the client’s expectation of how the site should behave. For instance, let’us say you have a fashion online store for both men and women. We test whether it’is easy for site visitors to navigate to categories of interest, and resolve any obstacles that get in their way. Or, let us say that you want the most recent Instagram photos to appear on your website. We need to ensure the most recent ones are there, and if they are not, find out why.

All testing is done in the “sandbox,” meaning it’is not a live site. We do not want customers to wander onto a site that’is not quite ready for prime time. This fact is important, as we will discuss later on.

How I Approach Functional QA

Doing functional QA means testing every functionality (in the scope) on the site to ensure it all works correctly, and as anticipated. It also means finding the stuff you never anticipated, but can have a very bad effect on the customer experience. In short, it is a lot of testing. So how do you organize your approach? You need to be super methodological.

  • Have the test plan, test suite and test cases (crafted from the requirements document) ready for the project/task/module (and reviewed by the concerned team members) before the demo phase.
  • Have the ability to modify/change the test cases according to the requirements change or scope change throughout the life cycle of the project.
  • Identify, record, document and track bugs thoroughly.
  • Provide real-time test reporting to the project manager (PM).
  • Perform a thoroughfull site QA (FSQA) if the site was previously tested in sprints (for an agile approach to a project) before handing the site over to UAT.
  • Produce QA documentation to client before UAT.
  • Participate in UAT to reduce efforts on the developer, client and also PMs.
  • Work closely with PMs, developers, designers and clients to reduce the back and forth to the best possible extent.

 

During the test execution I divide the functional QA into seven distinct categories of the site to test after I perform the smoke test and make sure that the module/site/project given to me is actually ready to be tested for regression to ensure efficient and effective testing:

1.     Homepage
2.     Header & Footer
3.     Category Page or Product Listing Page (PLP)
4.     Product Detail Page
5.     Shopping Cart
6.     Checkout
7.     Account

Let’s take a look at each.

#1: Homepage

The homepage is often a customer’s first impression of your brand, and naturally you want it to be a good one. That means it needs to look great and function properly.

Most site owners have a strong vision of what they want for their homepage. Social media feeds (Instagram photo feed just above the footer section), carousels (main mantles showing all the promotions on the site in the form of a carousel), featured products, endorsements and video feeds are just some of the bells and whistles brands deploy to make a highly relevant experience for visitors.

But they can also be points of failure if not tested and retested. When I test a homepage, I make sure that every feature and call to action (CTA) item work as anticipated.

#2: Header/Footer

The header is the place where critical functions occur, such as registering for an account, signing into an account, navigation to the site sections and searching on the site.

The footer can consist of the site map, about the site/owner(s), navigation to the site sections, blog, social media page links, customer support links (sometimes live chat) or newsletter sign up.

Most of the features or the functionalities in the header and footer can overlap or be interchanged. All of these functions tie into various backend systems, and it is critical to ensure that the integrations work flawlessly.

These sections pretty much cover the navigation to the site’s content and products by the customer and anything failing here would lead to the customer’s visit dropping off and/or losing the customer from visiting the site again and resulting in bad customer feedback.

The main things to look for here, would be:

  • Making sure that the navigation to the site’s categories, searching of the site’s contents/products, customer support links (live chat, if present), login/sign-up, social media page redirects and newsletter signup work as expected and that there are no show stoppers especially with redirects. For instance, if the visitor is not able to register/login to the site or not able to navigate on the site to the desired category on the site then that’s a critical issue.

 

#3: Category or Product Listing Page (PLP)

This part of the QA tests to see how easy and logical it is for visitors to find products they are interested in. For instance, let us say you have a unisex fashion site. Are your items categorized by gender? If I am in market for a black leather motorcycle jacket, how easy is it for me to find it?

In this scenario, I would want the site to help quickly narrow my search to men → jacket → motorcycle without a lot of clicks. In website functionality terms, the category functions should lead the user to specific product details pages of interest.

Search is a critical part of helping people find the products they want, and we have discovered a lot of issues with it. Auto-fill is important in your search function, because it makes it easy for the user to home in on the category of interest without a lot of effort.

We also test — and recommend if absent — filters, such as those that allow the user to see items priced from low to high, (or vice versa), breadcrumbs (which help in backtracking) and being able to select how many items to see on a page (pagination too).

#4: Product Detail Page

Product detail pages are the pages that provide all of the details about a product, such as its size, dimensions, weight, color options, images, videos, customer reviews and so on. It is also the page from which consumers add the item to their carts.

Generally speaking, there are two categories of products:

  • Simple products, in which there is no choice for the consumer to make, what you see is what you get.
  • Configurable products, in which the consumer must select a size, color, or some other attribute or customization.

 

It is not necessary to test each and every product detail page on your site, but you must test at least one example of every type of product (other product types include- bundled, grouped, virtual and downloadable). Test all aspects of product types. For instance, can you select the size and color you want on a t-shirt’s PDP (configurable product) and add it successfully to the cart?

#5: Shopping Cart

Do not assume that items you place in your cart are actually there. You must verify and validate them. For instance, were all the products added to the cart, actually added? Was the appropriate quantity (i.e. if you add one item to your cart, does only one item appear in it) of the product(s) added to the cart? Are the product size or other configuration attributes that you selected reflected correctly in the cart? Can you edit the product(s) in your cart? Can you remove product(s) from the cart? Can you change the quantity? Does the price update accordingly?

In some cases, the cart would also provide the estimated tax and shipping, as most would want to know the total cost of a order prior to proceeding to the checkout process. If this section is not there, I highly recommend a estimated shipping section, in which the user can enter his or her city and ZIP code (in the specified country) and get the shipping and tax costs.

#6: Checkout

The final step before the consumer makes a purchase is the checkout. The main items to look for here would be, if the customer is a guest, is he/she able to proceed and complete the checkout as a guest? Or if the guest wants to login to their existing account, are they able to? Does the order summary (if there is one) in the checkout create a better user experience?

If the consumers’ shipping addresses are the same as their billing addresses, they should have an option to click a box and have it auto fill. The first thing I look for is a box that allows me to auto-populate the billing address with the shipping address I entered. And of course, I check to see if all of the address components — name, address, city, state, ZIP code, phone number — are transferred correctly.

One of the most important functions in the checkout is the payment method(s), this is the main sales capture/transaction step on the checkout page, and it is critical to ensure that all of the payment gateways – Credit Cards, PayPal, Apple Pay, Amazon Pay, etc. — are configured and working properly. If not, you may end up shipping products to customers free of charge!

Testing the checkout literally means submitting orders, and charging your payment method the cost of the item, plus tax and shipping. It is important to ensure you are charged the correct amount, and that you receive an order confirmation email, as well as an email that your item has been shipped.

Buying these items in the testing process is also a great way to test the Returns process. Does the site offer an easy way to register a return? Do you clearly state what the customer will be reimbursed for: cost of the item, restocking charge, free returns, etc.? Once you return an item, do you receive an email stating that the item has been received? That your account has been credited?

#7: Account

Finally, we come to the account section. When consumers open an account with your site, you have the opportunity to market to them on an ongoing basis, and nurture a long-term relationship with them. Thus, the account functions are critical to get right.

Once, we were testing a new website deployed to production (live to the public), and I noticed that although everyone on my team had registered for an account on the site and were able to sign-in as expected none of the new accounts were created. The reason? The database to store the new customer information on the site had not been configured correctly in the backend. So, we should make sure to never miss the testing of the sign-up/sign-in feature on the site.

  • Account Registration: Can I sign on in a straightforward manner? Are the username and password requirements clearly stated? Am I able to enter all of the fields without any problems? Do I receive an email welcoming me to the site?
  • Account Login: Once I register, can I actually login to the site using my password? Do the “forgot username/password” links work as anticipated? Do I receive an email with clear instructions as to how to reset my password or retrieve my username? Am I able to login using my new password or username?

 

Apart from these, at the least, we should also look into addresses, order details (of previously placed orders) and Wishlist details of the user on the site to ensure the best user experience.

Have questions about QA testing or the process SD uses? Let us know.

Written by: Yathish Papanna, QA Manager