Allure Reports
Beautiful, interactive test reports for any test framework. Transform raw test results into executive-ready dashboards.
Overview
Allure is an open-source test reporting framework that generates beautiful, interactive HTML reports from test results. Unlike plain text or basic HTML reports, Allure provides detailed test timelines, step breakdowns, attachments (screenshots, logs, videos), and trend analysis. It supports virtually every test framework — JUnit, TestNG, PyTest, Jest, Cypress, Playwright, and many more.
Allure is particularly popular with automation teams that need to present test results to stakeholders. The visual clarity and interactivity of Allure reports make it easy to identify flaky tests, analyse failure patterns, and track quality trends over time.
What it's used for
Allure is ideal when:
- Professional test reporting needed: Executive-ready reports that impress stakeholders.
- Test result analysis: Detailed step breakdowns with screenshots, logs, and attachments.
- Trend tracking: Monitor pass rates, flaky tests, and execution times over time.
- Multi-framework standardisation: One reporting format across JUnit, PyTest, Jest, and Playwright.
Pros & Cons
Pros
- Beautiful, interactive HTML reports
- Supports 20+ test frameworks
- Detailed step breakdowns with attachments
- Trend analysis and flaky test detection
- Free and open source
Cons
- Requires configuration to integrate with test frameworks
- Report generation adds time to CI pipelines
- Allure TestOps (enterprise) is expensive
- Trend data requires persistent storage
- Some frameworks have limited Allure integration
Platforms & Integrations
Allure runs on Windows, macOS, and Linux. It generates static HTML reports that can be served from any web server or CI artifact storage.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Allure Report | Free | Report generation, all frameworks, community support |
| Allure TestOps | Custom | Centralised dashboards, test case management, analytics, SSO |
NZ Context
Allure is widely used in NZ automation teams for test reporting. It is particularly popular with Playwright, PyTest, and JUnit users who want better reporting than the default output. NZ QA meetups frequently showcase Allure reports as the standard for professional test presentation. For NZ testers, adding Allure to an automation framework is a quick way to improve reporting quality.
Alternatives
- TestRail — Test management with built-in reporting. More structured but less visual.
- ReportPortal — Real-time test reporting with AI-powered analysis.
- JUnit HTML Reports — Basic built-in reporting. Free but minimal.
When to choose Allure
A quick decision guide for NZ teams evaluating test reporting options.
| Choose Allure when… | Choose something else when… | Combine with… |
|---|---|---|
| You need to present automation results to non-technical stakeholders or a product owner who won't read raw logs | Your team needs a centralised test case repository — use TestRail or Xray, which have real test management alongside reporting | Playwright or PyTest as the execution engine; Allure just adds the reporting layer on top |
| You run tests across multiple frameworks (e.g. Playwright for UI + PyTest for API) and want a single, consistent report format | You need real-time test analysis and AI-assisted failure triage at scale — ReportPortal is better suited for that workload | GitHub Actions or GitLab CI artifact storage to persist historical trend data between pipeline runs |
| You want to attach screenshots, videos, and log snippets directly to the failing test step — not as separate CI artefacts | Your project is mostly manual testing — Zephyr Squad or TestRail fits manual workflows far better than Allure, which is built around automated results | A Slack or Teams webhook to post a summary link after each CI run, so the team sees results without hunting for the report URL |
| Budget is tight — the free Allure Report CLI is fully featured for most teams; no licence negotiation required | You need enterprise compliance features (SSO, audit logs, role-based access) without a large budget — Allure TestOps pricing can surprise you; compare against open-source ReportPortal first | A simple S3 bucket or Azure Blob Storage to host the static HTML report so the whole team can access it without a Jenkins login |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
allure-playwright adapter in an afternoon, wire it into the existing GitHub Actions pipeline, and publish the static report as a workflow artefact. Paste the report URL into a Slack message using a post-job step. No licence cost, immediate visibility improvement, and the manager can filter by label or suite without asking the team to decode JSON.allure-results artefacts in Azure Blob Storage between runs so the trend graph survives pipeline resets. If the team also needs built-in flakiness scoring and ML-assisted triage, that is the point I would seriously price ReportPortal's self-hosted option against TestOps.The bottom line: Allure earns its place the moment your test results need to be read by someone who did not write the tests. Start free, add history persistence early, and only consider a paid platform once you hit the scale where manual trend analysis takes longer than fixing actual bugs.
Interview questions
Questions you are likely to get if you list Allure on your CV — with what interviewers are really testing for.
What is Allure Report, and how does it differ from the built-in HTML report you get from Playwright or Jest?
What they’re really testing: Whether you understand what problem a reporting layer solves beyond raw pass/fail output, rather than just knowing Allure exists.
Strong answer covers: Allure aggregates results across multiple test runners into a single structured HTML report; it adds trend history, severity labels, and attachment support that default reporters lack; the report is static HTML so it can be hosted anywhere (GitHub Pages, Azure Static Web Apps) without a running server — a practical detail for NZ government projects where infrastructure is locked down.
When would you choose Allure Report over a paid platform like Allure TestOps or ReportPortal?
What they’re really testing: Whether you can make a cost-vs-value judgement rather than always defaulting to the free tool or the most expensive one.
Strong answer covers: Allure Report (free) is sufficient when history can be persisted via artefact storage and the team is small; paid platforms earn their cost at 500+ tests where ML-assisted flakiness scoring, user management, and persistent dashboards save more time than the licence costs; in NZ public-sector engagements, data sovereignty requirements may rule out SaaS options and push the decision toward self-hosted ReportPortal.
You’re a QA engineer at a NZ financial services company running 800 Playwright tests in GitHub Actions. Allure reports generate fine locally but the history trend graph is flat in CI — every run shows as “run 1”. How do you fix this?
What they’re really testing: Whether you understand the Allure history mechanism and how CI ephemerality breaks it — a gap many candidates who’ve only used Allure locally will hit.
Strong answer covers: Allure history requires the history/ folder from the previous report to be present in the results directory before the new report generates; in ephemeral CI runners the workspace is wiped each run; fix by downloading the history/ folder from the previous run’s artefact at the start of the pipeline, then re-uploading the updated report as a new artefact; for a financial services team this also satisfies evidence-retention expectations under NZISM and internal audit requirements.
Your Allure report shows 12 tests failing, but the engineers say all those scenarios pass on their machines. How do you investigate?
What they’re really testing: Methodical debugging instinct and whether you use the report itself as a diagnostic tool rather than jumping straight to “it works on my machine.”
Strong answer covers: Open the Allure report and check the Categories tab to see if failures cluster under “Product defects” or “Test defects”; inspect the attached screenshots, video, and trace for each failure; check the Timeline tab to see if failures correlate with a specific parallel worker or time window; compare the environment section (Allure environment.properties) to confirm the CI environment differs from local — common causes include base URL, test data state, or timing differences in NZ-hosted staging environments.
How would you structure Allure labels and suites on a project with 600 tests spread across API, UI, and performance layers?
What they’re really testing: Whether you think about report usability for non-technical stakeholders and can design a labelling strategy rather than leaving tests in a flat list.
Strong answer covers: Use @allure.label or decorator equivalents to tag each test with layer (API/UI/performance), feature (e.g. payments, onboarding), and severity (critical/normal/minor); map suites to product areas so a product owner at a NZ SaaS company can filter to just their feature without understanding the folder structure; reserve the “owner” label for tests tied to a specific squad so the right team gets notified when their tests regress; document the labelling convention in a team decision record so it stays consistent as the suite grows.