# Managing test accounts for QA without a spreadsheet hunt > Managing test accounts for QA goes wrong when the state lives in people's heads. Give each persona a profile with its login, role and state beside it. Source: https://mosaicbrowser.com/blog/qa-test-accounts-naming ## Keeping twenty QA test accounts straight Managing test accounts for QA goes wrong when the state lives in people's heads. Give each persona a profile with its login, role and state beside it. ![20: Twenty test accounts, each with its state beside it](https://mosaicbrowser.com/covers/qa-test-accounts-naming.webp) Managing test accounts for QA goes wrong in one predictable way: the facts about each account live in people's heads. Which persona is an admin, whose password was reset on Tuesday, which one is stuck on step three of onboarding, which one has two-factor turned on and on whose phone. With five accounts somebody remembers. With twenty, the first hour of a test run goes on finding out. The fix we use is to give every persona its own browser profile and to write what is true about it beside it, where the next tester will look first. ## Why test personas drift A test account changes every time it is used. A tester signs in as `trial-expired`, upgrades it to check the payment page, and now it is a paid account with the old name. Someone resets a password to test the reset email and forgets to put it back. A persona built to sit halfway through onboarding gets pushed to the end by an automated suite. None of that is anybody's fault. It is what test accounts are for. The usual record is a spreadsheet with an email, a password and a role, and a spreadsheet is a snapshot. It says what was true when somebody last edited it. The browser says something else: it still has last week's session cookie for one persona, a feature flag cached in local storage for another, and a half-filled form that the app restores on load. Sharing one browser across personas makes it worse. Sign out of one and into another and the app's own cookies and storage carry over, so the second persona can be shown a banner, a cached setting or an A/B bucket that belongs to the first. A bug found that way is a bug in the test. Mosaic is a desktop app Email yourself the link and open it on your computer. [How it works: REST API](https://mosaicbrowser.com/features/rest-api) ## One profile per persona In Mosaic each profile is its own browser, with its own cookie jar, storage and history, so a persona's state stays with that persona. Opening `trial-expired` opens a browser that has only ever been `trial-expired`. We split the library the way the [projects and tags write-up](https://mosaicbrowser.com/blog/projects-owners-tags-state) describes: what does not change goes in a project, and what does goes in a tag. - a project per product or environment under test, such as "Billing staging" or "Mobile web prod checks" - a profile name that says who the persona is and what role it has: `staging · admin · ana`, `staging · viewer · ben`, `staging · trial-expired` - tags for the state that moves: `onboarding-3`, `locked`, `2fa-on`, `needs-reset`, the ticket it is tied up in When a run changes a persona, the tester changes the tag in the same minute, and a bulk edit changes it on every selected row at once. Filter by `needs-reset` before a release and the list of accounts to fix is on screen, not in a thread. ## Write the login and the state where the browser is Two things in a profile do the work a spreadsheet was trying to do. The profile's credentials hold each login for that persona: a label, the site, the username, the password and, where the account has it, the two-factor setup key. A setup key that cannot make a code is refused when it is saved, not on the morning somebody needs it. The companion, the small extension inside each profile's browser, shows that profile's logins and its current code, and fills them into the page with real keystrokes. Nobody asks in chat for a code from a phone that is in someone else's bag. The profile's notes say what is true about the persona right now, in Markdown, edited in the same place they are read, in the profile editor or in the companion. Ours look like this: ``` **Role:** org admin, 3 seats used of 5 **Plan:** trial, 9 days left (do not upgrade) **Seed data:** 2 projects, 40 invoices, one overdue **Last reset:** by Ana, after the refund test ``` The line that saves the most time is the last one. "Who touched this last, and what for" is the question every test run used to open with. ## Snapshots, resets and what the browser cannot do A profile's cookies can be exported as a file and imported again later, to the same profile or a fresh one, including into a browser that is already open. That gives you a way to keep a persona's signed-in browser state from before a destructive test and put it back afterwards. It restores the browser, not the account. If the test cancelled a subscription, the server still has a cancelled subscription, and the restored cookie now belongs to a different account from the one in the notes. Reset the account in your app first, with whatever script or admin action you use, then restore or clear the browser side, then write the reset in the notes. A few habits outside the browser help as much as anything inside it: 1. Give each persona an address you control, such as `qa+trial-expired@yourcompany.example` on a provider that supports plus addressing, so reset emails reach the team and not a stranger. 2. Keep production test accounts few and labelled as test in your own admin, and follow your company's rules for them; most of this belongs in staging. 3. When you need a fresh persona, make a new profile from a preset rather than reusing one whose history nobody knows. Starting from a jar nobody has used is the same idea as [testing your checkout as a first-time customer](https://mosaicbrowser.com/blog/test-checkout-as-customer). ## Personas that need a place and a language Some test accounts exist to be somewhere: a German customer, a user in a timezone where tomorrow's deadline is already today. A profile carries its own timezone and language, and with a proxy attached they follow that proxy's measured exit, so the persona arrives as the user it describes. The details that trip a test in another region are in [testing in another timezone](https://mosaicbrowser.com/blog/testing-in-another-timezone) and [testing a site in another language](https://mosaicbrowser.com/blog/accept-language-testing). ## Questions ### How should QA teams store test account passwords? Somewhere that belongs to the account rather than to a person: a shared vault entry per persona, or in Mosaic the profile's own credentials, which hold the login, the password and the two-factor setup key together. A password in a chat message is out of date the first time anyone resets it. ### How do you handle two-factor codes on shared test accounts? Store the setup key with the account, not on one tester's phone. A profile's credentials in Mosaic keep the TOTP secret and show the current code in the companion inside that profile's browser, so nobody has to ask a colleague who is on holiday. ### Should test accounts share one browser? Not if you want each run to start from a known state. Two personas in one browser share cookies and local storage, so the app under test can see both, and a leftover session from one can change what the other is shown. ### How do you reset a test persona? The account's server-side state has to be reset in your app, usually by a script or an admin action. The browser side is separate: clear the profile's cookies and cache, or import a cookie snapshot you exported earlier, and note in the profile what was reset and when. ## Related [Projects say who owns it, tags say what state it's in](https://mosaicbrowser.com/blog/projects-owners-tags-state): How to organize client accounts with tags: the client goes in a project, the state in a tag. Owners rarely change; states change weekly. [Testing your own checkout as a customer who has never visited](https://mosaicbrowser.com/blog/test-checkout-as-customer): To test a Shopify checkout as a customer, pay with a test method from a browser that has never seen your store: no admin login, no saved address, no cart. [Testing date and deadline features in another timezone](https://mosaicbrowser.com/blog/testing-in-another-timezone): Midnight cut-offs and "ends today" banners break in zones you don't live in. Test a website in a different timezone without touching your computer's clock. [Testing a site in another language means more than one header](https://mosaicbrowser.com/blog/accept-language-testing): Set Accept-Language alone and the page still formats dates for your own machine. A real language test moves the header, navigator.languages and Intl. [How to manage multiple accounts without getting them linked](https://mosaicbrowser.com/guides/how-to-manage-multiple-accounts-without-getting-linked): Accounts get linked by shared cookies, IPs, fingerprints and habits. Give each its own profile, exit and history, then test it before you trust it. [Seeing both sides of your own A/B test](https://mosaicbrowser.com/blog/seeing-both-ab-variants): Testing tools put each visitor in one variant by a cookie or id and keep them there. To see every variant, keep one browser profile per variant for the test. [How to test a metered paywall as a new visitor](https://mosaicbrowser.com/blog/metered-paywall-new-visitor): A meter can count by cookie, by login, by address or by fingerprint. To test yours as a new visitor you need a browser that is new to every one of them. [A fresh browser for every test run, and why it should be cheap](https://mosaicbrowser.com/blog/fresh-profile-per-test-run): Leftover cookies and storage are where flaky browser tests come from. A one-time profile gives each run a clean jar and trashes itself when its browser closes. ## Mosaic, on your own computer The browser this blog is about: its own Chromium, fingerprints from real machines and a proxy exit per profile. Free holds 3 profiles. Pro is $49 a month for any number. Mosaic is a desktop app Email yourself the link and open it on your computer.