Bug Report Template: Screenshots, Recordings, and Steps to Reproduce

A useful bug report gives someone enough information to investigate a problem without reconstructing the conversation that led to it.

Include the affected feature, steps to reproduce, expected result, actual result, environment, and evidence. Add the observed impact and anything you have not yet confirmed.

The template below works for website projects, client portals, and small software teams. Use the short version to capture a report quickly, then expand it when the investigation needs more detail.

Copy-paste bug report template

[Short title describing the problem and its trigger]

Report ID: [Optional reference, such as BUG-014]
Reported by: [Name or team]
Date and time observed: [Include timezone when relevant]
Website, app, or project: [Name]
Affected page or feature: [Page, screen, or feature]
Environment: [Production / Staging / Local]
App version or build: [Version, release, or Unknown]

Summary

[One or two sentences describing the observed problem.]

Steps to reproduce

Starting conditions: [Required account role, settings, existing data, or previous action]

1. [Start from a specific page or screen.]
2. [Perform one action.]
3. [Perform the next action.]
4. [Describe where the problem appears.]

Expected result

[What should happen, based on the agreed requirement or normal behavior?]

Actual result

[What happened instead? Include exact error text if there is any.]

Frequency and scope

Reproduction frequency: [For example, 3 out of 3 attempts, Intermittent, or Not yet reproduced]

Observed affected users or accounts: [What you have actually confirmed]

Other environments checked: [Device, browser, account, or Not checked]

Device and browser details

Device: [Model or device type]
Operating system: [Name and version]
Browser or app: [Name and version]
Screen size or orientation: [If relevant]
Account role: [If relevant]
Network conditions: [If relevant or Unknown]

Evidence

Screenshot: [File name or reference]
Recording: [File name and relevant timestamp]
Error message: [Exact text or None shown]
Relevant logs: [Sanitized excerpt or reference, if available]

Impact and triage

User impact: [What the person cannot do, or what goes wrong]

Workaround: [Confirmed workaround or None confirmed]

Severity: [Proposed impact level and reason]

Priority: [Decision about when to address it, or Awaiting triage]

Owner: [Person responsible for the next action]

Investigation and resolution

Known facts: [Confirmed observations]

Open questions: [What still needs checking]

Next action: [Specific investigation step]

Resolution: [Complete after investigation or implementation]

Retest result: [Complete after testing]

Status: [Reported / Investigating / Ready for retest / Closed / Reopened]

You do not need to fill every field before reporting an issue. Use “Unknown” or “Not checked” where appropriate.

Missing information is easier to handle when it is visible.

A shorter bug report for quick capture

Use this when you need to record the issue before returning to your work.

Title: [Problem + trigger]

Where: [Page or feature]

Steps: [The shortest sequence you know]

Expected: [What should happen]

Actual: [What happened]

Environment: [Device, browser, and app version if known]

Evidence: [Screenshot or recording]

Impact: [What this prevents or disrupts]

Still unknown: [What needs confirmation]

A short, accurate report is useful. A long report filled with guesses is harder to investigate.

Filled bug report example

This is a fictional example for a client website. It illustrates the reporting format rather than describing a bug in SelfManager.

Portfolio filter shows the previous category after changing selection

Report ID: BUG-014
Reported by: Project reviewer
Affected feature: Portfolio category filter
Environment: Staging
App version or build: Not yet recorded

Summary

Changing the portfolio filter from Web to Branding updates the selected label, but the visible project cards continue to show the Web results.

Steps to reproduce

Starting conditions: Open the staging portfolio page in a desktop browser.

1. Select Web in the category filter.
2. Wait for the project cards to update.
3. Select Branding.
4. Compare the selected filter with the visible project cards.

Expected result

The selected filter shows Branding, and the project cards match the Branding category.

Actual result

The filter shows Branding, but the cards continue to show the Web selection.

No error message appears.

Frequency and scope

Reproduction frequency: 3 out of 3 attempts in the reported environment.

Observed scope: One desktop browser session.

Other environments checked: None.

Environment details

Browser: Chrome; exact version not yet supplied.
Operating system: macOS; exact version not yet supplied.
Account role: Public visitor.

Evidence

Screenshot: portfolio-branding-selected-web-results.png

Recording: portfolio-filter-category-change.mp4

Relevant moment: Around 00:12, after selecting Branding.

Impact and triage

User impact: A visitor may see the wrong project examples for the selected category.

Workaround: None confirmed.

Severity: Moderate under this project’s proposed scale because a browsing feature gives incorrect results.

Priority: Awaiting project-lead review.

Owner: Developer.

Next action

Reproduce the category change, record the affected build, and check whether the displayed results match the selected category.

The report distinguishes what was observed from what remains unknown. It does not claim the issue affects every browser or identify a cause before investigation.

How to write useful reproduction steps

Start from a state another person can reach.

“Change the filter” leaves several questions unanswered. Which page? Which original selection? Which new selection?

“On the portfolio page, select Web, wait for the cards to update, then select Branding” gives the investigator a sequence to follow.

Use one action per numbered step where possible. Include starting conditions that could change the result, such as:

• An account with a particular role.
• An existing item with saved data.
• A specific setting.
• A previous upload or selection.
• Returning to a page after signing in.

If you cannot reproduce the issue, report that honestly. Record what happened before it appeared and what you tried afterward.

Do not turn “it happened once” into “it always happens.”

Expected and actual results belong in separate fields

These two fields are the center of the report.

Expected result describes the agreed behavior.

Actual result describes the observation.

For example:

Expected: Selecting Branding displays Branding projects.

Actual: The selected label changes, but the previous Web projects remain visible.

Avoid “the filter is broken” as the entire actual result. It communicates frustration without identifying the mismatch.

If the expected behavior is unclear, flag the requirement for clarification. Some reports reveal an undefined decision rather than an implementation defect.

Screenshots or recordings: which should you attach?

Choose evidence that helps someone understand the problem.

A screenshot captures a state. A recording shows how you reached it.

Neither replaces written steps. A developer or reviewer should be able to understand the report without watching a long recording from the beginning.

For video evidence, add a brief description and timestamp:

“00:12: Branding becomes selected, but the Web cards remain.”

Keep unrelated windows, passwords, customer details, and private messages out of the evidence you share.

Severity and priority are different decisions

Severity describes the impact. Priority describes when the work should be addressed.

A small project can use a simple severity scale:

• Critical: A core workflow is unavailable or confirmed data loss is occurring.
• High: An important function fails with no reasonable workaround.
• Moderate: A function behaves incorrectly, but other work can continue.
• Low: A minor issue has limited effect on the task.

These are suggested definitions. Agree on the scale for your project.

Then decide priority using context: affected users, deadlines, dependencies, available workarounds, and competing problems.

The person reporting the issue can describe the impact. The person coordinating the work can decide its place in the schedule.

Avoid marking every report urgent. Explain the consequence that justifies its position.

Keep the report and evidence together in SelfManager.ai

SelfManager organizes work in dated tables with tasks, notes, and comments. For a small project, a practical setup is a table named “BUG-014: portfolio filter” on the date the issue was reported.

Use the template as a manual reporting structure:

• Put the full report in the table’s notes.
• Add tasks for investigation, implementation, and retesting.
• Record follow-up observations in comments.
• Keep screenshots and recordings on the same table.

The template’s severity, priority, and triage status fields are written labels. They do not imply that every field exists as a dedicated SelfManager column.

Attach the recording beside the investigation

SelfManager’s Video section supports uploads up to 2 GB per video, in-app playback, and original-file downloads.

Uploading requires a paid plan or lifetime deal on the table owner’s account. Videos share the document allowance: 5 GB on Individual and 25 GB on Team.

Name the recording with the report ID so it remains recognizable.

If you are evaluating SelfManager, use the seven-day trial to try the dated reporting workflow. Video uploads require the paid entitlement described above.

SelfManager can suit a freelancer or small team keeping investigation context together. For dedicated issue tracking with engineering workflows and release automation, evaluate a specialist system.

Retest before closing the report

After a proposed fix, repeat the original reproduction steps.

Record:

• The build or environment tested.
• Whether the original mismatch still occurs.
• The result of any closely related checks.
• Who tested it and when.
• Any remaining limitation.

For the fictional filter bug, confirm the transition from Web to Branding, then check the reverse transition and the unfiltered view.

Write a concrete result:

“Retested on staging build [identifier]. Web → Branding and Branding → Web display the matching project cards. Unfiltered view also checked.”

If the failure remains, reopen the report with the new evidence.

“Code changed” and “problem verified as resolved” are separate milestones.

Before you submit the report

Check that someone unfamiliar with the issue can answer these questions:

1. Where does the problem happen?
2. What actions lead to it?
3. What should happen?
4. What happened instead?
5. What evidence supports the observation?
6. What remains unknown?
7. Who owns the next action?

Start with the information you have and improve the report as you investigate.

For small client projects, keeping the report, recording, decisions, and follow-up tasks in one SelfManager table can make the handover easier to follow.

Frequently asked questions

What should a bug report include?

Include a specific title, affected feature, reproduction steps, expected and actual results, environment, evidence, and observed impact. Add an owner and next action so the report can move forward.

Do I need a recording for every bug?

No. A screenshot may be enough for a static layout or text issue. Use a recording when the sequence or timing helps explain what happened.

What if I cannot reproduce the bug?

Record the original observation, starting conditions, time, environment, and attempts to reproduce it. Mark it intermittent or not yet reproduced rather than guessing the cause.

What is the difference between severity and priority?

Severity describes impact. Priority determines when to address the issue compared with other work. Record the reason behind each assessment.

Can I use this bug report template in SelfManager?

Yes. Keep the report in table notes, investigation actions as tasks, and updates in comments. Add relevant images or videos alongside the work, subject to the applicable upload and storage limits.