Bug report template for websites

The template

Copy these fields into your feedback tool, or use a tool that captures the environment automatically.

• URL: where does it happen?
• Element: which element exactly?
• Steps: 1. … 2. … 3. …
• Expected: what should happen?
• Actual: what happens instead?
• Environment: browser, operating system, resolution

A filled-in example

Here is what the template looks like in practice instead of staying blank:

• URL: /cart
• Element: “Checkout” button
• Steps: 1. Add product to cart 2. Open cart 3. Click “Checkout”
• Expected: redirect to the checkout page
• Actual: page reloads and stays on the cart
• Environment: Safari 17, iOS 17.4, iPhone 13

Why the environment decides everything

A large share of reports is environment-specific. Without browser and resolution your team tests in the wrong place and sends the report back as not reproducible.

Automatic instead of manual

Nobody should have to type environment, URL and element. nootiz captures them automatically when the note is created, which reduces the template to three free fields: steps, expected, actual.

How detailed do reproduction steps need to be?

Detailed enough that a person who has never seen the page can recreate the bug. A step like “fill in the form” is not enough – name the actual inputs.

Rating severity

Add a rough severity level so your team knows what to tackle first:

• Blocker: core function (e.g. purchase, login) does not work
• High: function limited, workaround exists
• Low: cosmetic issue with no loss of function

One bug per report

Even when two issues seem related: one report per bug allows separate prioritisation and separate status.

Common mistakes when filling in the template

These are the most frequent issues that make a report unusable:

• Expected behaviour is missing entirely
• Steps are phrased too generically
• Environment gets asked about afterwards instead of captured immediately
• Multiple bugs end up in a single report

Screenshots vs. live context

A screenshot shows a single moment but not the interaction before it. A note left directly on the element on the live page also shows state and environment at the same instant.

From report to task

A bug report only becomes useful once it lands in the development team's tool. Notes that can be handed over to Jira, GitHub, Trello or Asana skip the manual retyping step.

Who fills in which field?

Reporters provide URL, element, steps, expected and actual. Environment should be captured automatically, not typed. Severity is best set by development or QA, since they know the technical context — the reporter only flags how much it blocks their own work.

What if the template's fields contradict each other?

If “expected” and “actual” read the same, the field was misunderstood. Ask directly: “what would you have seen instead?” — the contradiction usually resolves once someone names the target behaviour explicitly.

Using the template in a distributed team

In asynchronous work, the template has to stand on its own without a follow-up question. Always add a timestamp and, if relevant, the reporter's time zone, so “just happened” stays meaningful later.

Closing out a report

Only mark a report resolved once the fix is live in the relevant deployment and the reporter has confirmed the behaviour now matches what was expected. A status of “in progress” without a follow-up date otherwise stays open indefinitely.

Using the template without a tool

The six fields work just as well in a shared spreadsheet or a plain document. The only difference from a dedicated tool is that environment and screenshots have to be added manually there.