CI/CD & tooling
Allure
Test reporting aimed at the people who did not run the tests.
Allure in practice
A reporting framework that collects structured results from a test run and renders them as a browsable report: outcomes grouped by feature and severity, each test expandable to its steps, with screenshots, request logs and stack traces attached at the point of failure. It integrates with most runners across several languages, so a mixed estate of browser, API and unit suites can publish into a single format instead of four different console outputs nobody outside the team can read.
It is the artefact that makes an automation engagement legible to the client. A pipeline log answers whether the run passed; a report answers which business flow broke, on which browser, with what on screen at the moment it happened — and it answers that for a project manager without anybody translating. We also use the historical view to argue about flakiness with evidence, since a test that has failed intermittently for three weeks is visible in a trend line and deniable in a console.
History requires somewhere to keep it. The trend and flakiness views depend on previous results being carried between runs, and a pipeline that publishes a fresh report each time silently loses the most valuable half of the tool.
Rich reports are only as good as the instrumentation. Steps, attachments and severity labels have to be added deliberately in the suite; without that effort the output is a prettier pass-fail list.
It reports, and nothing more. It does not run tests, gate merges or notify anybody, so it sits alongside the pipeline’s own signalling rather than replacing it.
Publishing and hosting is left to you. Making the report reachable by a client — with access control, if the content warrants it — is a small infrastructure task that has to be owned.
The generated site is a static bundle that grows with attachments, and a suite that screenshots liberally produces reports large enough to be worth a retention policy.
FAQ
Allure questions we hear often
Is a report worth the setup on a small suite?
Rarely, at first. Under a hundred tests run by the people who wrote them, the console is adequate and the instrumentation effort is not repaid. It starts to matter when somebody outside the team needs to understand a failure without asking — which usually arrives at the same moment as the first monthly report to a client, and is easier to set up before that than during it.
What should be attached to a failing test?
Enough to diagnose without rerunning: a screenshot at the point of failure, the page state or response body, and the request and response for the call that mattered. Attaching everything on every test is the common overcorrection — it inflates the report, slows publishing, and buries the two artefacts somebody actually needed among fifty they did not.
Can it show whether a test is flaky?
With history retained, yes, and this is the strongest argument for keeping it. The retry and history views distinguish a test that fails consistently from one that fails one run in six, and that distinction is the whole basis of a quarantine decision. Without persisted history the tool cannot make that call, and neither, in practice, can the team.
Contact
Wondering if this is the right tool?
Describe what you are trying to verify and we will tell you which instrument fits, including when the answer is one we do not use.