What this template is for
Bug reports are the highest-volume ticket type in most Jira projects, and they are also the most inconsistent. A QA engineer who files three bugs a day fills out a different set of fields than a customer-support agent who files three bugs a year. The result is wasted triage time, duplicate reports, and bugs that sit in the backlog because nobody can reproduce them.
This template standardises the bug-report contract in two places:
- On the Jira Create Issue screen - the fields below are what a project admin should put in front of every reporter. This is a Jira project-settings job (Project settings → Screens), not something an app does for you.
- On the sub-task list - the work-breakdown that should exist on every triaged bug. This is where STM Issue Templates earns its keep: the sub-tasks below get created automatically by an STM Executor the moment a Bug ticket is opened.
When to use it
Use this template whenever a defect is reported through any channel - QA testing, customer support, production monitoring, or an internal Slack ping. It is intentionally heavyweight because the cost of a half-filled bug report is much higher than the 90 seconds it takes to populate the fields properly.
For very small surface bugs (typos, copy fixes) most teams skip the template and use a lightweight task. For everything else - functional defects, regressions, performance issues, security findings - this template is the floor.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Cart total ignores promo code on checkout step 2 | Yes |
Description | Reproduction steps, expected vs actual | Yes |
Priority | High | Yes |
Severity (custom) | S2 - Major | Yes |
Affects Version | 4.12.0 | Yes |
Environment | Prod / Chrome 125 / macOS 14 | Yes |
Steps to Reproduce (custom) | Numbered list, 1 step per line | No |
Expected Result (custom) | Total reflects 10% discount | No |
Actual Result (custom) | Total unchanged after applying code | No |
Component/s | checkout-service | No |
Labels | regression, customer-reported | No |
Attachments | Browser console log, HAR file, screen recording | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- QA triage - confirm reproduction on the latest release branch
- Engineering investigation - identify root cause and affected components
- Fix - implement and self-review the patch
- Regression test - add a test that fails before the fix and passes after
- Release note - draft the customer-facing changelog entry
Common questions
What fields belong on a Jira bug report?
Every bug report should capture summary, description with numbered reproduction steps, priority, severity, affects-version, environment, expected vs actual result, and at least one attachment (screenshot, HAR, or console log). Component and labels make triage faster. Add these to the project's Create Issue screen so reporters see them on every new Bug.
What's the difference between Priority and Severity on a Jira bug?
Severity measures user impact (how broken is it?). Priority measures scheduling urgency (when do we fix it?). A low-severity, high-priority bug is rare; a high-severity, low-priority bug usually means a workaround exists. Both fields belong on every bug ticket.
Should bug reports use sub-tasks?
Yes. Splitting triage, investigation, fix, regression test, and release note into sub-tasks lets QA and engineering claim work independently and gives you accurate cycle-time data per phase rather than one opaque 'In Progress' status.
How do you automate sub-task creation for every new Jira bug?
Use STM Issue Templates. Build a sub-task template with the QA-triage / investigation / fix / regression-test / release-note sub-tasks, then create an Executor that fires On Create Issue when issue type is Bug. STM creates the full sub-task set on every new bug without manual intervention. STM doesn't change the bug's own create screen - that's a Jira project-screen configuration.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →