Terms and concepts
These terms define the public Allure TestOps model used throughout the documentation and product UI.
| Term | Meaning |
|---|---|
| Project | The main workspace boundary in Allure TestOps. Projects contain launches, test cases, plans, dashboards, jobs, and project-level settings. |
| Test case | A managed test asset in Allure TestOps. It can be manual or automated and can include metadata such as tags, links, owners, and workflow status. |
| Test result | One execution attempt of a test inside a launch. A result has a status, metadata, and optionally steps, attachments, retries, history, defects, and issues. |
| Launch | The shared execution context for one testing activity. A launch groups the test results, launch metadata, and related review actions for that activity. |
| Job | The reusable link between an Allure TestOps project and a CI pipeline definition. |
| Job run | One execution of a job inside a launch. Automated CI-driven results are grouped into job runs. One launch may contain several job runs. |
| Test plan | A reusable execution scope: a named set of test cases, optionally defined by filters or AQL, and optionally assigned to users or jobs through executors. |
| Environment | A set of named variables that describe the runtime context of a run, such as browser, platform, branch, or release. |
| Defect | A known problem captured in Allure TestOps and linked to the test results, test cases, and launches it affects. Defects can have automation rules for future matching. |
| Mute | A way to suppress or ignore expected noise from a specific test result or test case context. Use a mute for noise control, not to represent a shared known problem. |
| Workflow | The lifecycle model for test cases. A workflow defines which statuses exist and how a test case moves between them. |
| Status (of a test case) | The current lifecycle state of a test case inside its workflow, for example draft, active, or outdated. |
| Custom field | A project-defined metadata field used to classify test cases and support filtering, organization, and reporting. |
| Tree | A hierarchical view of test cases built from project metadata, usually custom fields. Trees help teams browse scope instead of relying only on flat lists. |
| Tag | A simple reusable label applied to test cases or launches for search, grouping, and filtering. |
| Error category | A failure-oriented grouping used during result analysis. Categories complement execution hierarchy by grouping failures by problem type rather than by test structure. |
| Test key | A link from a test case in Allure TestOps to a test case in an external test management system such as TestRail or Zephyr Scale. |
| Allure ID | The stable identifier of a test case inside Allure TestOps. It is used to link automation code to an existing Allure TestOps test case and avoid duplicates after refactoring. |
| Auto close policy | Project rules that close launches automatically after a configured delay. Closed launches are the ones that update analytics and automated test cases. |
| Cleanup policy | Rules that define how long launch artifacts such as attachments and other stored execution data are kept before cleanup. |
© Qameta Software Inc. All rights reserved.
