Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.testsprite.com/llms.txt

Use this file to discover all available pages before exploring further.

This page defines the building blocks the Web Portal uses. If you’ve already used TestSprite once, most of these will feel familiar — this is the canonical reference for when a teammate asks “wait, what’s a Test List vs a Test?”

​
Project

The top-level container for everything you do in the portal. A project represents one application (or one slice of an application — e.g. one micro-frontend or one API surface) and groups all the tests, runs, credentials, and variables that belong to it.
A project bundles:
  • Type: UI (frontend), API (backend), or both
  • Configuration: starting URL or API endpoints, auth credentials, extra context
  • Generated tests: every test case TestSprite drafted for this app
  • Run history: every execution of those tests, with results and recordings

Test Detail

Tour of every tab on the project detail page

​
Test

A single executable check inside a project. UI tests are multi-step user-journey tests (sign in → navigate → fill a form → assert); API tests are typically per-endpoint checks (call → assert status, schema, contract).
A test has:
  • A title (e.g. “Verify successful login with valid credentials”)
  • A description in natural language
  • A list of steps TestSprite will execute
  • Expected outcomes the test will assert against
  • A status after each run: Pass, Failed, or Blocked

​
Test Run

One execution of a project’s tests, end to end. Each run produces results, screenshots, recordings, and (for API tests) the call logs TestSprite made to your service.
A run captures, per test:
  • Pass / Failed / Blocked verdict
  • Step-by-step screenshots (UI) or HTTP requests and responses (API)
  • A video recording for UI tests
  • An AI-authored failure analysis when something didn’t go as expected

​
Test List

A reusable collection of tests, often spanning more than one project. Test Lists are how you assemble a regression suite, smoke check, or release-gate suite.
A Test List groups individual test cases — frontend, backend, or both — under one name. The list itself has its own run history (every time it’s executed) and is the unit you schedule for continuous monitoring.

Test Lists

How to create and manage Test Lists

​
Schedule

A recurring rule that runs a Test List automatically — daily, weekly, monthly, or on a custom cadence. Schedules turn one-off testing into continuous monitoring.
A Schedule binds:
  • A Test List (what to run)
  • A frequency (when to run it)
  • A timezone (so 6 AM means 6 AM where your team works)
  • Notification preferences (who hears about failures)

Monitoring & Scheduling

Schedule continuous test runs

​
Feature Map (Use Case Flow)

A structured list of features and the use cases under each, built from your PRD when you upload one at project setup. It’s the spec-side input that grounds the rest of the lifecycle — exploration targets these use cases, plan generation scopes test cases to them, and the report attributes coverage back to them.
TestSprite reads your uploaded PRD (markdown / PDF / plain text — anything spec-shaped) and produces something like: Feature: Checkout → Use Cases: Add to cart, Apply coupon, Pay with card, Pay with PayPal, Handle payment failure. The result is rendered as a flow graph during the wizard’s Use Cases & Features step, and persists as the Use Case Flow tab on the project detail page.

​
Feature Exploration (Beta)

A pre-test phase for UI projects where TestSprite visits your live app and explores it feature by feature, targeting the use cases from the feature map. The test plan in the next step is grounded in both the spec (feature map) and real behavior (what exploration could and couldn’t reach).
Exploration walks a list of features (Sign Up, Checkout, Profile, etc.) on your live app, captures what it could and couldn’t reach, and surfaces a status per feature: Exploring while it’s running, then Done, Failed, or Blocked when it finishes.

Feature Exploration

Deep dive on the exploration phase

​
Variables (Dynamic Variables)

Values captured from one API test and reused as inputs in a downstream test — the way TestSprite stitches together multi-step API flows.
When TestSprite runs POST /orders and gets back { "orderId": "abc" }, it can capture orderId as a dynamic variable. A later GET /orders/{orderId} test then consumes that captured value instead of a hard-coded one.You’ll see the captured variable name (e.g. orderId) and its values across runs on the Dynamic Variables tab.

​
Credentials (Authentication)

The keys, tokens, or login details TestSprite uses to call your APIs or sign into your app during testing.
For API projects: per-API auth type (Bearer Token, API Key, Basic Token, or None) plus the secret value, with bulk update if one token covers many endpoints.For UI projects: a test account (URL + username + password) TestSprite uses to sign into your app during exploration and runs.Credentials are stored encrypted, masked in the UI (only first/last few chars shown), and editable any time from the Authentication tab.

​
Cleanup

Post-run teardown of resources tests created — records, files, sessions — so your test environment doesn’t fill with leftovers.
After API tests finish, TestSprite reviews any resources the suite created and tries to clean them up automatically. The Cleanup tab shows which resources were captured during the run and the status of each cleanup attempt (Has cleanup, Orphaned).

​
Test Plan

The structured list of test cases TestSprite drafts after analyzing your project. The plan is what you review and refine before any code is generated.
Each entry in a Test Plan has:
  • A title and description
  • A category (functional, security, error handling, etc.)
  • Steps TestSprite will execute when the test runs
  • Expected outcomes for each step

​
Where to Go Next

Testing Lifecycle

How these terms come together end to end

UI Testing

First UI test, step by step

API Testing

First API test, step by step

Test Detail

Every tab on the project detail page