15 E-Commerce Test Cases to Include in Your Test Suite

Good testing documentation is as important as a QA engineer's meticulousness and reasoning ability. That’s why we pay so much attention to teaching our Junior QAs how to prepare test cases, checklists, bug reports, and other artifacts.

Our team has been working with the e-commerce niche since the early days of QA Madness. In this article, you will find some sample test cases for e-commerce websites and apps you can use during work – as ready artifacts or as a background/examples for your own test cases.

Test Cases in a Nutshell

A test case is a set of actions executed to verify a particular feature or functionality of your software application.

A test case is a set of actions executed to verify a particular feature or functionality of your software application.

QA engineers can use valid or invalid inputs during testing. Based on that, we distinguish positive and negative test cases.

The format and structure of a test case can vary from project to project and even specific features of a product. For example, there are mandatory elements, such as summary and steps to reproduce, and optional elements, such as preconditions and postconditions.

15 E-Commerce Test Cases Examples for Web and Mobile Testing

We decided to share some manual test cases for an e-commerce website and app a beginner QA can find useful. We included test cases for both online stores and marketplaces.

All of the screenshots in this article are used as examples only. Our QA team hasn’t tested the mentioned services. The majority are familiar to a wide audience, and that’s what makes them great illustrative material.

And once again: these are sample artifacts. Their purpose is to explain the structure of test cases and show how they work in practice.

1. User Registration

Let’s start our list with negative test cases for an e-commerce website (or e-commerce app, it will work for both). As you may remember, a negative test case uses invalid inputs to check if the software doesn’t do something it is not supposed to. During registration, such invalid inputs can include incorrect user information in all or at least one of the required fields.

ID: TC-1.1

Summary: Check the registration with empty required fields.

Steps to reproduce:

1. Open the Homepage: https://www.bookdepository.com/.
2. Click the “Sign in/Join.”
3. Click the “Create your account.”

Expected result: A user cannot register. The error message is displayed.

Screenshot: Book Depository

When filling in the “expected result,” make sure to look up the requirements. In this case, the button is active even with empty fields. Some platforms, however, choose a foolproof strategy: the button is inactive if some information is missing. Thus, the test case will look different, too:

ID: TC-1.2

Summary: Check the registration with empty required fields.

Steps to reproduce:

1. Open the Homepage: https://www.ebay.com/.
2. Click the “register.”
3. Click the “Create account.”

Expected result: A user cannot register. The button is inactive.

Screenshot: eBay

A few more words about this foolproof UX. If a user places a cursor in a field and then clicks somewhere else without entering any data, the fields will be highlighted red, and texts with explanations will pop up.

Screenshot: eBay

Once again, that’s why you need to refer to the specification requirements for the platform under test.

2. Signing In

Another important test case focuses on registration. As you may already know, test cases for e-commerce websites are often universal and reusable. Here’s an example that is universal and can be suitable not only for e-commerce but also for platforms from other niches.

ID: TC-2

Summary: Check signing in with valid data.

Pre-conditions: The user is already registered.

Priority: High.

Steps to reproduce:

1. Open the website: leave the link to the website.
2. Proceed to the login page.
3. Fill the required fields with valid data.
4. Submit the form.

Expected result: The user is logged in. My account page is displayed.

As you can see, this test case features more fields. There are two reasons for this: teams use different formats (“Priority”), and some cases require more information to execute (“Pre-conditions”).

3. UI Test Case

UI test cases go hand in hand with functional cases. To the great extent, these two groups overlap and cover the same elements. Back to registration and login: we test functionalities, but we do it through the means of the user interface. So, there is usually no need to divide test cases into categories strictly.

ID: TC-3

Summary: “Keep me signed in” checkbox is checked.

Steps to reproduce:

1. Open the Homepage: https://www.bookdepository.com/.
2. Click the “Sign in/Join.”
3. Verify that the “Keep me signed in” checkbox is checked.

Expected result: The box is checked by default. The color of the checkmark is E77808 / RGB(231,120,8).

Screenshot: Book Depository

4. Editing Account Data

It doesn’t matter if a person has made a mistake during registration or changed their name or address. It is essential to provide users an opportunity to update their personal data and make sure it actually works. Here’s a sample e-commerce test case for that.

ID: TC-4

Summary: Edit user name in “My Account.”

Priority: High.

Steps to reproduce:

1. Open My Account: https://www.bookdepository.com/account.
2. Go to “Personal Details” > “Name, Email & Password.”
3. Click the “Edit” in the “Name” field.
4. Click the “Save changes.”

Expected result: The success message is displayed.

Post-conditions: Go to “Name, Email & Password” to look if the changes have been applied.

Screenshots: Book Depository

As always, it is necessary to run a negative test case for this functionality and check saving the information with the empty field. You already know how to write this one on your own.

5. Search Results

Search is one of those features that make navigation on an e-commerce platform faster and easier, especially if we are speaking about a marketplace or a large merchant.

ID: TC-5

Summary: Check the search suggestions.

Priority: Medium.

Steps to reproduce:

1. Open the website: https://www.etsy.com/.
2. Start typing the keyword in the search row.
3. Check the list of the results in the dropdown list.

Expected result: All of the results in the dropdown list start with the letters already entered.

Screenshots: Book Depository

Some platforms offer to search for an item in a specific category. On some, the matches are not direct – the queries only contain some of the letters, like on the screenshot below:

Screenshot: Book Depository

If you are working with some other variations of the search suggestions, the test case (and the expected result, in particular) will go a bit differently.

6. Product Filtering

The bigger the selection is, the more important the filters are. Just like with the search algorithm, it is essential to display the relevant results that meet the set parameters. Here’s a sample test case to check it.

ID: TC-6

Summary: Check the product’s filtering on the category page.

Pre-conditions: The user has chosen their location.

Steps to reproduce:

1. Go to a category page: https://www.ikea.com/us/en/cat/standing-desks-55008/.
2. Apply the filters: price range, features, color, and availability. Keep in mind that it might be better to check each filter individually first and then check the combination of several.
3. Check the results displayed.

Expected result: The results displayed should update automatically and immediately and match the applied filters.

Screenshot: IKEA

We applied sorting by customer rating, which can be tested individually, too. Also, some platforms display results after a user clicks on a button that confirms the choice – “Apply,” “Refine results,” etc. Remember to adjust your test case accordingly.

7. Shopping Cart

A user has found everything they were looking for and added the items to a cart. At some point, a user changes their mind and decides to remove one or several items. It can be to prevent an impulsive purchase or because of finding a better alternative. Just like the reason, the actual name for a cart can differ, but the test case covering this functionality will look quite similar.

ID: TC-7

Summary: Remove a product from the cart.

Priority: High.

Steps to reproduce:

1. Go to the website: https://www.sephora.com/.
2. Add products to “Basket”.
3. Click the basket icon.
4. Click the “Remove.”

Expected result: The product is no longer displayed in the basket.

Screenshots: Sephora

If a user can view and manage a basket by hovering over the icon, like on this website, the basket scenarios for this option should be described in the dedicated test cases.

Screenshot: Sephora

QA specialists may add the information about total price changes in the “Expected Results.” Some prefer to include this in a separate set of test cases. It depends on the approach a particular team uses or the required level of detalization.

8. Checkout Process

How about some negative test cases of an e-commerce website or (mobile app) to our collection of sample artifacts? Similarly to user registration, the checkout process requires filling in some obligatory fields.

On the one hand, if a user forgets to leave their delivery address, a customer support representative can give a call and specify it. But online shopping was invented to minimize the number of interactions, right? On the other hand, what if a user forgets to leave their phone number, too?

ID: TC-8

Summary: Check if a user can proceed to the payment without selecting a shipment address.

Steps to reproduce:

1. Open the website: leave the link to the website.
2. Add any product to the cart.
3. Proceed to the checkout.
4. Choose a shipment method.
5. Indicate a billing address.
6. Proceed to the payment step.

Expected result: A user doesn’t have a possibility to proceed to choose the payment method without indicating their shipping address.

Depending on the requirements specification, a button taking a user to the next step can be inactive or a user will see a corresponding error message.

9. Payment Gateway

Our content team doesn’t have a test entity to illustrate this one (and doesn’t need to buy anything online at the moment). So, this test case will be more abstract, meaning there are no names of the website sections or buttons. You can specify those when preparing real test cases to use on a client’s e-commerce website.

ID: TC-9

Summary: Place an order via Visa payment method.

Priority: High.

Steps to reproduce:

1. Open the website: leave the link to the website.
2. Add an item to the basket.
3. Proceed to the checkout page.
4. Fill in the required information: leave the credentials used for testing.
5. Choose Visa as the payment method.
6. Enter card data.
7. Finish the purchase.

Expected result: The transaction is successful. A user gets a confirmation message.

You will need to test all of the available testing methods in this set. Thus, the test case will be reusable – just change the name of the payment system. And once again, be more specific with the names of the site sections and buttons if needed. The main rule is to provide enough data to make a test case easy to understand and execute while avoiding redundancies and too-obvious directions.

10. Installation / Uninstallation

You can use all of the previous artifacts in both e-commerce website testing and mobile application testing. Maybe, it’ll be necessary to change a few details, but nevertheless. Meanwhile, there are some mobile-specific test cases for e-commerce apps.

First, you’ll need to check if an app installs on a mobile device.

ID: TC-10.1

Summary: Install the application on iPhone 11.

Priority: High.

Steps to reproduce:

1. Download the build.
2. Install the application.
3. Launch the application.

Expected result: The application is installed and works correctly.

After all the tests, you should check if it is possible to delete the application.

ID: TC-10.2

Summary: Check the app uninstalling.

Priority: High.

Steps to reproduce:

1. Open device settings.
2. Open application settings.
3. Uninstall the application.

Expected result: The application is uninstalled. The app’s icon isn’t displayed on the device’s OS.

11. Localization Test Case

When a user types “nike.com” in a browser, they go to a website and see a popup with a list of locations. After choosing the relevant one, a user proceeds to the website in their country. Right, that’s localization. Interestingly, some regions appear twice: countries can have several locales with different languages.

Screenshot: Nike

Software localization goes beyond translations. It can include an adaptation of assortment, imagery, and even colors that would work better in a particular region. For example, the majority of locales have a banner with a Phil Knight’s quote.

Screenshot: Nike

However, there are some local sites with different banners. You can see several examples below.

Screenshot: Nike – Japanese locale

Screenshot: Nike – Canada, Australia, New Zealand

Screenshot: Nike – Southeast Asia

Screenshot: Nike – Mexico

Screenshot: Nike – China

Long story short, it all depends on the requirements. So we’ll share a simple test case for Nike's store.

ID: TC-11

Summary: Check the russian locale.

*Steps to reproduce: *

1. Open the russian locale: https://www.nike.com/ru/
2. Check the main banner.

Expected result: Items are not available for purchase. The corresponding message is displayed.

Screenshot: Nike – Russia

As you can see, the actual result corresponds to the expected one. “Currently, Nike cannot guarantee the delivery of items for russian customers. Due to this, purchases on the website nike.com and Nike app are temporarily unavailable in this region.”

12. Popup Elements

When a user chooses their location and scrolls down the homepage on Nike’s website, they see the following message:

Screenshot: Nike

It is essential to make sure that a user can close this popup window. Otherwise, shopping will be impossible.

ID: TC-12

Summary: Closing the popup on the homepage.

Priority: High.

Steps to reproduce:

1. Open the homepage https://www.nike.com/.
2. Choose a location and scroll down until a popup form appears.
3. Close the popup.

Expected result: The popup is no longer displayed. A user can continue interacting with the website.

You should also check the functionality of the popup:

• if a user can sign up;
• if all the fields are working correctly;
• if the links are clickable;
• if there is a confirmation message on the email, etc.

13. Real-Device Testing

It’s not a secret that the share of mobile traffic keeps increasing. E-commerce is not an exception. Thus, it is likely that QA engineers will eventually receive more e-commerce apps for testing.

We always emphasize the importance of real-device testing since it is the only way to check software in an environment that closely imitates real-life conditions. Here’s one more mobile-specific test case for this.

ID: TC-13

Summary: Application’s functioning during accepting the incoming call.

Pre-conditions: The application is installed.

Steps to reproduce:

1. Launch the application.
2. Start using the app.
3. Accept the call on the screen of the incoming call.

Expected result: After the end of the call app maximizes and works correctly.

Similarly to installation/uninstallation, you can reuse this test case in test suites for different products and industries. An app’s functioning during declining the call should be tested separately.

14. Navigation

Some platforms allow making quick purchases without user registration. Some require registration. Regardless of the case, registered and unregistered users have access to the different parts of the functionality, and it is reflected by the site navigation.

ID: TC-14

Summary: Check top navigation for a logged-in user.

Pre-conditions: The user is already logged in.

Priority: High.

Steps to reproduce:

1. Go to the website: https://www.bookdepository.com/.
2. Check navigation at the top of the page.

Expected result: “Hello username,” “Order Status,” “Wishlist,” “My account,” and “Sign out” are displayed in the upper right corner.

Screenshot: Book Depository

In contrast, this is how the navigation looks for unlogged users.

Screenshot: Book Depository

15. Website UX and Content

You must already know that UX testing isn’t a task solely for a QA team. It focuses on emotions as much as a convenience and relies on marketing research. Nevertheless, there are some UX bugs specialists log during UI testing or documentation review.

The situation is similar with content bugs. Often, a Content Manager or Product Owner is responsible for the product descriptions, their correctness and relevance. Still, there are some aspects a QA team can check as a part of their work scope.

ID: TC-15

Summary: Check a product description.

Steps to reproduce:

1. Open the website: https://www.ikea.com/us/en/.
2. Open any product.
3. Check if all sections of the product description contain the texts.

Expected result: There are no empty fields or text sections.

Screenshot: IKEA

If you are on IKEA’s website, you’ll need to click on “Materials & care,” “Safety & compliance,” and so on to check if all of the mentioned webpage sections feature the descriptions.

To Sum Up

These are just a few of the e-commerce website testing test cases a QA team normally includes in a test suite. Even the smallest and simplest online shopping platforms feature a bunch of standard functionalities – registration, category and product pages, checkout, payment, wishlists, coupons, etc. – that will take time to check properly. And to do it efficiently, you always need to prepare test documentation first 😉