Tags, labels, layers, and custom fields

Use these metadata types to describe test cases in a way that improves filtering, planning, dashboards, and ownership over time. The main decision is which attribute should stay lightweight, which one should stay governed, and which values should come from automation instead of the UI.

Choose the right metadata type

Tags

Use tags for lightweight grouping that changes often.

Typical examples:

• smoke or regression scope;
• technology or platform markers;
• temporary grouping for a release or rollout.

Tags work well when a test case can have many values at once and the values do not need central governance.

Label-driven metadata

Allure labels are the automation-side transport for structured metadata. When an adapter writes labels into result files, TestOps can use them to update or enrich the automated test case.

Use label-driven metadata when:

• the automation code is the source of truth;
• the value should travel with the test implementation;
• uploads should keep the UI in sync with what the code declares.

Layers

Use layers for one mutually exclusive testing dimension such as UI, API, or unit testing. Unlike tags, a test case belongs to one layer at a time.

Layers are useful when the same reporting and planning views need one stable classification axis.

Custom fields

Use custom fields when the metadata needs stronger governance, predefined values, or a stable role in trees and reporting.

Custom fields are the right fit when you need:

• a controlled vocabulary at instance or project level;
• tree-building dimensions such as epic, component, or microservice;
• structured filtering that many users will depend on.

Decide whether metadata is owned in code or in TestOps

Automation-heavy teams usually keep metadata code-driven and let uploads update automated test cases from results. UI-owned metadata is a better fit when the value is maintained by people in TestOps and should not be overwritten by the next upload.

Use Metadata update settings when some fields must stay owned in the UI even for automated cases.

Admin and project setup

Most teams need two setup layers before the metadata becomes useful at scale:

1. Administrators declare the governed entities, such as custom fields or globally available layer names.
2. Project owners map those entities into the project and decide which values are allowed to arrive from automation.

The related owner pages are:

• Project trees for building browseable structure from governed metadata;
• Metadata update settings for choosing code-owned versus UI-owned fields;
• Test plans for reusing metadata in execution scope.