Selenium · Browser automation foundations
How do you report Selenium test results effectively?
Short answer
Use a reporter such as Allure or Extent to show pass and fail status, steps, timings, environment details and failure attachments. Attach screenshots, logs and request details so a failure can be diagnosed without rerunning locally.
A report is for the person triaging a failure, not just for a green dashboard. It should answer what ran, what failed, on which browser, at which step, and what the application looked like at that moment.
@Attachment(value = "failure screenshot", type = "image/png")
public byte[] screenshot() {
return ((TakesScreenshot) driver).getScreenshotAs(OutputType.BYTES);
}
@Step("Sign in as {0}")
public void signIn(String email) {
loginPage.enterEmail(email);
loginPage.submit();
}
Allure.addAttachment("page url", driver.getCurrentUrl());- Group results by suite, feature and browser so patterns are visible
- Record environment details such as browser version, OS and grid node
- Attach screenshots, console logs and API payloads on failure
- Keep step names at the user-intent level, not at the click level
- Publish reports as CI artifacts with a retention policy
- Track duration trends to catch slow tests before they become timeouts
Too much reporting is also a problem. Attaching a screenshot and full DOM on every step creates huge artifacts and slows the run. Capture detailed evidence on failure, and keep successful runs lightweight.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What should a failure report include?
- 2Why avoid attaching screenshots on every step?
- 3How do you make report steps useful?
- 4What reporting risks exist with personal data?
Say it in the interview
I use Allure or Extent to show status, steps, timings, environment and attachments. On failure I attach a screenshot, the URL, browser logs and relevant request details so someone can triage without reproducing locally. Steps are named after user intent rather than individual clicks. I keep successful runs lightweight and restrict artifact access because screenshots and payloads can contain personal data.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Selenium mock interview and get scored feedback on depth, clarity and confidence.