---
title: "Allure | Skills We Assign For | Azendo"
description: "Allure test reporting — categorised failures, historical trends, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/allure/"
---

[Skills](https://azendo.co/skills/) QA and delivery tooling 

# Allure.

Allure is a test reporting framework producing detailed HTML reports from most major test frameworks, with steps, attachments, history and failure categorisation. It turns a pass/fail count into something a non-tester can read.

## Where Allure fits on a long engagement.

Raw CI output is unreadable to anyone not already familiar with the suite. Allure produces a report showing which tests ran, which steps each executed, and what was attached at the point of failure — screenshots, logs, request payloads — which is usually enough to diagnose without reproducing.

History and categorisation are what make it more than a prettier log. Seeing that a test has failed intermittently for three weeks distinguishes a flaky test from a new regression, and that distinction is the one teams most often get wrong when deciding whether a red build blocks a release.

## What an assigned team does with Allure.

Reporting is how testing communicates outside its own function. A product owner who can see what was verified makes better release decisions than one told only that the suite passed.

Making that visible is part of the assigned testing capacity's job under [qa outsourcing](https://azendo.co/services/qa-engineering-and-test-automation/), not a reporting layer added afterwards.

## What we use Allure for.

* Failures diagnosed from the report Screenshots and payloads attached at the failing step, so reproduction is rarely needed.
* Flaky separated from broken Historical trends that distinguish a long-standing intermittent from a new regression.
* Evidence for people outside QA A readable account of what was verified, for release decisions and for auditors.

## How Allure capacity is assigned.

Reporting is how testing communicates outside its own function, so it is part of the assigned capacity rather than a layer added afterwards. What that capacity covers is set out in [how the monthly fee is built](https://azendo.co/pricing/).

## Roles we assign Allure for

* [Test Automation Engineer QA and test automation](https://azendo.co/services/qa-engineering-and-test-automation/test-automation-engineer/)

## Service lines it sits in

* [QA and test automation](https://azendo.co/services/qa-engineering-and-test-automation/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in qa and delivery tooling

* [Jira — skill we assign for](https://azendo.co/skills/jira/)
* [TestRail — skill we assign for](https://azendo.co/skills/testrail/)
* [Jest — skill we assign for](https://azendo.co/skills/jest/)
* [React Testing Library — skill we assign for](https://azendo.co/skills/react-testing-library/)
* [XCTest — skill we assign for](https://azendo.co/skills/xctest/)
* [Espresso — skill we assign for](https://azendo.co/skills/espresso/)
* [Detox — skill we assign for](https://azendo.co/skills/detox/)
* [Flutter Test — skill we assign for](https://azendo.co/skills/flutter-test/)

## Tell us what your roadmap needs Allure for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)
