Gain a basic understanding of Thunders' core concepts so you can set up your organization and navigate efficiently.

A Thunders organization is the top-level container for everything you do in the platform. When you sign up, you create or join an organization.

You can manage test projects, members and their roles, configure API tokens for CI/CD integrations, and control billing from the organization settings.

A test project groups related test artifacts together: test plans, test cases, test sets, environments, variables, and apps.

Each project can be connected to external sources (Jira, Notion, Confluence, Linear, Xray…) through connectors. Thunders AI can pull knowledge context from these sources when creating tests, and can report bugs back to them.

Learn more: Add / Edit / Delete a Test Project

An app represents a distinct application within a test project. Each app corresponds to one of the applications that make up your product under test, such as a customer-facing frontend, an admin dashboard, or a backend API.

Thunders supports four app types:

A project can contain multiple apps. This lets you write test cases that span different applications in a single workflow (for example, change a setting in the admin panel, then verify it on the customer portal).

When you create a project, you configure your first app by choosing its type. You can add more apps later from the Apps view. Each app has its own URL per environment, so Thunders knows which URL to target when running tests against a specific app in a specific environment.

Learn more: Add / Edit / Delete a Test Project

An environment represents a deployment context where tests run, such as development, staging, or production. Each environment has its own URL per app, its own variables, and its own credentials. This lets you run the same test cases under different conditions without modifying them.

Key characteristics:

Learn more: Add / Edit / Delete an Environment

Variables let you parameterize test cases so they can be reused across environments without hardcoding values. Reference any variable in your test steps using the [VARIABLE_NAME] syntax. Thunders replaces it with the actual value at execution time.

Thunders supports three types of variables:

Variable names must use only uppercase letters, numbers, and underscores. Maximum 32 characters, no spaces or special characters.

When writing test steps, you can type / or [ to trigger the auto-complete picker and quickly insert a variable reference.

Variables can be defined at two levels:

Learn more: Variables

Thunders AI is the AI assistant built into every project. It can generate test plans from a requirements file or user story, write test case steps from a natural-language description, and browse your application to propose test flows.

Thunders AI uses the project's connectors and knowledge sources for context, so the tests it generates are grounded in your actual requirements and documentation. You can also ask it questions about your existing tests, such as how many test cases you have or whether a specific flow is already covered.

A test plan is a structured document that defines what needs to be tested for a feature, module, or user story. Rather than writing test scenarios manually, you can import a requirements file or paste a user story and let Thunders AI generate the test scenarios for you.

Each test plan is organized into sections and scenarios. Sections group related scenarios together, and each scenario describes a specific flow to validate. From any scenario, you can create test cases directly, keeping requirements and tests linked throughout the lifecycle.

Learn more: Generate Test Plans with Existing Variables

A test case is a sequence of steps that verify specific functionality. Test cases belong to a project and can reference variables, target specific apps and environments.

Thunders supports several step types:

Test cases also support a main stage and a teardown stage, so cleanup steps always run even if the main flow fails.

Learn more: Add / Edit / Delete a Test Case · Execute a Test Case · Run Test Cases from the List

A test set is a collection of test cases grouped together to test a specific feature, component, or workflow. A single test case can belong to multiple test sets, so you can organize the same tests in different ways without duplicating them.

Each test set has its own dedicated workspace where you can see the pass rate, view set-level run history, and manage all included test cases in one place. You can search, filter, add, or remove tests from the same page, and execute the full set without jumping between screens.

Learn more: Test Sets

Labels are custom tags you can apply to test cases to categorize and filter them. Each label has a name, color, and optional description. You can create labels from the project’s Labels tab, or inline while editing a test case (from the test case editor or the test cases list).

A test case can have multiple labels, and labels can be searched and filtered across the project. Labels can be archived when no longer needed without affecting the test cases they were applied to.

Learn more: Custom Labels

Test assets are files that your test cases use as inputs or produce as outputs. Examples include images for visual comparisons, CSV files for data-driven tests, or documents for file upload scenarios.

The test assets library gives you a central view of all files in a project. From there, you can upload new assets, see which test cases reference each file, download files, and edit asset metadata.

Learn more: Test Assets

A test run is the actual execution of one or more test cases in a specific environment. It captures pass/fail results, execution time, screenshots, and logs. Test runs give you a clear view of testing progress and help identify failures.

Learn more: View a Test Run Report · Run Test Cases from the List

Personas are configured per project. When you run a test, you choose a persona that defines how the AI approaches your application. Each persona has a unique profile, perspective, and set of capabilities.

Built-in personas include a QA engineer, a performance specialist, a security analyst, and an SEO consultant. There is also a configurable accessibility persona that you can set up with specific standards (WCAG 2.1 AA, Section 508, etc.), testing tools, and severity thresholds.

Learn more: Meet our Personas · Accessibility Persona