Allure TestOps terms and concepts

Terms and concepts

Following definitions are used in the documentation on this very site. If you met anything that is not covered here, please [let us know](mailto:support@qameta.io?subject='please update your documentation’)

Definition Explained
Test case A set of arrangements, actions and assets to check some feature. Automated or manual. Test case has steps with actions and expected results.
Test suite A set of test cases
Test plan A set of test cases for checking certain feature, or logically combined to achieve some target, e.g. smoke tests.
Feature A feature of your product that you intend to test.
Project Highest level of aggregation for tests. Could be used for a product or its part.
Launch Set of test results within of one or several tests runs. Contains data about the execution of test with parameters, tags and environment information as well as with the results of your tests runs.
Job An entity that is linked to a CI build job and used to run the build job
Defect Represents discovered, analysed and registered event or bug to avoid further of similar events or bugs by the members of your team.
Mute Feature allowing you to ignore some test results if a test has failed for a known reason.
Custom field Custom categories used to build tests’s tree hierarchy. Provided either manually or described in automated tests.
Tree Adjustable hierarchical view structure for test cases. Trees are built based on the Custom Fields.
Environment Set of conditions like OS, VCS branch, release ID, URL used for a specific test run / build job)
Error category Extension for test run status (Passed, Failed etc.) to add some flavour to the test results and also additionally categorise the results for the easier analysis.
Role Allure TestOps user’s role in a project, e.g. Owner, Lead etc. This is either set manually or retrieved form the test results for the automated tests.
Status (of a test case) Represents the stage of a test life cycle, e.g. ‘Active’, ‘Review’, ‘Outdated’ etc. Statuses are used to build a Workflow.
Workflow Workflows define the life cycle for tests. You can assign different life cycle stages for manual and automated test cases and even created alternative workflows for the test cases of the same type.
LiveDoc / Live documentation Automatically generated tests documentation based on the tests results.
Live Documentation policy Set of rules describing how to create the live documentation, e.g. based on the VCS branch or some tag added to a test.
Auto close policy Set of rules describing automatic closure of Launches. Live documentation is created for closed launches only, analytics and statistics are updated for closed launches only.
Tag(s) Label used to mark certain tests for easier search
Clean up schema On system’s (global) or project’s level - clean up schema defines how long certain prts of test results (attachments, scenarios, fixtures) will be stored on your file system.