Nexus for beginners: Practical solutions for e-commerce testing

About this page

This guide is designed for beginners and first-time Nexus users. Our goal is to help you build reliable, low-maintenance automated tests by showing you how to handle hurdles like managing unique user data and reducing the manual effort required for repetitive steps.

By utilizing these strategies—along with validation techniques like Visual and Text Assertions—you can automate complex workflows while keeping your test suite organized and scalable.

Walking through a sample purchase flow

To help you understand how to use Nexus in a real-world context, we will walk through a standard purchase flow:

[1] User registration → [2] Login → [3] Add to cart → [4] Checkout

Each section below addresses specific challenges found within these steps and explains the best ways to solve them.

Practical solutions

[1] User registration

The problem

Ensuring new users can sign up and start using the service without issues is a critical first step in testing.

However, if you use a fixed email address, subsequent tests will fail with an error stating the email is already registered. Creating a brand-new email manually every time you run a test is inefficient and impractical.

The solution: Random email

This feature is only available for remote workspaces.

Nexus offers a feature called Random Email. It automatically generates unique email addresses, allowing you to run user registration tests as many times as needed without any manual setup.

How to set up

1. When you reach the email input step, click the email icon in the menu bar.
   

2. Select [Create random email] from the menu.
   

3. Give the email a name and click the [Save] button

   

4. Copy the generated email and paste it into the [Email] input field.

   

[2] Shared group steps

The problem

It is inefficient to record the same process, like a login, over and over for different scenarios.

For example, on an e-commerce site, possible test flows include:

• Log in → Purchase

• Log in → Return an item

• Log in → Edit User’s account

If these tests were created individually, any changes to the UI or specifications would require us to manually update every single test—including those covering the login process—one by one, which would make maintenance very time-consuming.

The solution: Shared group steps

We can prevent this issue by turning repetitive steps, like logging in, into shared group steps. These groups can be reused across different scenarios. If the steps need to change, you only have to update them in one place, and the changes will automatically be reflect across all instances.

How to set up

1. In the scenario editor, select the steps you want to turn into a shared group.
   

2. Click the three-dot menu on the selected steps and select [Create shared group].
   

3. Name the group and click [Done].

   

4. Finally, click the [Save] button.
   

   
   You can manage the shared group steps under workspace resources.

   

[3] Visual assertions

The Problem

With repeated updates, UIs can break — buttons may become hidden due to layout shifts, and other visual regressions can slip through unnoticed. On top of that, manually verifying every element on a content-heavy page is both time-consuming and error-prone.

Take the simple cart page shown below as an example. There's actually quite a lot to check:

1. Are the product name and color displaying correctly?

2. Is the quantity showing the intended value?

3. Is the item price correct?

4. Is the cart total being calculated accurately?

5. Does the cart badge count match the number of items inside the cart?

The Solution: Visual assertions

Manual inspection is inefficient. For pages that matter, use Nexus's Visual assertions instead.

As shown in the image below, Visual assertions compare the screen at test execution against the one captured during recording, and fires an alert whenever an unexpected visual change is detected. The human eye struggles to catch subtle discrepancies across individual elements, but AI can instantly flag even the smallest deviation.

When dealing with values that naturally fluctuate — such as prices — you can adjust the Max pixel difference (%) threshold to allow for an acceptable margin of visual variation.

How to set up

1. Click the icon highlighted in red

   

2. Click [Assert page visual change]

   

3. Enter a value for the [Max pixel difference (%)] and click [Add].

   

[4] Text assertions

The problem

A successful page transition alone doesn't guarantee that the system has actually completed its processing correctly.

With something as complex as a payment flow, there's always the risk that the page appears to load just fine while an error has silently occurred behind the scenes.

To be confident that the system handled a request properly, you need to verify a specific message on screen — something that directly confirms things worked as intended.

The solution: Text assertions

Set up a text assertion targeting a specific message that appears after checkout — something like "Thank you for your purchase."

Validating the exact wording on screen gives you direct confirmation that the payment process completed successfully. It also prevents false positives — situations where a test passes simply because the page loaded, even though it's actually showing an error message — making your test suite far more reliable.

How to set up

1. Click the icon highlighted in red in the menu bar.

   

2. Click on the text you want to verify. The selected area will be highlighted in purple, as shown in the image.
   Then click [Assert text].

   

3. From the dropdown menu, select [Equals] and click [Add].