How to Dictate a Bug Report Someone Can Reproduce

"It broke again" is an honest report. It is also a hard one to fix. By the time you open the issue tracker, the exact screen, button and result have blurred together. Dictating a bug report can preserve those details while they are fresh, but only if you give the speech a shape before you start.

This is a short workflow for turning an observed failure into a report another person can reproduce. It works whether you are testing a side project, filing an issue at work or helping maintain an open-source tool. You will still need to type exact commands and check the final report. Voice is for the account of what happened, not for inventing evidence.

Start with the failure, not a diagnosis

Bug reports go sideways when the title announces a theory: "The database cache is broken." You may be right, but the person investigating needs the observation first. A better title names the action and result: "Saving a draft clears the selected language in Settings." That can be tested without accepting your theory about the cause.

The same rule helps when you dictate. Say one sentence about the task you were trying to finish, then one sentence about what the software did instead. Do not begin with a long history of your week or a guess about which subsystem failed. If the issue is intermittent, say so. If it happens every time on your machine, say that too, but do not claim it happens to everyone.

GitHub's guide to creating an issue describes entering a descriptive title and body, and notes that a repository may provide an issue template. Use that template when one exists. The spoken structure below helps you gather facts before you fill its fields; it is not a reason to ignore the project's own instructions.

The five-field voice note

Open a blank private draft rather than filing straight into a public issue tracker. Click into the editor and dictate five short fields. Use a fresh line between them. Your first pass should sound like a witness account, not a polished release note:

1. Context: What were you trying to do? Name the page, feature or operation.
2. Steps: What actions produced the failure? Number them in order.
3. Expected: What result did you reasonably expect?
4. Actual: What happened on screen? Quote a short error only after checking it.
5. Scope: When did it happen, on what environment, and can you repeat it?

Here is a copy-paste template. Replace every bracket with an observed detail. If a field is unknown, write "not checked" instead of filling it with a plausible answer.

Title: [action] causes [observed result]
Context: I was trying to [goal] in [feature/page].
Steps to reproduce:
1. [exact starting state]
2. [first action]
3. [next action]
Expected: [what should have happened]
Actual: [what happened, including checked error text]
Frequency: [once / sometimes / every attempt on this device]
Environment: [app version, OS, browser if relevant]
Evidence: [safe screenshot or sanitized log, if useful]

Do not read the square brackets aloud and expect them to become structured markup. Put the headings in your editor first, then speak into each field. If you use a desktop voice keyboard such as Talkpad on macOS or Windows, put the cursor in your private draft and dictate one field at a time. That makes it easier to stop, inspect and correct each piece before posting.

Reproduce once, then narrate the clicks

Memory turns a sequence into a summary. "I changed a setting and the page crashed" might leave out the refresh, the account switch or the unsaved form. Repeat the sequence if it is safe, with the draft open beside the affected app. Pause after each action and record what you did. Do not repeatedly trigger a bug that deletes data or charges money just to improve the wording.

Keep steps literal: "Open Settings, choose Spanish, click Save, reopen Settings." Avoid "go into the usual preferences and do the thing." If your app has several Save buttons, name the panel. If the bug appears only after a reload, include the reload. A colleague who has never seen your screen should be able to perform the steps without messaging you for the missing click.

You can dictate the narrative, but use the keyboard for fragile strings. A model may turn a package name into common words, alter capitalization in a flag or smooth away a minus sign. Paste a checked stack trace or error from the app rather than speaking it. The same goes for a precise version such as 1.4.12. See our guide to names and technical terms for less risky words that still need careful review.

Separate expected from actual

This is where a report becomes useful. "The form failed" tells the investigator almost nothing. "After I clicked Save, the confirmation appeared, but the language reverted to English when I reopened Settings" describes an observable mismatch. The expected result can be just as plain: "The saved language should still be Spanish when I reopen Settings."

Do not smuggle a proposed fix into the expected field. "The app should use a different cache" is an implementation suggestion, not a user-visible expectation. Put any hypothesis in a clearly marked note at the end, with uncertainty intact. Your colleague may find that the cause is an API response, a stale client or something else entirely.

When speech recognition gets a negation wrong, the report can reverse its own meaning. Compare "the dialog did not close" with "the dialog closed." Read those sentences back on screen before filing. Our risk-first proofreading method puts negations, numbers and names ahead of stylistic edits for this reason.

Add environment without making a forensic dossier

The smallest useful environment is usually the app version, operating system, browser if the bug occurs in a browser, and any feature setting needed to reproduce it. Note whether you can reproduce it in a clean session or another device only if you actually tested. A timestamp or network condition matters when it changes the outcome; otherwise it adds noise.

Inspect a screenshot before attaching it. User names, email addresses, tokens, customer records and chat previews can hide in the corners. Crop to the relevant area or blur sensitive details using a trusted editor. Logs deserve the same review. If an issue tracker is public, assume the attachment will be public too. For workplace policy questions, use our voice typing privacy checklist before dictating confidential material into any tool.

Talkpad can put a spoken draft into the app where your cursor sits, but it does not verify that a screenshot is safe or that a stack trace is correct. Those are your checks. If company policy restricts speech processing for incident data, follow the policy and write the sensitive parts manually.

A two-pass edit before you file

Pass one is for reproducibility. Start at the listed state and follow your steps literally. Does the failure appear? Are expected and actual results different and legible? Did you leave out a sign-in step or a setting that changes the outcome? If you cannot reproduce it again, change the frequency field to reflect that instead of hiding the uncertainty.

Pass two is for risk. Check version strings and error text against their sources. Remove secrets from the body and attachments. Replace speculation with observable facts, or label it as a hypothesis. Shorten the introduction if it delays the steps. You can use the dictated-draft editing toolkit when the first pass arrives as a block of speech rather than clean fields.

A useful report need not be long. Some bugs take three steps and two sentences; others need a controlled example. Resist padding. The goal is for someone else to reproduce the behavior and understand why you expected something different. If you cannot explain the starting state, investigate a little more before publishing.

Frequently asked questions

Can I use dictation to write a bug report?

Yes. Dictate the context, reproduction steps and expected versus actual behavior into a private draft. Type and verify exact commands, error messages, URLs and version numbers before sharing it.

What should a bug report include?

Include a descriptive title, starting context, ordered steps, expected result, actual result, relevant environment and safe evidence if needed. Follow the repository's issue template when it provides one.

How do I report a bug I cannot reproduce?

State that it happened once or intermittently, record what you observed and the environment you know, and say which attempts failed to reproduce it. Do not fill unknown steps with guesses.

Should I attach logs to a public issue?

Only after checking them for secrets and personal information. Remove or redact sensitive data and share the smallest excerpt that helps explain the failure. Follow your team's incident and privacy rules.

Download Talkpad for free – 2,500 words/week on the free plan.