TestInspector automates 2FA login flows through the {{TOTP:secret}} variable, which accepts a base32-encoded TOTP secret and generates a valid one-time password at the moment the test step executes, eliminating the need for hardcoded codes or external tools. The secret is stored as an encrypted variable at the test, suite, or organization scope, so it is never exposed in plain text in the test definition or execution logs. This approach supports scheduled runs, CI-triggered suites, and cross-browser execution without modifying the application's authentication configuration.

Two-factor authentication creates a practical problem for automated testing: the one-time password changes every thirty seconds, so any code captured during test authoring is invalid by the time the test runs. Teams that have not addressed this problem typically handle it one of three ways: they disable 2FA on test accounts, mock the authentication service, or use a custom script that generates TOTP codes externally. All three approaches have meaningful drawbacks. Disabling 2FA on test accounts creates a coverage gap for one of the most security-critical flows in most applications. Mocking the auth service does not test the real user experience of completing the second factor. External scripts introduce a maintenance dependency and can produce timing failures when the code is generated slightly before the execution window. For teams building reliable test automation practices, native TOTP support inside the test platform removes all three problems from the equation.

Why TOTP Codes Cannot Be Hardcoded in Test Steps

TOTP (Time-based One-Time Password, RFC 6238) generates a six-digit code by hashing the shared secret with the current Unix timestamp divided into thirty-second intervals. A code valid at 14:35:00 is invalid at 14:35:30. Any test that captures a TOTP code during authoring — whether through a recorder or manual entry — will fail every run after the first because the captured code is no longer valid.

This time dependency distinguishes TOTP from other dynamic values in test automation. Variables like test usernames, environment URLs, or form inputs can be parameterized with static values because they do not expire on a thirty-second clock. TOTP codes require runtime computation, not runtime substitution. A static variable containing a TOTP code value is not a workaround — it is a test that will fail every time it runs in an automated context.

The base32-encoded secret, by contrast, does not change between runs. It is the seed that generates codes, not a code itself. Storing the secret securely and computing the code at runtime is the correct architecture for automated 2FA testing. The distinction matters for how test data is stored, accessed, and protected in the software testing workflow.

How {{TOTP:secret}} Variables Work in TestInspector

The {{TOTP:secret}} syntax in TestInspector accepts the base32-encoded secret string used to configure TOTP in the target application. This is the same value that authenticator apps like Google Authenticator or Authy scan when 2FA is enabled — it is typically displayed as a QR code and also available as a plain text string in the account security settings during setup.

At runtime, when a test step contains {{TOTP:secret}} in an input field, TestInspector computes the current TOTP value using the stored secret and the current timestamp. The computed six-digit code is inserted into the step input at that moment, which means it is valid for the current thirty-second window when the application receives it. The computation happens automatically — no external library call, no script dependency, no timing coordination is required in the test steps.

The variable syntax follows the same interpolation model as other TestInspector variables. A step that types a value into an OTP field uses the same structure as any other input step, with {{TOTP:secret}} as the value. The system recognizes the TOTP prefix and triggers the code generation at execution time. Live run output is streamed via WebSocket, and the actual code value is masked in logs to prevent accidental exposure of a valid OTP in run records.

Encrypted Variable Storage and the Variable Hierarchy

The base32 TOTP secret is stored as an encrypted variable in TestInspector. Encrypted variables are not displayed in plain text at any point in the interface: the value is stored encrypted at rest and is never shown after initial entry. In execution logs, the interpolated value — the six-digit code — is masked so that a valid OTP does not appear in the run history where it could be captured and reused within its validity window.

Variable scope in TestInspector follows a three-level hierarchy: test-level variables are specific to a single test and override any same-named variables in higher scopes, suite-level variables apply to all tests within a suite, and organization-level variables are shared across all suites and tests in the organization. For TOTP secrets, the appropriate scope depends on whether the secret is unique to a test or shared across multiple tests and suites.

If a test account is used across multiple test suites — for example, a shared QA user account whose 2FA is configured once in the test environment — an organization-level encrypted variable allows all suites to reference the same secret without duplicating storage. If different test accounts require different TOTP secrets, suite-level variables keep each secret scoped to the relevant suite. Test-level variables are appropriate when a specific test is the only consumer of a particular test account's 2FA configuration.

The hierarchy also determines how overrides work. A test-level variable with the same name as an org-level variable takes precedence during that test's execution, which is useful for running parameterized tests against different user accounts with different TOTP secrets without restructuring the suite. This mirrors how environment-specific test data is managed for other dynamic inputs in the complete software testing guide.

Building a Complete 2FA Login Test in TestInspector

A 2FA login test in TestInspector follows the same structure as any multi-step authentication flow, with the TOTP variable inserted at the second factor step. The following steps describe a representative flow for an application with email and password first factor and a TOTP-based second factor.

The first step navigates to the login URL — typically a variable such as {{BASE_URL}}/login, so the test runs against different environments without editing steps. The second and third steps enter the test account username and password, both stored as encrypted variables. The fourth step clicks the login button or submits the form. The fifth step waits for the OTP input to appear, either by asserting a specific element is visible or by using a wait step with a target selector for the OTP field. The sixth step enters {{TOTP:secret}} in the OTP input field. The seventh step submits the OTP. The eighth step asserts the expected post-login state, such as the dashboard URL or a user-specific element that only appears after successful authentication.

This sequence tests the full 2FA flow as a user would experience it. The test does not skip any step, mock any service, or rely on the application being in a special mode. It runs on the actual login surface in whatever browser is selected — Chrome, Firefox, Edge, or Safari — and produces a pass or fail result based on whether the application accepted the generated OTP and completed the login.

TestInspector's browser extension can record the navigation and interaction steps, reducing authoring time for the non-TOTP steps. The {{TOTP:secret}} variable is then substituted into the recorded OTP field step manually, replacing whatever value the recorder captured during the session. For teams evaluating TestInspector against their existing testing toolchain, the ability to handle TOTP without external dependencies is often the deciding factor for applications where 2FA is enabled on all accounts in the test environment. Teams looking to build or augment a QA team will find that reducing framework complexity lowers the barrier for QA engineers without scripting backgrounds to own 2FA test coverage end to end.

Scheduling, CI/CD Integration, and Cross-Browser 2FA Coverage

Automated 2FA tests in TestInspector run on the same scheduling and CI trigger infrastructure as any other test. Scheduled runs use cron expressions, interval-based triggers, or one-time schedules configured on the suite. A suite containing 2FA tests can be scheduled as a nightly smoke test or triggered on every deployment through the CI/CD trigger API, which accepts an HTTP POST request with an API key and returns a run ID for status polling.

Because the TOTP code is generated at runtime by the TestInspector execution engine, there is no additional configuration required to make 2FA tests work in CI. The encrypted TOTP secret is resolved from the variable store at execution time on the managed Selenium grid, the same as any other encrypted variable. The CI pipeline does not need to manage TOTP libraries, inject secrets as environment variables, or coordinate timing between a code generation script and the test runner.

Cross-browser coverage for 2FA flows is configured at the suite or test level by selecting the target browsers. Running the same 2FA test across Chrome, Firefox, Edge, and Safari verifies that the OTP input behavior, form submission, and post-login state are consistent across browsers — a meaningful coverage point for applications where the 2FA UI has been customized. The manual vs. automated testing guide covers additional guidance on which test types benefit most from automation investment and how to prioritize coverage.

Comparison: 2FA Testing Approaches

Frequently Asked Questions

Is it safe to store a TOTP secret in TestInspector?

Yes. TestInspector stores TOTP secrets as encrypted variables, meaning the raw value is encrypted at rest and is never displayed in plain text in the interface, test steps, or execution logs. The computed OTP value is also masked in log output to prevent a valid code from appearing in run history. The security model is equivalent to how any sensitive credential — password, API key, or service token — is managed in a testing platform that supports encrypted variable storage.

Can I use the same TOTP secret for development and staging environments?

Yes, if the test accounts configured in development and staging share the same TOTP secret, which is common when test accounts are provisioned from the same seed configuration. If development and staging use separate account provisioning with distinct TOTP secrets, configure environment-specific secrets at the suite or org level using variable naming conventions that distinguish the environments.

What happens if the TOTP window expires just before the step executes?

TestInspector's TOTP implementation handles window timing so the generated code is valid at the moment it is submitted to the application. The RFC 6238 standard allows for a tolerance window of plus or minus one interval on the server side, and most applications implement this tolerance. If your application has a stricter validity window, verify execution timing alignment with your configured tolerance before deploying to scheduled runs.

Can I test SMS-based OTP flows with TestInspector?

SMS OTP flows require receiving and reading a code delivered via SMS, which is outside the scope of browser-based test automation. These flows are most reliably tested by using a test phone number service that exposes received SMS messages via API, then reading the code from the API response in a TestInspector HTTP request step before entering it in the OTP field. TestInspector supports HTTP GET steps with response body assertions, which can be adapted to read OTP codes from SMS gateway APIs.

How do I get the base32 TOTP secret for my test account?

The base32 secret is available when 2FA is initially configured on an account. Most applications display it as both a QR code and a plain text string during the setup flow, typically labeled as the secret key or manual entry key. For test environments, provision test accounts with 2FA and capture the secret during setup. If your test environment generates accounts programmatically, the TOTP secret is typically accessible through the account provisioning API or the user management database used for the test environment.

Does {{TOTP:secret}} work in scheduled and CI-triggered runs?

Yes. The TOTP code is generated by the TestInspector execution engine at the time each run executes, regardless of how the run was triggered. Scheduled runs, CI-triggered runs via the API, and manually executed runs all use the same execution path. The encrypted secret is resolved from the variable store and the code is computed at runtime in every case, with no special configuration required to enable TOTP generation in automated run contexts.