Every QA session produces findings. What teams do with those findings — how they document, communicate, and track them — is the difference between bugs that get fixed and bugs that get shipped.

This guide gives you a practical QA report template for visual testing sessions, explains what each section should contain, and shows how to generate a shareable PDF report that engineers and clients can actually use.

What a QA Report Should Include

A QA report is a structured record of what was tested, what was found, and what the recommendation is before release. For visual testing specifically, it needs to capture:

Session metadata — what release or build was tested, who ran the test, when, and on what platform
Scope — which screens, flows, or components were reviewed
Findings — a list of issues found, each with a screenshot, description, and severity
Pass/fail status — which areas passed review and which have open issues
Recommendation — ship, ship with known issues, or block

Without all five sections, the report doesn't function as a handoff document. A list of screenshots without context isn't a report — it's a folder.

Visual QA Report Template

Here's a complete template you can use directly or adapt for your team.

Visual QA Report

Project: [Project or product name] Build / Version: [Build number, branch, or release tag] Environment: [Staging / Production / Preview URL] Tester: [Your name] Date: [Date of testing session] Platform tested: [macOS / Windows / iOS / Android — include browser + version for web]

Scope

List exactly what was reviewed in this session. Be specific — "the whole app" is not useful. Good examples:

Checkout flow (cart → shipping → confirmation)
Dark mode across all five primary screens
Mobile viewport (375px) for the onboarding sequence
New pricing page — layout, typography, and CTA button states

Summary

| | Count | |---|---| | Screens reviewed | — | | Issues found | — | | Critical | — | | Major | — | | Minor | — | | Passed without issues | — |

Findings

For each issue found, include:

Issue #1

Screen: [Which screen or component]
Severity: Critical / Major / Minor
Description: [What's wrong — be specific about what was expected vs. what was found]
Screenshot: [Annotated screenshot with pin at exact location]
Viewport / Platform: [Where this was observed]
Ticket: [Link to Jira or ClickUp ticket if created]

Repeat for each issue. Number them sequentially.

Passed Screens

List screens that were reviewed and passed without issues. This is as important as the findings — it tells stakeholders which areas were verified and gives confidence in what is ready to ship.

Recommendation

One of three outcomes:

Ship — no blocking issues found, all reviewed areas pass
Ship with known issues — minor issues noted but none are release blockers; linked tickets are non-critical
Block — critical or major issues found that must be resolved before release

What Makes a Good Visual Bug Report

The findings section is where most QA reports fall apart. "Button looks off" is not a useful bug report. "The primary CTA button on the pricing page has 12px left padding instead of 16px at 375px viewport — see pin #1 in screenshot" is.

Every finding needs four things:

1. An annotated screenshot. The engineer fixing the bug should be able to open your report and immediately see exactly what you're pointing at. A numbered pin dropped at the precise location — not a full-page screenshot with a vague arrow — saves a full back-and-forth cycle. See our guide on how to report UI bugs in Jira with screenshots for the exact annotation format that works.

2. Expected vs. actual. "The header background should be #1A1A2E in dark mode. It's currently inheriting #FFFFFF from the light theme." One sentence. Clear and actionable.

3. Viewport and platform. Visual bugs are often environment-specific. "Observed on Windows Chrome 121, 1440×900 viewport" tells the engineer exactly where to reproduce it.

4. Severity. Use a consistent three-level system: Critical (blocks release), Major (must fix before launch), Minor (fix in next cycle). Don't overuse Critical — it dilutes the signal.

How to Generate the PDF Report

The bottleneck in visual QA reporting isn't finding bugs — it's assembling the report. Manually copying screenshots into a document, adding annotations in PowerPoint, writing descriptions, then exporting as PDF: this takes 30–60 minutes on a typical session, and most teams skip it entirely as a result.

Captur generates this report for you.

Here's the workflow:

Capture screenshots as you review — they land in your project Space automatically
Annotate each screenshot with numbered pins and comments at the exact issue location
Group the screenshots into a named Visual Review — this becomes your report session
Export as a PDF report — annotated screenshots, comments, and session metadata export in one click

The output is a structured PDF you can email to a client, attach to a release ticket, or add to a Confluence page. The formatting is handled — you spend time on the QA, not the document.

When to Send a QA Report

Not every testing session needs a formal PDF report. Here's a practical guide:

Always send a report:

Pre-release review on any client-facing product
Any build going to a client for sign-off
Major feature releases on products with design specifications
Regression testing sessions before a significant version bump

A Jira/ClickUp ticket per bug is sufficient:

Routine sprint testing with no external stakeholders
Internal builds between team members
Quick smoke tests on minor releases

No formal documentation needed:

Exploratory testing during active development
Quick "does this look right" checks between designer and developer

The rule of thumb: if someone outside your immediate team needs to understand what was tested and what was found, send a report.

QA Report Checklist

Before sending:

[ ] Build / version number is recorded
[ ] Scope is clearly defined — no ambiguity about what was and wasn't reviewed
[ ] Every finding has an annotated screenshot
[ ] Every finding has expected vs. actual description
[ ] Viewport and platform is noted for each finding
[ ] Severity is assigned consistently
[ ] Passed screens are listed (not just findings)
[ ] Recommendation (ship / ship with issues / block) is explicit
[ ] All findings are logged in Jira or ClickUp with screenshots attached

Building the Reporting Habit

The teams that consistently ship polished UIs aren't doing more QA work than everyone else — they have a faster reporting workflow, so the overhead doesn't become a reason to skip the process.

A QA report that takes 5 minutes to generate gets done before every release. One that takes an hour gets skipped.

Captur is built around this: capture, annotate, and export a shareable PDF report from a single interface, without assembling a document manually.

For the full visual QA workflow that feeds into these reports, see how to do visual QA before every release.

View Captur pricing →

QA Report Template: How to Document a Visual Testing Session