Test accounts

A test account is a username and password on your product that a person signs in with. Add one when the product needs an account to be useful: a person with an account signs in through your product’s own sign-in form instead of stopping at it. The model playing a person never sees the password — Trawler types it.

Adding one

On the plan page, choose Your product needs sign-in? Add a test account. Under Test accounts, enter:

• Username or email — what the account signs in with, up to 320 characters.
• Password — 8 to 1,000 characters.

Choose Add account. Accounts are saved as soon as you add or remove them; they do not wait for Save plan. A project holds up to 20.

Afterwards the list shows each username with a hint of its password — password …wxyz for a password of 16 characters or more, and just password … for a shorter one. The password itself is never shown again.

Message	Why
The password must be 8 to 1000 characters.	Too short or too long.
Enter the username or email the account signs in with (up to 320 characters).	The username is empty or too long.
A project can hold at most 20 test accounts.	Remove one first.

Giving it to a person

Each person’s card gains Signs in as, with No account and one entry per account. Pick the account and choose Save plan. Several people can share an account; they then share whatever that account holds, so their sessions can see each other’s changes.

Removing an account with × also takes it away from every person who used it.

How a person signs in

When a person with an account reaches the product’s sign-in form, they point Trawler at the username and password fields, and Trawler types both in, one after the other. Both fields need to be on the page together: a sign-in that asks for the username and the password on separate screens may stop the person.

The password goes only into a real password field, and only on one of the origins the run may open. The person cannot type into a password field themselves, cannot press keys other than Enter, Tab, Shift+Tab and Escape while one has focus, and cannot read what a password field holds.

Wherever a password could surface — the page the model reads, the notes and findings a person records, the report — it is replaced with •••.

When a defect is replayed, the fresh agent signs in with the account of the person who reported it.

Caution

A person without an account is told to sign up the way a new user would, if the product allows it — but they cannot fill in a password field. A sign-up form that asks for a password stops them. If signing up is not what you are testing, give them an account.

How accounts are stored

Passwords are encrypted before they are stored, each bound to its workspace, project and account, so a copy moved anywhere else cannot be decrypted. They never travel to your browser.

A password is decrypted inside Trawler when a run starts, and again each time one of the run’s sessions, replays or judge calls is handed to a runner. That runner receives the passwords of the run’s accounts; a person can sign in only with their own.

Protected staging

Staging behind HTTP basic auth or a secret header cannot be set up in the app yet — the people would stop at the protection. The local runner accepts both.