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.
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.
You can learn more about different types of test cases and how to write them in one of our previous guidelines. The link is below.
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.
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:
Expected result: A user cannot register. The error message is displayed.
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:
Expected result: A user cannot register. The button is inactive.
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.
Once again, that’s why you need to refer to the specification requirements for the platform under test.
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:
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”).
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:
Expected result: The box is checked by default. The color of the checkmark is E77808 / RGB(231,120,8).
Below, you can find a link to the article about UI testing and an example of a standard UI test. Give it a read or save it for later.
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:
Expected result: The success message is displayed.
Post-conditions: Go to “Name, Email & Password” to look if the changes have been applied.
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.
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:
Expected result: All of the results in the dropdown list start with the letters already entered.
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:
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.
ID: TC-6
Summary: Check the product’s filtering on the category page.
Pre-conditions: The user has chosen their location.
Steps to reproduce:
Expected result: The results displayed should update automatically and immediately and match the applied filters.
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.
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:
Expected result: The product is no longer displayed in the basket.
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.
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.
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:
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.
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:
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.
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:
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:
Expected result: The application is uninstalled. The app’s icon isn’t displayed on the device’s OS.
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.
However, there are some local sites with different banners. You can see several examples below.
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:
Expected result: Items are not available for purchase. The corresponding message is displayed.
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.”
When a user chooses their location and scrolls down the homepage on Nike’s website, they see the following message:
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:
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:
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:
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.
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:
Expected result: “Hello username,” “Order Status,” “Wishlist,” “My account,” and “Sign out” are displayed in the upper right corner.
In contrast, this is how the navigation looks for unlogged users.
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:
Expected result: There are no empty fields or text sections.
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.
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 😉
Quality control is obsolete. The spread of Agile, DevOps, and shift-left approach has pushed traditional…
Be honest, if your phone disappeared right now, your world would be in shambles. Data…
Teams have a love-hate relationship with Android. It’s highly customizable and has an incredibly vast…
Apple applications are easy to test. Compared to Android, that is. But when it comes…
Result-driven QA isn’t always about planning and strategizing. Sometimes, the best thing for your product…
A flimsy UI doesn’t lead to customer frustration, negative reviews, and high churn. When people…
