Concepts

The terms Testsigma uses, grouped by where you meet them.

Structure

Project holds everything for one product under test: its applications, test cases, elements, and test data.

Application is what you are testing, and its type is fixed at creation. A project holds one by default, or several once Allow adding multiple applications is on.

Application version separates test assets for different releases of the same application.

Requirement is a documented functional need. Assigning requirements to test cases is how you trace coverage back to what was asked for.

Folder and subfolder organize the test case library. A folder groups related subfolders, and each subfolder holds its test cases.

Save point stores the state of a whole project, so you can restore it later. Testsigma keeps up to 10 and creates one automatically before an import.

Authoring

Test case is a list of steps, executed in order, that automates one test scenario.

Test step is one action inside a test case. Its type is natural language by default, and can be changed to a REST API call, a step group, a loop, a condition, or a block.

Natural language action, or NLP, is a step written in plain English, such as Enter test data in the element field.

Step group is a saved sequence of steps, reused across test cases. A login flow written once serves every test case that needs it.

Element is something on a page or screen a step acts on: a button, a link, an input field. An element holds the locator that finds it, such as an XPath or an accessibility ID.

Elements repository holds every element in an application version, reusable across all its test cases.

Test recorder captures your interactions as steps, along with the elements they touch. Faster than writing steps by hand, and it captures more locator detail.

Copilot authors, executes, and debugs in one live session. It generates steps from the current screen, runs them inline, and gives you execution controls and diagnostics while you build.

Atto is Testsigma’s AI layer. Its agents work across authoring, execution, and diagnosis rather than one part of it: Generator, Agentic Learning, Test Data Generator, Analyzer, and Bug Reporter.

Generator turns requirements, designs, documents, and prompts into test cases, then automates them against your live application.

Agentic Learning explores your live application and corrects a generated test flow, adding missing steps and fixing the order. It proposes, and you accept the result before it is saved.

Test Data Generator builds a test data profile for a data-driven test case, instead of you entering the rows.

Analyzer explains why a step failed, naming the error type and root cause, and proposes fixes you apply in a click.

Bug Reporter files a failure as a ticket in your bug tracker, carrying the analysis and screenshots into it.

Auto-healing repairs a broken locator during a run. When an element’s XPath changes after a UI update, Testsigma finds the new one, the step continues, and the change is listed in the run result.

Test data

Test data profile holds data in rows for data-driven testing, entered in Testsigma or imported from Excel. A test case bound to a profile runs once per row.

Test data type is where a step’s value comes from: a raw value, a profile parameter, a runtime variable, an environment value, or a generated one.

Data generator produces a value at run time, such as a random email or a date offset from today.

Runtime variable carries a value from one step to a later one, within a run.

Environment is a set of values that changes by target, so the same test case runs against QA, UAT, and staging without edits.

Uploads holds the files a test needs: mobile builds, and attachments a step sends.

Execution

Test suite groups related test cases to run together. A dynamic suite holds a filter instead of a fixed list, so it picks up matching test cases created later.

Test plan decides what runs, where, and when: which suites, on which machines, with which settings and schedule.

Test machine is a browser or device a test runs on, defined by its OS, version, and resolution.

Test lab is where a test machine lives: Testsigma’s cloud, your own devices, or a third-party cloud such as BrowserStack.

Ad-hoc run executes one test case immediately, outside any suite or plan, to check it works.

Prerequisite is a test case that runs before another one, so a login or a setup flow does not have to be repeated in every test case that depends on it.

Partial run executes part of a test plan rather than all of it, filtered by suite or by test case attributes, and can be saved as a favorite for reuse.

Parallel and queued limits come from your subscription. The parallel figure is how many things run at once, and the queue is how many wait behind them.

Desired capabilities are key-value pairs that configure the browser or device for a run, such as a time zone, an extension, or a geolocation.

Testsigma Agent runs tests on your own machines, handling queueing, execution, and results.

Testsigma Terminal is the desktop application that manages the agent and runs Copilot sessions locally.

Testsigma Tunnel routes a cloud test’s traffic through your network, so an application behind a firewall can be tested on cloud machines.

Testing approaches

Each of these is a shape a test plan takes, rather than a feature of its own.

Cross-browser testing runs the same test suites across several browsers, to confirm behavior holds on each.

Parallel testing runs several things at once instead of in sequence, cutting the total time a plan takes. How many run at once depends on the parallel and queued limits in your subscription.

Distributed testing splits one scenario across machines, each running a different part of the application, for systems whose components run in different places and talk to each other.

End-to-end testing validates a whole business workflow across applications and platforms, such as booking on web, cancelling on mobile, and checking the refund on web again.

Headless testing runs the browser without rendering its interface, so tests execute faster and use fewer resources. It is web only, and records no video.

Data-driven testing runs one test case repeatedly, once per row of a test data profile.

Scheduled testing runs a plan without anyone triggering it. It runs on the date, time, and repeat frequency you set.

Local testing runs on your own machines and devices rather than Testsigma’s cloud, for an application inside your network or a specific physical device.

Collaboration and governance

Role decides what a user can do, and is assigned per project, so someone can be a Test Lead on one project and read-only on another. Testsigma has 6, from Super Administrator with full control short of account and billing information, through Test Manager across several projects and Test Lead within one, down to Automation Engineer/Developer for authoring and a read-only role for viewing.

Review management puts a test case or an element through approval before it counts as ready. Submit for review, a reviewer approves or rejects, and self-review is available where a second pair of eyes is not required.

Execution stop permissions control who can stop a run in progress, so one person cannot end a run another team depends on.

Audit log records who changed what and when, and can be filtered and exported.

Custom field is a field you define on a test case, application, version, or project, for organizing and filtering beyond the built-in attributes.

Results and analysis

Run result reports an execution at test suite, test case, and test machine level, with screenshots, logs, and video.

Visual testing compares a screenshot against a stored baseline, so a layout change surfaces as a failed comparison.

Accessibility testing scans against WCAG guidelines and reports the violations, per step.

Mock server returns simulated API responses during a run, so a test does not depend on the real backend.

Dashboard tracks results over time. A Legacy dashboard is fixed. An Advanced dashboard is built from widgets you choose.

Extending Testsigma

Addon adds actions of your own to Testsigma’s built-in set, written in Java for Classic applications or TypeScript for Modern ones.

Plugin integrates a third-party tool such as Jenkins, Slack, or Microsoft Teams.

Execution engine is either Classic or Modern, chosen when you create an application and fixed afterwards. It decides which addon language applies and which features are available.

CI/CD integration triggers a test plan from your build pipeline, so tests run on every commit or deploy. Testsigma ships integrations for Jenkins, GitHub, GitLab, Azure DevOps, AWS, Bitbucket, CircleCI, Travis, Bamboo, and others, and a shell script or the REST API covers anything not on that list.

REST API drives Testsigma programmatically: trigger a plan, fetch results at any level, upload test data or files, and read project information. An API key from Settings > API Keys authenticates the call.