A screenshot of an incorrect order reference shows a symptom. It does not tell the next reviewer which account could edit it, what value existed beforehand, or whether the change survived a reload. Without those details, two people can follow apparently similar steps and observe different behavior.
A useful Jira bug report preserves enough context to reconstruct the observation, compare it with an explicit expectation, and decide what to investigate next. Start with a short, searchable title, then put the reproducer and supporting evidence in a structured description. Keep uncertainty visible instead of filling gaps with a suspected root cause.
In Jira Cloud, the short title may appear as Title, formerly Summary. Some sites and documentation still use Summary, project, and issue where newer experiences use Title, space, and work item. Available fields and controls depend on your site's configuration and create experience.
Use the Bug work type when it is configured for the destination, or the equivalent your administrator has approved. Bug is a default software work type, not a promise that every Jira space has the same types or workflow. Before submitting:
Expected Result, Actual Result, Environment, Reproducibility, and Severity below are suggested description headings. They are not guaranteed separate native Jira fields. If your team already has suitable structured fields, populate those and avoid contradictory copies in the description.
A manual description template does not require a Marketplace app or automation rule. Consider custom fields only when the team needs consistent filtering or reporting that description text cannot provide. Ask the responsible administrator to inspect existing fields, their scope, and the applicable screens or work-type configuration before adding another field. A field missing from the create form may be hidden or configured differently, rather than unavailable in Jira.
Put the short symptom title in Title or Summary. Copy the following headings and prompts into Description. Keep the minimum context needed to reproduce and assess this finding; do not turn an unknown into “not applicable” merely to make the report look complete.
State the observable behavior that should occur. Identify the acceptance criterion, requirement, or agreed rule supporting that expectation. Include what must remain unchanged when relevant.
Record the observed difference, the failing step, and any exact message. Separate visible behavior from unverified explanations. State which downstream effects were checked and which remain unknown.
Describe the affected user task, known exposure, and any verified workaround. Propose severity and priority using the team's definitions, with a reason. List sanitized evidence by filename or an approved reference, explaining what each item demonstrates and who can access it.
Identify the related requirement, executed test and version, run or attempt, and any potentially matching defect. Record the main unanswered question, the person responsible for obtaining missing information, and the agreed follow-up point.
The starting state is part of the reproducer. “Open an order and save it” leaves the reviewer to choose an order, account, and initial value. Specify whether the record already exists, which role is active, and what configuration makes the path available. Use approved synthetic fixtures where possible. Describe how to restore them before another attempt.
Write actions in the order performed, with inputs that could affect the outcome. Split steps when separate actions introduce meaningful state changes. Do not include every mouse movement, but retain a browser reload, account switch, delayed response, or repeated submission if it changes the conditions. If a problem depends on timing, describe the observed sequence rather than claiming a precise delay that was never measured.
Expected and actual results should address the same checkpoint. “The system should work” cannot be compared with “Save returned an error.” Explain whether the value should persist, whether a forbidden operation should leave data unchanged, or which error should appear. Cite the team's requirement within the report using its approved reference. When intended behavior is disputed, record the question for the responsible owner instead of inventing an acceptance rule.
For an intermittent failure, retain the attempts that did not fail as well as those that did. Record the conditions and denominator: “failed in three of five reset attempts on this build” is more useful than “sometimes.” Do not infer a production failure rate from a small local attempt set. If the trigger is unknown, report the available observation and assign the missing investigation; an incomplete reproducer does not make a potentially serious finding disappear.
Keep observation and diagnosis separate. A value remaining changed after reopening a screen is evidence of persistence through that path. It does not establish whether the cause lies in the browser, authorization logic, service, or storage layer. Label a suspected cause as a hypothesis and identify the evidence needed to evaluate it.
The entire report below is fictional. Its application, identifiers, versions, times, evidence files, and outcomes illustrate the format; they are not a customer case or a test performed against Jira or another system. Sample browser and build values are identifiers, not current-version recommendations.
Title or Summary: Reviewer can change an existing purchase-order reference and retain it after reopening.
Use the staging purchase-order application, build orders-rc21, with Chrome 130.0.6723.58 on Windows 11 23H2. Sign in using an approved synthetic account assigned the Reviewer role. No credential belongs in the report.
Synthetic order DEMO-204 exists in Draft state with reference ALPHA. Fictional acceptance criterion AC-7 permits Reviewers to view purchase orders but prohibits changing their reference. An authorized fixture owner restores ALPHA before each attempt and confirms that the same role and configuration are used. No real customer record is involved.
Expected: under AC-7, the Reviewer cannot persist a reference change. The application should prevent the prohibited update, and reopening DEMO-204 should still show ALPHA. Whether the interface hides the control or rejects the save should follow the agreed design.
Actual in this fictional observation: the control accepts BETA, Save displays “Order updated,” and reopening the order still shows BETA. The divergence begins when the prohibited update is accepted and remains visible at the persistence checkpoint. No claim is made about which backend component caused it.
The fictional observation window is 10:14–10:19 UTC on 20 October 2026. Three reset attempts on the stated build show the same result, giving an illustrative record of three failures in three attempts. Other browsers, roles, order states, and service paths have not been checked. Those limits belong beside the result, not hidden behind “always reproducible.”
The proposed evidence set is deliberately small. These are fictional file references for a report, not attachments created or uploaded by this guide.
Evidence Reference | What It Demonstrates | What It Does Not Establish |
|---|---|---|
DEMO-204-before-redacted.png | Initial ALPHA value and synthetic Reviewer context | Whether every role has the same permissions |
DEMO-204-save-redacted.mp4 | The edit, Save response, and BETA after reopening | Which component permitted the update |
DEMO-204-event-excerpt.txt | Sanitized event window and safe correlation reference DEMO-EVENT-21 | The behavior of unexamined requests or records |
Proposed impact statement: a role intended to read orders can alter a business reference through this path. Wider exposure and changes to other fields remain unknown. Under this fictional team's local definitions, the reporter proposes Major severity because an unauthorized persistent change affects record integrity, and requests prompt priority review. Neither label is a universal Jira scale or a substitute for the team's risk decision.
Related context: AC-7, test ORDER-READ-04 revision 2, and failed attempt RUN-DEMO-21. Those are illustrative record identifiers, not native fields automatically created by Jira. The next-action owner should investigate the allowed update path and determine exposure. Any temporary restriction is a proposed mitigation until an authorized owner verifies its effectiveness.
Choose evidence that answers a specific question. A screenshot can show an initial value or visible error. A short recording can preserve a sequence. A narrow log excerpt or request trace can connect the observation to an event window and correlation identifier. None automatically proves a root cause, and a success notification alone may not establish the underlying business outcome.
Before attaching or linking evidence, inspect it for passwords, session cookies, access tokens, authorization headers, customer details, private messages, and unnecessary internal information. Browser network exports and recordings can contain more data than the visible screen suggests. Review the resulting file rather than assuming an export or redaction option removed everything sensitive.
Prefer synthetic data and the smallest useful excerpt. Crop unrelated content, remove secret-bearing headers and payload values, and verify the exported copy after redaction. Keep enough context to connect the evidence to the build, attempt, and observed result. When an identifier itself is sensitive, use an approved safe reference with a controlled mapping rather than exposing it in a broadly visible issue.
Jira supports attachments, but administrators can disable them, and adding files depends on the applicable permissions and configuration. Use only an approved storage location and confirm that intended reviewers can access it. Configured work-item security can restrict visibility where available; it does not replace redaction or guarantee identical controls on every plan and project type. Ask the administrator to check the actual access model before sharing sensitive material.
For a suspected security or privacy issue, follow the organization's restricted reporting and incident process. Do not repeat destructive actions against production to improve a reproducer. If raw evidence requires specialist access, keep it in the approved restricted location and record who can review it and what question it answers. An inaccessible link without an owner leaves the investigation blocked.
Before creating parallel work, compare potentially matching defects by trigger, expected behavior, and affected version, not title alone. When an existing defect owns the finding, preserve the new conditions and evidence with an appropriate available relationship. Jira link types are configurable, and linking a duplicate does not itself establish that its affected build is covered by a fix.
A useful handoff names the next question, an accepted next-action owner, and a review point. For the worked example, that question is whether the prohibited update is accepted beyond the observed UI path and which users or records are exposed. Severity describes impact under the team's convention; priority expresses when to act relative to other work. Explain the rationale and uncertainty before asking someone to choose a label.
When a report originates in a managed test run, retain the executed case version and failed attempt rather than copying only the case title. Sherlock Test Management's documented linked-defect workflow describes creating a Jira defect from a failed test while retaining the run, executed case, requirement, and source context. Its finished runs remain attached to the baseline version they executed. These are app capabilities, not native Jira test execution or evidence of autonomous browser testing. The Sherlock product workflow describes that case-to-run-to-defect context.
After a correction is delivered, preserve the original failure and add a separate observation identifying the corrected build, restored conditions, steps, expected result, actual result, and evidence. Record blocked prerequisites instead of claiming a pass on an unknown artifact. Select nearby checks based on the change's risk; passing the original reproducer alone does not certify the release. The bug-fix verification workflow develops that follow-up without assuming every project has identical reopen or close transitions.
Before submitting the next report, ask a teammate to reconstruct its starting state, locate the exact expected-versus-actual difference, and open the safe supporting evidence. If any answer depends on the reporter's memory, add the missing information or name the person who will obtain it. That is a practical intake standard a template can support without pretending every investigation is already complete.
A tester reviewing a Jira issue may need a fresh smoke run without opening GitLab and choosing pipeline parameters. A manually triggered Jira Cloud…
A scheduled QA flow stops updating release-readiness notes. Some work items may already have changed, others may still be waiting, and the last visible…
A sprint can contain carefully estimated testing work and still overload the only person who can perform it. The missing input may be a…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
