A bug report is useful when another person can repeat the problem without having to reconstruct your afternoon. “The form is broken” describes frustration, but it does not identify a particular failure. A short, well-structured note can turn that complaint into a testable observation. The goal is to preserve the conditions, the action, and the result while keeping guesses about the cause separate.

This walkthrough uses an invented contact form that accepts a name and message. The form and results below are fictional examples, not claims about a fault in BiNotePads. You can adapt the structure in a browser note, then transfer the finished report into your team's issue tracker. The tracker remains the place for assignment and status if that is how your team works.

Define one observable failure

Start with the narrowest description that distinguishes this problem from other problems. “Contact form clears the message after a rejected email address” is more useful than “Contact form error.” It tells the reader which action loses information. Do not include the presumed implementation cause in the title unless it has actually been established.

Record the page or screen, the application version if it is available, and the browser version you used. Include whether you were signed in and whether the problem happened in a new or existing draft. These details are conditions for reproduction, not a request to copy account identifiers, private messages, or browser diagnostics into a public report.

Keep the smallest useful sample

Use invented values that reproduce the behavior. In this example the name is “Example Reader,” the email is “reader-at-example,” and the message is “Please send the opening hours.” The invalid email is deliberate. A real customer's details would make the report harder to share without helping the test.

Remove optional fields one at a time while checking that the behavior still occurs. If deleting an attachment makes the failure disappear, mention the attachment's relevant type and size using a harmless substitute. Do not say that every attachment fails if you tried only one. A minimal sample narrows the investigation; it does not prove the underlying cause.

Write steps that start before the problem

A reader needs a known starting point. “Press Send again” leaves too much unstated. Use numbered actions and include any setup that changes the result. Keep the observed behavior out of the action steps so a tester can follow them without assuming the outcome.

test page: fictional contact form
starting state: signed out; empty form
1. Open the contact form.
2. Enter Example Reader in Name.
3. Enter reader-at-example in Email.
4. Enter Please send the opening hours in Message.
5. Select Send once.

If the problem requires refreshing the page or waiting for a particular event, describe that condition. Avoid arbitrary instructions such as “click around for a while.” If you cannot yet identify the necessary action, record what you know and label the missing condition as unresolved.

Compare expected and observed results

State both results in separate sentences. Expected: the form rejects the invalid email and keeps the message available for correction. Observed in the fictional example: an email warning appears, but the message field becomes empty. This comparison explains the user impact without exaggerating the severity.

Add a frequency statement only when you have a basis for it. “Observed in two attempts using the sample above” is different from “always happens.” If a colleague cannot reproduce the issue, keep both records. Differences in account state, browser version, or input can be useful evidence rather than reasons to erase the original observation.

Separate evidence, hypotheses, and requests

Evidence might be a redacted screenshot showing the warning and empty field. A hypothesis might be that the form resets all fields after validation. Label the second statement as a hypothesis. It should not silently become the ticket's accepted explanation.

The request can stay practical: preserve the message when rejecting the email, and add a test for that path. Assigning a cause or prescribing a code change is unnecessary when you have only observed the interface. Include the report date and a contact route your team already uses so follow-up questions have somewhere to go.

Retest without rewriting history

When a fix is available, repeat the original steps with the original harmless sample. Record the version and retest date, then say which result changed. If the message now remains but an attachment disappears, that may be a separate failure rather than a reason to mark the entire workflow successful.

Keep the first observation and append the retest. Replacing the original result with the fixed behavior destroys context. A useful closing note reads “Original steps passed on version X; message retained after invalid email warning.” That is enough to connect the fix to the evidence without claiming that every possible form path has been tested.

Before sending the report

Read the steps as if you had not seen the failure. Check that the title identifies one problem, all sample values are safe, and the expected result reflects an actual requirement or a clearly stated expectation. Export or copy the final report into the agreed issue system. A browser note is a convenient drafting surface; it is not automatically a shared ticket or a complete test record.

Use the BiNotePads online notepad to adapt this example. For a separate copy of important work, follow the browser-note backup guide.