How Allure TestOps works
Allure TestOps is built for test evidence, meaning test results and related context, that needs to stay shared, reviewable, and connected to the team that owns it. The core model is small: projects define the collaboration scope, launches group test executions around a shared goal defined by your team and process, and manual and automated tests are treated as equal test cases with the same data model, attributes, and metadata. The difference is how they are maintained and where the source of truth lives.
For the exact glossary used across the documentation, see the Terms and concepts page.
Projects define the shared testing scope
A project is the shared scope for visibility, analytics, test documentation, and execution in Allure TestOps. It keeps related test cases, launches, dashboards, collaborators, and integrations together, but it does not force a one-team-one-project structure. How you split projects is a team decision: by product, service, QA area, release scope, or any other boundary that makes test history and analytics useful.
In practice, keep together the work that should share:
- visibility and access;
- test documentation;
- launch history;
- analytics and dashboards;
- defects and integrations.
Launches organize test runs around a shared goal
A launch is a logical container for related test runs. Its scope is defined by your process: a CI build, release candidate, regression cycle, environment check, or any other goal the team wants to track together.
A launch helps the team answer:
- what ran;
- what passed or failed;
- what needs a defect, mute, or rerun;
- what this run means for the project.
Each test result belongs to a launch. Closing the launch finalizes its results and makes them immutable for history and analytics.
Manual and automated tests share the same data model
Manual and automated tests are equal test cases in Allure TestOps. They can use the same attributes, metadata, links, ownership, history, and analytics, so the team can see them in the same project context.
The difference is maintenance and execution. Manual tests are authored and executed in Allure TestOps. Automated tests are maintained in code, executed by the automation stack, and connected to Allure TestOps through their results.
That means you do not need to understand every product area before starting. A first evaluation is usually one of these:
- run a manual test to see the workflow entirely inside Allure TestOps;
- upload or trigger automated results to see how existing execution data appears in Allure TestOps;
- create a combined launch later if you want to review manual and automated evidence together.
Projects and launches as the shared review context
The important shift is not only that results are collected. It is that the same people can review the same evidence in one project and make the next decision from the same launch. That shared review boundary is why projects, launches, dashboards, defects, and integrations are grouped the way they are.
If you want to prove that workflow in practice, bring in one teammate early:
- Invite them to the instance if they do not yet have an account.
- Add them to the project once they can sign in.
Where to go next
Ready to try the first flow? Go to Getting started and choose the path that matches your situation.
If your first setup already works, continue with Next steps for CI, issue tracking, and dashboards.
