Users

A User in msg.ZenTestAI is a simulated end-user profile that a test executes as. It carries the credentials, the two-factor configuration, the browser language, the timezone, the viewport size — everything that makes a test feel like a real person interacting with your application.

Every test case is linked to exactly one User (set on the General tab of the test). When the test runs, msg.ZenTestAI logs in as that User (if a login is required) and behaves the way the User is configured.

note

Do not confuse this with the AI Assistant feature. AI Assistants are the conversational assistants that help you write or maintain tests. Users (this page) are the test-actor profiles used at execution time.

You manage Users in the left navigation under Users. The list page header shows the total count (e.g. "Available Users (5)"); click a row to open the User editor in a sidebar.

Editor layout

A Usage References button in the editor header shows every test that currently uses this User, so you can review who would be affected before changing credentials or deleting the User.

The User editor is grouped into four collapsible sections:

• General — title and description.
• Authentication — the authentication mode and the credentials/secrets that go with it. See Login and Authentication for the full per-mode walkthrough.
• Viewport — the simulated browser environment (language, timezone, screen size).
• Client Certificates — optional client-side SSL/TLS certificate and key, for sites that require mutual TLS.

General

Field	Description
Title	The name shown for this User in the picker on the test General tab. Required.
Description	Optional free-text notes about the User. Limited to 300 characters.

Authentication

The Authentication section controls how the test logs in. The set of visible fields depends on which authentication mode you pick — the section is intentionally minimal for users that don't need a login at all.

The available modes are:

• None — no login is performed; the test starts directly on the configured URL.
• Password (Basic Auth) — username + password. A second Variant dropdown decides how the credentials are delivered (login form, HTTP basic-auth header, bearer token header, NTLM, NTLM with login page).
• OAuth + TOTP — username + password + a time-based one-time password (Google Authenticator style).
• HOTP — username + password + a counter-based one-time password, optionally with a PIN.
• Yubikey OTP — Yubikey hardware-token simulation using AES key + public/private IDs.

For mode-specific fields, the login flow at runtime, and how to set up two-factor secrets, see Login and Authentication.

Identification fields

Three optional identification fields are available on every authenticated mode:

• E-Mail — the User's e-mail address. Useful when the login form requires e-mail (rather than user-name) or for easier identification in the list.
• Client/Tenant — a tenant or client identifier for multi-tenant applications where the login must specify which scope to log into.
• Entitlements — a free-text label (or comma-separated list) of the permissions/roles this User should have in the application under test. Used as metadata to help map external-system test-data to the right User during import, and to make the list easier to read.

Secrets are stored encrypted

After the first save, secret fields (Password, TOTP secret, HOTP secret, Yubikey AES key, Yubikey private ID) are not shown anymore and cannot be retrieved through the UI. They are encrypted at rest. To rotate a secret, edit the User and enter the new value — leaving the field empty keeps the existing one.

Two-factor helper buttons

When a two-factor mode is selected, a small refresh button appears next to the secret field. It generates the next valid OTP from the configured secret so you can quickly verify the value with your authentication provider during setup (and confirm a new TOTP device the first time).

For HOTP there is an additional edit button that lets you manually adjust the HOTP counter — useful when the counter drifts out of sync with the target system.

Viewport

The Viewport section simulates the user's browser environment:

Field	Description
Browser language	The language the browser advertises to the application (e.g. English – en, Deutsch – de). Affects which localization the application under test serves. Picked from a fixed list.
Timezone	The simulated browser timezone, used wherever the application reads the user's local time. Defaults to UTC (UTC+0). Picked from a fixed list of about 36 timezones.
Used browser device	A preset that defines the viewport size and form factor. Includes Desktop-Small / Medium / Large, iPad Landscape / Portrait, iPhone Landscape / Portrait, and two Custom options (Desktop or Phone) that let you set the width and height in CSS pixels.

Client Certificates

For applications that require mutual TLS, attach the User's client certificate and private key here. The runner will present the certificate to any site that asks for one during the test execution.

Tips

tip

A common pattern is to keep one User per persona (e.g. Admin, Customer, Read-only viewer) and reuse it across many tests. Switching the User on a test then switches the entire identity of the simulated session — including viewport and language — without having to touch the test itself.

warning

A test case can only be linked to one User, and the login is always the first step of the test. To exercise multi-user scenarios — for example "Admin creates an order, customer approves it" — split the flow into several tests and chain them with an execution plan. For doing two logins in one test, use a snippet with Login required and the Isolated toggle enabled (see Test-Case Definition → Snippets).