Record the login once as an Authenticated Profile, and every Test Case that uses it starts already signed in. A Profile is a saved browser session: the cookies and storage your application writes after a successful sign-in. Thunders stores it encrypted and replays it at the start of a Test Run, so your Test Cases skip the login screen entirely.
This is the answer to slow, brittle login steps. Signing in at the top of every Test Case is the single most repeated part of most suites, and it is also the part most likely to break on a multi-factor prompt or a redirect.
What a Profile stores, and what it does not
An Authenticated Profile holds the session your application left in the browser: cookies, localStorage and IndexedDB entries for the sites you visited while recording.
It does not hold your password. Recording captures the result of signing in, never the credentials or the keystrokes you typed, and the interface says so while the browser is live: "We capture the session, never your password or keystrokes."
Stored values are encrypted at rest and masked in the interface. Thunders never shows decrypted cookies, tokens or storage back to you.
Record a Profile
Open your Test Project, select Configure, then Authenticated Profiles.
Select Record profile.
Choose the Environment and the App to sign in to. The Test Project needs at least one App with a URL configured for that Environment.
Select Go live. A real browser opens in front of you.
Sign in as the user you want to save, exactly as a person would, including any multi-factor step.
Select Capture & save profile.
Give the Profile a Profile name, and a description if it helps your team.
The live session is time limited, and the interface counts down with "Session ends in n min". If it ends before you capture, start again.
This is one of two ways to create a Profile. The other is to let a Test Case capture one as it runs, which is the stronger pattern for a whole suite. See Let a Test Case create the Profile below.
When you close the window while still signed in, Thunders asks whether to Capture & save profile, Discard session, or Keep signing in, so you do not lose the session by accident.
What the outcome tells you
Outcome | What it means |
Profile captured | The authenticated state was encrypted and stored. Test Runs using this Profile start already signed in |
No session data found | No persistent cookies or storage appeared after sign-in. The app may keep authentication in memory only, which a Profile cannot restore |
Couldn't store the profile | Nothing was saved, and the live browser is still open, so you can retry without signing in again |
If capture reports that IndexedDB was not included, the Profile is usually still fine. Most applications keep authentication in cookies.
Let a Test Case create the Profile
Recording by hand is the quickest way to get started. For a suite that runs regularly, it is usually better to let a Test Case sign in and save the Profile, so nothing depends on somebody remembering to record one before the session expires.
The recommended shape is a Test Set with a pre-requisite:
Write one Test Case that signs in and ends with a Capture Profile step.
Add it to a Test Set, and set it as the Test Set's pre-requisite. It then runs first, and the rest of the set only runs if it passed.
Write every other Test Case in the set to begin with an Inject Profile step pointing at that same Profile name.
The pre-requisite signs in once, and every Test Case behind it starts already signed in. A sign-in that breaks fails one Test Case in an obvious place, rather than failing each of them separately for what looks like a different reason each time.
Read the Authenticated Profiles list
Column | What it shows |
Profile | The Profile name, and a summary such as "12 cookies, 2 origins" |
Environment | The Environment the Profile was recorded against |
Fingerprint | The browser identity the session was recorded with |
Last refreshed | When the session was last captured |
Type | How the Profile was created |
The status beside a Profile is Active, Expiring soon, Expired, or Unknown, with the date underneath. An expired Profile no longer signs anyone in, so record it again.
Select View saved content to inspect what a Profile holds: the cookie names, domains and flags, and the localStorage and IndexedDB entries, with every value masked.
Renaming and deleting
Both are riskier than they look, because test steps resolve a Profile by its name.
Renaming breaks every Test Case that injects the Profile under the old name, and the dialog warns you with the exact count before you save. Deleting removes the Profile and its stored session, and the confirmation names how many Test Cases will fail as a result.
If you rename, update the steps that point at the old name in the same sitting.
Frequently asked questions
What exactly does Thunders store when I record a Profile?
The session your application created after you signed in: its cookies, localStorage and IndexedDB entries. Credentials and keystrokes are never captured, and what is stored is encrypted at rest and masked in the interface. For credentials a Test Case needs to type, use a Secret.
Should I record a Profile by hand or let a Test Case capture it?
Record by hand to get going, and for a one-off. For a suite you run regularly, let a Test Case capture it and make that Test Case the Test Set's pre-requisite, so the sign-in happens fresh on every run and nobody has to remember to refresh anything.
Which applications work best with Authenticated Profiles?
Any application that keeps its session in cookies or browser storage, which is the large majority. Capture tells you immediately: "Profile captured" means you are set, and "No session data found" means that application holds authentication in memory only, so keep signing in inside the Test Case.
How long does an Authenticated Profile last?
As long as the session your application issued. The list shows Active, Expiring soon or Expired with the date. When it expires, record the Profile again.
Can I use one Profile in several Test Cases?
Yes, and that is the point. Any number of Test Cases can inject the same Profile.
Do Authenticated Profiles cost credits?
Yes, an Authenticated Profile is a billable entity.
How do I cover several Environments?
Record one Profile per Environment. Each Profile shows the Environment it was captured against in the list, and a Test Case can resolve the right one at run time by putting a Variable in the Profile name.