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. Profiles work for web applications only. They do not apply to Mobile Apps yet.

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.

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.

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.

To replace the session of a Profile, record it again under the same name. Test Cases that use it keep working.

You can also create a Profile in two other ways. A Test Case can capture one as it runs, which is the stronger pattern for a whole suite. See Let a Test Case create the Profile below. And when Thunders AI cannot sign in while it browses your application, the chat asks you to Record profile. The same dialog opens, and Thunders AI continues signed in after you save.

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.

If capture reports that IndexedDB was not included, the Profile is usually still fine. Most applications keep authentication in cookies.

A Profile applies to all Environments of the Test Project, or to one Environment only. When a Test Run reads a Profile name, it takes the Profile of the run's Environment if one exists, and the project Profile with the same name otherwise. This is the same rule as for Variables, so one Test Case signs in as a different user on Staging and on Production with no change to its steps.

To give one Environment its own account:

The Source column shows where each row comes from: Environment, Project or Overrides project. Inherited rows are read-only here. To return to the project Profile, select Remove override on the overriding row. This deletes the Profile of the Environment and its stored session.

The Credentials and Variables tab of the Environment shows Variables in the same way.

Thunders does not predict when a session expires, because your application decides that on its server. Instead, each Test Run that injects a Profile checks that the browser lands where the capture ended. A Profile shows Session rejected when the application sent the browser somewhere else, for example to its sign-in page, and Session unverified when Thunders could not check the result. The badge goes away after the next Test Run that lands signed in. To replace a session that no longer works, record the Profile again under the same name.

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.

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:

To run the set on several Environments, turn on Save per environment in the Capture Profile step. Each run then saves the session into the Profile of its own Environment, and creates that Profile when it is missing.

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.

See Test Set Pre-requisites and How do I use a saved login in a test case?

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.

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. See Add / Edit / Delete / Use Secrets.

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.

As long as your application accepts the session it issued. Thunders does not guess an expiry date. The list shows Last captured, and a Profile shows Session rejected once a Test Run finds that the session no longer signs the user in. Inject steps that Renew the saved session save the session the application returns on each run, which keeps the Profile working for longer with applications that extend a session on each visit.

Yes, and that is the point. Any number of Test Cases can inject the same Profile. When parallel runs must not share one account, group several Profiles in a pool. See How do I give each parallel run its own account? and How do I use a saved login in a test case?

Yes, an Authenticated Profile is a billable entity. See Credit Consumption.

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.

Record a project Profile, then override it on each Environment that needs another account, with Override for this environment. A Test Run takes the Profile of its own Environment first and the project Profile otherwise, so the inject step keeps one name. See How do I use a saved login in a test case?

End the capture while the user is still signed in. A sign-out after the capture, in the browser or in the Test Case, can end the session on the server, and every later Test Run then lands on the sign-in page with Session rejected. Record the Profile again without the sign-out.

It is now a tab of the project Settings, next to Credentials and Variables. Each Environment also has its own Authenticated Profiles tab. The old address opens the new tab.