August 27th, 2026

Jira Bug Report Template With a Worked Browser Example

Copy a Jira bug report template and see a worked checkout example with the starting state, browser steps, expected result, and first mismatch.

Dwayne Samuels Co-founder & CEO, Samelogic

A useful Jira bug report lets a developer follow the same path and observe the same failure. It should answer five questions before the first comment arrives:

What starting state is required?
What exact actions produce the problem?
What should happen?
What actually happens, and where does it first diverge?
Which browser, build, account state, and supporting material belong to this run?

That is the short answer. The template below puts those answers in a stable order, followed by a worked browser-history example you can adapt.

What belongs in a Jira bug report

Atlassian describes its Jira bug tracking template as a structured place to capture, assign, prioritize, and move bugs through a dedicated workflow. Its guidance also points teams toward labels, custom fields, and attachments for added context. BrowserStack's practitioner guide recommends a title, environment, numbered reproduction steps, expected and actual results, visual proof, and severity or priority.

Those fields are necessary, but browser bugs often need one more thing: the state-changing action that connects the starting state to the failure. A screenshot can show the wrong total. It cannot show that the customer went Back, changed shipping, and then went Forward into a stale payment view.

Field	What to write	Why the receiver needs it
Summary	One observable failure, affected surface, and triggering condition	Makes the issue searchable and scannable
Starting state	Account, data, route, permissions, cart, feature flags, or prior action	Prevents a clean-page retry from testing a different situation
Environment	Build, browser and version, operating system, viewport or device, and URL	Separates workflow failures from environment-specific failures
Steps	Ordered actions with exact labels and state changes	Gives the developer an executable path
Expected	The result required after the final relevant action	Defines the acceptance boundary
Actual	The observed result plus the first mismatch	Points investigation at the earliest useful contradiction
Reproduction rate	Runs attempted and runs reproduced under the same setup	Distinguishes a deterministic condition from an intermittent one
Impact	User or workflow consequence without guessing the root cause	Supports triage without inflating severity
Attachments	Focused screenshot, short video, console or network detail, or captured browser path	Preserves context that prose cannot carry efficiently

Copyable Jira bug report template

Use the same field order across QA, support, and product. Keep implementation theories in a separate note unless you have verified them.

jira-bug-report-template.md

(Plain text)

## Summary
[Surface] does [actual behavior] after [triggering condition].

## Starting state
- Account or role:
- Required data or prior state:
- Starting URL or route:
- Build or release:

## Environment
- Browser and version:
- Operating system:
- Device or viewport:
- Relevant feature flag, locale, or network condition:

## Steps to reproduce
1. 
2. 
3. 

## Expected result

## Actual result

## First mismatch
[Name the earliest action or state where expected and actual diverge.]

## Reproduction rate
[Runs reproduced] of [runs attempted] with the same setup.

## Impact
[Describe the blocked user or team outcome.]

## Attachments
- Focused screenshot or video:
- Console or network detail:
- Captured browser path:

## Notes
[Verified facts only. Put unverified root-cause ideas here and label them as hypotheses.]

Worked browser example

Consider a synthetic checkout incident. Support reports that Express shipping is selected, but payment still shows the Standard total of $120. Engineering opens the Express checkout directly and sees the correct $135 total, so the bug appears to disappear.

The clean page and the customer report can both be accurate. The missing condition is browser history.

Disclosed experiment method

We built a local synthetic checkout fixture with a $110 subtotal, Standard shipping at $10, and Express shipping at $25. The fixture stores a payment snapshot when the payment view first opens. It creates no order, sends no commerce request, and uses only synthetic IDs.

A real headless Chrome run checked two paths:

Clean Express path: open Express payment directly. The live total and displayed payment snapshot are both $135. Validation passes.
History-dependent path: start on Standard at $120, continue to payment, go Back, change shipping to Express, then go Forward. The live total is $135, but payment restores the old $120 snapshot. Validation is blocked.

The failure is deterministic under that sequence. Calling it flaky would hide the condition that makes it reproducible.

Completed Jira fields

Summary

Browser Forward restores the Standard payment total after shipping changes to Express.

Starting state

Synthetic order ORD-7314 is on the cart.
Subtotal is $110.
Standard shipping is selected at $10.
Live total is $120.
No payment snapshot exists.

Environment

Current Chrome run against a local synthetic fixture
Desktop viewport
No external API, order, or payment request

Steps to reproduce

Open the cart with Standard shipping and a $120 live total.
Select Continue to payment and confirm the displayed payment total is $120.
Select Browser Back to cart.
Change shipping to Express and confirm the live total becomes $135.
Select Browser Forward to cached payment without reloading.
Select Validate total.

Expected result

Payment recalculates or invalidates the previous snapshot and displays $135 before validation.

Actual result

Express remains current and the live total is $135, but the displayed payment total is $120. Validation is blocked.

First mismatch

Browser Forward restores the payment view after the cart changed to Express. The current cart state and the displayed payment snapshot disagree for the first time on the same screen.

Reproduction rate

Reproduced in the controlled history-dependent run. The clean Express control path passed.

Impact

A customer can reach payment with a total that does not match the current shipping choice. The issue also wastes a handoff if engineering tests only the final Express state from a fresh page.

Attachments

Attach the shortest material that proves the transition: the starting Standard cart, initial $120 payment snapshot, Back navigation, Express change, Forward navigation, and $135 versus $120 mismatch. Add console or network data only when it helps explain that boundary.

How to keep the Jira issue actionable

Start from the earliest reproducible state

Do not start the steps at the final broken screen. Name the smallest prior state the receiver must recreate. For account, permission, checkout, and browser-history bugs, that setup can matter more than the final click.

Use one action per step

A step such as “change shipping and return to payment” hides the order of operations. Separate Back, shipping selection, and Forward. The developer should know which action changed the state and which action exposed the mismatch.

Separate observation from diagnosis

“Browser Forward restores $120 while Express is current” is an observation. “The cache invalidation service is broken” is a diagnosis. Keep the issue factual until the implementation cause is verified.

Attach context, not volume

A long recording, full console dump, or unrelated network archive can make the useful signal harder to find. Capture the bounded path around the failure. Mark the first mismatch so the receiver can inspect it without replaying an entire session.

Define done in receiver terms

A fixed issue should survive the original path, not only a fresh-page check. In this example, the acceptance check must repeat Standard payment, Back, Express, and Forward, then confirm that the displayed total is $135 before validation.

When a screenshot is enough

A screenshot is enough when the state is visible, the setup is trivial, and the receiver can reproduce the same result from the provided URL and account. A short video helps when timing or motion matters. Console and network details help when a request or runtime error is the first mismatch.

For state-dependent browser failures, preserve the ordered path. The goal is not to attach every available artifact. It is to give the person fixing the issue the smallest complete explanation of how a valid starting state became an invalid result.

If your team repeatedly loses that transition, Samelogic can be deliberately started before the reproduction and used to send the exact browser path to the teammate fixing it. The team behind Samelogic built it for bounded QA, support, product, and engineering handoffs, not passive session replay. You can install the Chrome extension or first review how to choose a bug reporting tool and how to reproduce a frontend bug.