Home → Use cases → QA testing

Testing as many users at once

Anything with roles, tenants or invitations has to be tested by more than one user at a time — an admin inviting a member, two people editing the same record, a customer and the support agent reading their ticket. Incognito windows run out fast.

Why incognito stops working

A browser gives you one normal session and one incognito session; a second incognito window shares the first one's storage. Beyond two concurrent users you are into separate browsers, separate machines, or clearing state between every step — all slow, and all easy to get wrong in a way that makes a test lie to you.

Separate profiles give you as many genuinely independent sessions as you need, side by side on one machine, each with its own cookies, storage and service workers.

A profile per persona

Name profiles for roles rather than people — admin, member, viewer, expired-trial, suspended. Each keeps its logged-in state between runs, so you stop burning the first two minutes of every session signing in.

Persistent state is the point. A profile that has been the expired-trial user for three weeks accumulates exactly the history that makes a realistic test, and it is there tomorrow.

Geo and locale testing

Bind a proxy in the market you want to test and the profile's timezone follows its location automatically, so date formatting, business-hours logic, currency and regional content all get exercised together rather than one at a time.

That combination is what catches the real bugs: a booking form that works in London and breaks across a date boundary in Auckland is invisible when you only change the IP.

Driving it from code

Each profile exposes a Chrome DevTools Protocol endpoint, so an existing Puppeteer or Playwright suite can attach to a profile instead of launching a blank browser — keeping the persona's logged-in state rather than re-authenticating in every test.

const { webSocketDebuggerUrl } = await startProfile(ADMIN_PROFILE)
const browser = await puppeteer.connect({ browserWSEndpoint: webSocketDebuggerUrl })

Full walkthrough in Puppeteer & Playwright with isolated profiles.

Multi-user scenarios

The scenarios worth automating are the ones that need two sessions live at the same moment:

• An admin invites a user; the invitee accepts in another profile and the admin's list updates.
• Two users edit one record and the conflict handling is exercised for real.
• A permission is revoked mid-session and the other profile's next action is checked.
• A customer submits a ticket and the agent profile sees it arrive.

Sequential single-user tests cannot cover any of these honestly.

Fingerprint-dependent behaviour

If your product does device recognition, risk scoring or "new device" email alerts, you need browsers that genuinely differ to test it. Profiles with distinct, coherent fingerprints let you exercise that path without a rack of physical machines — and the fingerprint test shows you what each profile actually presents, so you can confirm the difference rather than assume it.