Skip to content

Test accounts

Burhan uses your app the way a user does: it opens your staging site or installs your Android build, signs in, and walks each journey step by step. For that it needs an account it can sign in with, on an environment where a test order or a deleted record does no harm.

Why a real account

Burhan doesn't read your code or call your API. It drives a real browser (or a real Android phone) and judges what appears on the screen against your spec. Without an account it only sees the sign-in screen.

The account lives on staging, never production. Journeys that change data (place an order, delete a branch) only run on environments you mark as allowed to.

Which accounts to give it

Setup asks for one account and lets you add more. Each has a title, a login, a password (stored encrypted) and a short description of what's in it: "~50 customers, orders from last month, payments connected". Burhan reads that description when it writes journeys, so it doesn't plan a step that needs data the account hasn't got.

  • Main account: journeys sign in with it. Give it data: customers, orders, a history.
  • Empty account: a fresh sign-up with nothing in it, for first-run and empty states.
  • Other roles: a cashier, a branch manager, a viewer. A journey can run on one account or on all of them.
  • No sign-in: tick it if your app has no login, and Burhan starts from the home page.

Twins (Android)

On a phone, one account is signed in on one phone at a time: many apps keep a single session per account. If you have a second account of the same kind, write "twin of main" in its description. Read-only journeys may then run on it in parallel; a journey blocked on the twin for lack of data runs again on the account it stood in for.

2FA, OTP and other sign-ins

Authenticator codes (TOTP): paste the Base32 secret or the otpauth:// link behind your 2FA setup's QR code. Burhan computes the six-digit code itself at sign-in; the secret is stored encrypted and never leaves the server.

Codes by email or SMS: your project gets a test inbox address (and a number, when set up). Point the test account's email or phone at it and Burhan waits for the code, then types it.

A token, header or cookie instead of a browser login works too, added to requests to your app's own site only.

Google sign-in and sessions that expire: Burhan can't pass Google's robot check. Log in once in Burhan's browser from Settings → Authentication; Burhan keeps the session and tells you (the bell, email, Slack) when it expires and a run is waiting.

Find the bugs before your customers do.

Start free

No scripts. No card. $20 free at sign-up.