Concepts

Testspace organizes test results in a hierarchy, from your Organization down to each test case.

organization            your-organization.testspace.com
└─ project              Connected (a repository) or Standalone
   └─ space             a branch, a release, an environment, ...
      └─ result         one publish, one Manual spec run, or one test session
         └─ folder
            └─ suite
               └─ case

Organization

Your Organization is your Testspace account. Its name is the subdomain of your Testspace URL, chosen when you sign up:

your-organization.testspace.com

The Organization view has these tabs: Projects (the landing page), Insights, Users, Activity, and Account (owner only).

Project

A Project is a collection of Spaces. There are two types:

	Connected	Standalone
Managed by	a GitHub, GitLab or Bitbucket repository	you, in Testspace
Spaces	created automatically, one per branch (and for pull requests)	created by hand
Settings	the repository and its .testspace.yml file	dialogs in Testspace
Manual specs	Markdown files in the repository	written in Testspace's editor
More	Connected Projects	Standalone Projects

Both types publish automated results the same way, from CI or by hand, and show results in the same views.

The Project view has these tabs: Spaces, Results, Insights, Notes and Activity.

Space

A Space holds the results of one line of testing: a software branch, a release, a product variant or a test environment. Results are published to a Space, and Manual tests run in one.

The Space view has these tabs: Current (its active Result), Manual (when Manual testing is enabled), Metrics, Results and Activity.

Sandbox

A sandbox Space is for work in progress, such as staging new tests or a branch under development. Its specs and published Results are kept as in any other Space, but a sandbox Space:

• sends no result email notifications
• doesn't appear in the Organization view
• is left out of the Project's Insights
• doesn't create issues
• can't run Manual test sessions; its spec runs are trials and aren't saved
• is never judged a subset

In a Connected Project, a branch is a sandbox unless it is the default branch, the head of an open (non-draft) pull request, or configured as a release (see Release). In a Standalone Project, you choose it in the Space's settings. Every Space of an archived Project is a sandbox.

Result

A Result is one publish of automated results, one ad hoc run of a Manual spec, or one Manual test session. The Space's active Result is the one its Current tab shows; Triage notes are saved there. The Results tab lists every Result, and each Result has its own Health.

Suite and Case

A Result contains Suites, optionally organized in folders, and each Suite contains test cases. A case is the smallest unit: it passes, fails, is blocked, or doesn't run (untested or not applicable). Code coverage and static analysis are published as Suites too.

Glossary

Word	Means
Healthy / Unhealthy	every check passed / a check failed (Health)
Invalid	a Result that can't be trusted: nothing ran, or over 5,000 failures
partial	shown beside the verdict: the Result is a subset, or a metric wasn't reported (Partial)
subset	a Result with clearly fewer Suites than the Space's recent Results
not reported	a metric that normally reports has no value in this Result (Metrics That Stop Reporting)
NA	a metric with no value that wasn't expected, such as a new metric
New / Flaky / Consistent	the states of a tracked failure (Failures)
missing	a tracked failure that didn't run in this Result
retired	a tracked failure whose test stopped running; tracking ends, not as a fix (When a Tracked Test Doesn't Run)
Exempt	a failure left out of Health, set in Triage or by pytest xfail
Publication deadline	days a Space may go without a new Result before it shows as missed (Publication Deadline)
Push token	a Project's credential for publishing results (Connected, Standalone)
Access token	a user's credential for the client and the Web API