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 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 and domain verification guides cover preparation.
Create and validate the browse path
The example below opens a catalogue and follows a product link. It uses supported calls from the Playwright compatibility reference. The URL and product label need to be replaced with values from your site:
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 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
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 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.
Read, investigate and retest
The report guide 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.