The Allure report is not just one page — it has multiple sections, each designed for a different audience and purpose. Knowing which section to check for what saves you time. Let us walk through each one.
This is the landing page. It shows the big picture: total tests, pass/fail percentages as a donut chart, trend charts over previous builds, and environment info. This is the page you share in standup. "85% pass rate, 3 blockers, down from 5 yesterday." That is all your manager needs.
Tests organized by Java package and class name. This is the "developer view". Click a class to expand it, see individual tests, and their status. Use this when you want to know "Which test class has failures?"
Tests organized by @Epic > @Feature > @Story. This is the "business view". Stakeholders can navigate: Banking Portal > Fund Transfer > Valid Transfer. Use this when a manager asks "Is the fund transfer feature stable?" You navigate to that node and show the results.
Visual charts: status distribution (how many passed/failed/broken), severity distribution (how many BLOCKER vs NORMAL), duration chart (which tests take the longest), and trend history. Use this to spot patterns: "Most failures are in CRITICAL tests", "These 5 tests take 80% of the execution time".
Shows a Gantt-style chart of when each test started and finished. Essential for parallel execution debugging. If two tests are accessing the same data and one is failing intermittently, the Timeline shows if they were running at the same time — which means they are stepping on each other.
Groups failures into categories like "Product Defects" (real application bugs) and "Test Defects" (broken tests). You can define custom categories. This answers the question: "How many failures are actual bugs vs broken test code?"
Shows tests that were retried. If a test failed on the first attempt and passed on the second, it appears here flagged as "flaky". This section is gold for identifying unstable tests. Review it weekly.
| Section | Content | Why It Helps |
|---|---|---|
| Description | Text from @Description | Understand what the test was verifying |
| Steps | Nested @Step trace | See exactly which action failed |
| Attachments | Screenshot, URL, page source, logs | Visual proof of the failure state |
| Error | Assertion message + stack trace | Technical details for the developer |
| Parameters | Data-driven test input values | Which specific data caused the failure |
| History | Pass/fail over previous builds | Is this a new failure or a recurring one? |
| Links | @Issue, @TmsLink, @Link | Jump to JIRA ticket or test case spec |
Bookmark these shortcuts: Behaviors tab for stakeholder meetings, Suites tab for developer debugging, Categories tab for triage meetings, Retries tab for weekly flaky test reviews, Graphs tab for trend analysis in retrospectives.
Q: How do you read an Allure report? Which sections do you use?
A: The Overview dashboard gives me the pass/fail summary — I share this in standup. The Behaviors tab organizes tests by Epic/Feature/Story — I use this when stakeholders ask about specific feature coverage. The Suites tab shows results by Java class — I use this to quickly identify which test class has failures. When I click a failed test, I see the step-by-step trace, screenshot, page URL, and error message. The Categories tab helps me triage — separating real application bugs from broken test code. The Retries tab identifies flaky tests. The Timeline view helps debug parallel execution issues.
Key Point: Each Allure tab serves a different audience. Overview for managers, Behaviors for stakeholders, Suites for developers, Categories for triage, Retries for stability reviews.