# Test a storefront browsing scenario

Can visitors reach the relevant product pages under the expected browsing workload? This recipe answers that question without placing orders.

## Example storefront test {#plan}

| Plan item | Illustrative choice |
| --- | --- |
| Environment | Authorised staging storefront, with a known release and cache state. |
| Scenario | Catalogue → Canvas backpack link → product detail; stop before cart. |
| Data | Stable catalogue item and visible label; no real customer data. |
| Workload | 10 sessions over 30 seconds for a baseline; 600 over 10 minutes only if justified and authorised. |
| Location | One available region, held constant between runs. |
| Evidence | Completed sessions, failures, relevant page and step timings and target telemetry. Completed sessions includes failed outcomes; support can help investigate exact session starts. |
| Stop owner | The site operator monitors impact and can stop the run. |

These example counts can be adjusted to match your expected peak traffic and permitted test scope. The [production safety](https://userlimit.com/documentation/help/production-safety.md) and [domain verification](https://userlimit.com/documentation/get-started/verify-domain.md) guides cover preparation.

## Create and validate the browse path {#build}

The example below opens a catalogue and follows a product link. It uses supported calls from the [Playwright compatibility reference](https://userlimit.com/documentation/reference/playwright-compatibility.md). The URL and product label need to be replaced with values from your site:

~~~javascript
await page.goto('https://your-verified-domain.invalid/catalogue');
await page.getByRole('link', { name: 'Canvas backpack', exact: true }).click();
~~~

Check that import produces exactly Open then Click. [Validate](https://userlimit.com/documentation/journeys/validate.md) and inspect the destination. A successful click alone does not prove that an order can be completed. Search can be a separate second scenario once the browse path works; use the site’s actual search field and supported text-entry and press actions.

## Run a baseline and the agreed workload {#baseline}

Run the small baseline first and record its average session duration. At an illustrative 30 seconds per session, 10 sessions use about 0.083 VUh, and 600 sessions about 5 VUh. These are estimates; [usage and billing](https://userlimit.com/documentation/reference/usage-and-billing.md) explains how recorded usage is calculated.

A successful baseline provides a starting point for a larger authorised run. Comparisons are more useful when the release, catalogue, location and cache conditions remain consistent. See [configuration](https://userlimit.com/documentation/runs/configure-traffic.md).

## Read, investigate and retest {#read}

The [report guide](https://userlimit.com/documentation/results/read-a-report.md) explains session outcomes, failures and timings. Slower pages or failing actions provide a starting point for investigation. A repeat after a specific fix can show whether it improved the result.

Add-to-cart testing belongs in a controlled environment with understood inventory, session state and cleanup. Payments, orders and emails need separate arrangements. This browsing test does not cover checkout or payment.

[Run this workflow in UserLimit](https://userlimit.com/tests/new)

## Related guide {#next-step}

[Prepare for a launch](https://userlimit.com/documentation/recipes/launch-readiness.md)