How to Create a Defect in Jira: Step-by-Step Guide for QA and IT Teams

Creating a defect in Jira takes two minutes. Creating one that a developer can actually act on without sending five Slack messages takes deliberate structure. This guide walks through every field, every decision point, and every edge case involved in logging a defect in Jira – from opening the Create dialog to linking the ticket to the right sprint, test case, and requirement.

What Creating a Defect in Jira Actually Means

In Jira, a defect is created using the Bug issue type – or a custom issue type your organization calls “Defect” if the admin has configured one. The two are functionally identical. The issue type determines which fields appear on the create form, which workflow states are available, and which screens and schemes apply to the ticket. If your project uses a custom Defect type instead of the standard Bug type, the steps are the same. The field names may differ slightly.

The goal of a defect record is precise: give the development team everything they need to reproduce the problem, understand its impact, and prioritize its fix – without any follow-up conversation. Per ISTQB Foundation Level guidance, a defect report must be complete at the point of creation. Incomplete reports create handoff delays that compound across sprint cycles.

In Jira’s default Scrum project setup, the Bug issue type is available alongside Story, Task, and Epic. In Jira Align (used in SAFe enterprise programs), defects are a separate entity – tracked in the defect backlog and optionally promoted to stories for sprint planning. This guide covers the standard Jira Cloud Bug creation flow, with notes on enterprise-specific configuration where relevant.

Before You Create a Defect in Jira: What to Have Ready

Opening the Create dialog without having your data ready produces low-quality defect reports. Developers receive vague tickets, ask for clarification, and the ticket sits in Triage for three days instead of moving to In Progress. Before you click Create, collect the following.

Exact steps to reproduce. Write them out as a numbered sequence before you open the form. If you can’t reproduce the defect consistently, note the frequency and the conditions under which it occurs. An intermittent defect that appears “sometimes” needs to document what you were doing, what data was in the system, and how many times out of ten the problem appears.

The expected result. This is not “it should work.” It is the specific, documented behavior defined in the requirement or acceptance criterion. If you don’t have a reference requirement, you need to find one before logging the defect – otherwise the triage team can’t confirm it’s actually a defect rather than a gap in specification.

The actual result. Describe exactly what the system did, with specific values, error messages, and observable behavior. “The page crashed” is not an actual result. “The application returned HTTP 500 with the message ‘Internal Server Error’ after clicking Submit on the Claims Entry form when the Patient Account Number field contained more than 8 characters” is an actual result.

Environment details. This means: which environment (DEV, QA, UAT, PROD), which build or release version, which browser and version if it’s a web application, which operating system, and any relevant configuration state. A defect that reproduces only in QA and not in DEV is not the same problem as one that reproduces in both.

Evidence. Screenshot, screen recording, API response log, SQL query result, or error stack trace – whatever documents the actual result objectively. Text description alone is never sufficient for a complex defect.

Severity and priority assessment. Know the difference before you open the form. Severity is the technical impact on the system. Priority is the business urgency to fix it. These are set independently – or should be. More on this in the field-by-field guide below.

How to Create a Defect in Jira: Step-by-Step

Step 1: Open the Create Issue Dialog

In Jira Cloud, click the blue Create button in the top navigation bar. The keyboard shortcut is C (when you’re not in a text field). This opens the Create Issue dialog. The dialog pre-populates the Project field based on your current project context. If you’re navigating between multiple Jira projects, verify the Project field shows the correct project before proceeding – submitting a defect to the wrong project sends it to the wrong team’s backlog.

You can also create a defect directly from the Backlog view by clicking + Create Issue at the bottom of the backlog list and selecting Bug from the issue type dropdown. This approach automatically places the new issue in the backlog without a pop-up dialog. It’s faster for simple defects but gives you fewer fields upfront. For complex defects, use the full Create dialog.

A third path: if you’re working in a test management tool like Xray or Zephyr Scale that’s integrated with Jira, you can create a defect directly from a failed test execution. The tool pre-populates the defect form with the test case name, execution date, and test steps – which saves significant time and ensures the defect links back to the test evidence automatically. If your program uses a test management add-on, this is the preferred method.

Step 2: Select the Issue Type – Bug or Defect

In the Create Issue dialog, the Issue Type dropdown is the second field after Project. Select Bug. If your project has a custom issue type named “Defect,” select that instead. The selected issue type determines which fields are required and which workflow states are available. Selecting the wrong type – for example, creating a Story instead of a Bug – changes the workflow, removes defect-specific fields, and misroutes the ticket in triage.

Some organizations configure separate issue types for different defect categories: “Bug” for development defects found in DEV, “Defect” for QA or UAT findings, and “Production Issue” for post-release failures. If your project uses this classification, understand which type applies before you proceed. Using the wrong type affects how defects appear in dashboards and sprint reports.

In Jira Align (SAFe programs), defects created at the program or team level sync to Jira with a specific mapped issue type. If you’re on a SAFe program and creating defects in both Jira Align and Jira directly, confirm with your Scrum Master or Jira admin which system is the system of record – duplicating defects across both is a common problem on large programs.

Step 3: Write the Summary (Title)

The Summary field is the defect title. It appears on the sprint board, the backlog, in search results, and in every notification email. It is the first thing a developer reads. Write it so that someone unfamiliar with the feature can understand what is broken, where, and under what condition – in one line.

The ISTQB-recommended format for a defect title is: [Location] – [What went wrong] – [When/Condition]. Applied in practice: instead of “Login not working,” write “Login page – Submit button unresponsive when password field contains special characters in Chrome 120.” Instead of “Claims form broken,” write “Claims Entry form – ICD-10 code field truncates values over 8 characters on Save in QA environment.”

Avoid vague verbs like “not working,” “broken,” “failing,” or “issue with.” These titles force the reader to open the ticket for any context. A precise title lets a developer scan the backlog, identify the defect relevant to their component, and start their assessment before they open the full record. On programs with 80+ open defects, this matters.

Keep the summary under 255 characters (Jira’s field limit). If you need more context, it goes in the description. The title is a navigation aid, not the full report.

Step 4: Write the Description – The Core of the Defect Record

The Description field is where the defect report lives. In Jira Cloud, the description editor supports rich text, numbered lists, code blocks, and inline images. Use this. A description written as one paragraph of prose is harder to scan than a structured record with labeled sections.

A complete defect description has four mandatory sections: Steps to Reproduce, Expected Result, Actual Result, and Environment. If your Jira project has a bug issue template configured (via a description template or a Jira app like Smart Templates), it will pre-fill these section headers. Use them. If your project doesn’t have a template, create the structure manually every time.

Many experienced teams also add a fifth section: Notes / Context – where the tester adds any observations that don’t fit the other categories. For example: “This defect only appears when the session has been active for more than 30 minutes. A fresh login does not reproduce the issue.” That context would otherwise be lost.

Writing Steps to Reproduce That Actually Work

Steps to reproduce are the most critical part of a defect record. Without them, a developer is solving a mystery instead of fixing a bug. Each step must be atomic – one action per step. Don’t combine “Navigate to Claims page and click Submit” into one step. The navigation and the click are separate steps, and the distinction sometimes matters for identifying exactly when the error occurs.

Include preconditions above the steps: the state the system must be in before Step 1 begins. “User must be logged in as a Billing Manager role.” “The patient record must have a blank diagnosis code field.” These preconditions prevent a developer from running the steps correctly but missing the defect because the system state was wrong.

For intermittent defects – ones that don’t reproduce every time – document the frequency explicitly: “Occurs approximately 3 out of 10 attempts.” Include any pattern you’ve observed: time of day, concurrent users, data volume, or sequence of prior actions. An intermittent defect with no frequency or pattern data is extremely difficult to fix, because the developer may run the steps five times without seeing the problem and close the ticket as “Cannot Reproduce.”

Step 5: Set Priority

Jira’s default Bug issue type includes a Priority field with values: Highest, High, Medium, Low, and Lowest. In many Jira configurations, this single Priority field carries double duty – representing both technical severity and business urgency. This is a known limitation. Quality Assurance professionals – per ISTQB Foundation Level guidance – treat severity and priority as separate dimensions. If your Jira project has both a Severity field and a Priority field (configured via custom fields), use both independently. If it only has Priority, use it to reflect business urgency and document technical severity in the description.

Set priority based on: how many users are affected, what business function is impaired, whether there is a workaround, and how close you are to a release milestone. A defect that blocks the primary happy path of a release-critical feature is Highest priority regardless of its technical severity. A defect that crashes a rarely used admin report is lower priority even if its technical severity is high.

One common mistake: over-escalating everything to Critical or Highest. When 40% of the backlog is marked Critical, the label loses meaning. Developers have no way to differentiate genuinely blocking defects from the rest. Resist the pressure to inflate priority. Set it to what the evidence supports.

Step 6: Assign to the Right Person or Team

The Assignee field determines who receives the defect notification and owns the next action. Assignment depends on your team’s triage process. Some teams assign new defects to the QA lead or triage queue; others assign directly to the developer responsible for the affected component.

If your team runs a formal triage process – where a QA lead, BA, and developer review new defects before sprint assignment – leave the Assignee as Unassigned or assign to the triage owner. Assigning directly to a developer before triage bypasses the review step and can result in developers working on misclassified or duplicate tickets.

On large programs with multiple development squads, use the Components field (covered in Step 8) to route the defect to the right team. Many Jira projects configure automatic assignment rules based on component selection – so setting the correct component triggers assignment automatically without the reporter needing to know which developer owns which module.

Step 7: Set the Fix Version and Sprint

The Fix Version field connects the defect to a release milestone. If the defect must be resolved before a specific release (a UAT gate, a PI boundary, or a production deployment date), set the Fix Version accordingly. This feeds the Version release report and lets the release manager see defect density per version at a glance.

Don’t set Fix Version if the resolution timeline hasn’t been decided yet. Setting it prematurely creates false commitments in release reports and misleads program management. Set it after triage, when the team has agreed on which sprint or release the fix belongs in.

The Sprint field assigns the defect to an active or upcoming sprint. Like Fix Version, set this after triage confirmation – not at creation time unless the defect is obviously critical and must be pulled into the current sprint immediately. A defect created and sprint-assigned before triage may displace story work the team already committed to.

Step 8: Set Components and Labels

Components group issues by functional area of the application. Common component examples: “Claims Processing,” “Patient Portal,” “Authentication,” “Reporting,” “HL7 Interface,” “Payment Gateway.” Setting the correct component is important for two reasons. First, it determines routing if your project has auto-assignment rules. Second, it enables component-level defect density reporting – a metric that shows which areas of the system are generating the most defects, which informs test focus and risk-based test planning per ISTQB Advanced guidelines.

Labels add searchable tags that don’t exist as dedicated fields. Common label uses: “HIPAA-Critical” for compliance-sensitive defects, “Regression” for defects that represent a reintroduction of a previously fixed issue, “Data-Quality” for defects involving incorrect data output, “Automation-Candidate” for defects that should be covered by automated test cases after resolution. Labels are informal but powerful for filtering – a QA lead who queries `label = HIPAA-Critical AND status != Done` has an instant compliance defect report.

Step 9: Link the Defect to Related Issues

The Linked Issues section connects the defect to other Jira tickets using typed relationships. The standard link types are: blocks / is blocked by, duplicates / is duplicated by, relates to, and clones / is cloned by. Use them precisely.

Link the defect to the user story it violates using “relates to.” This creates the traceability from defect back to requirement that ISTQB and BABOK v3 both emphasize. Karl Wiegers in Software Requirements, 3rd Edition frames requirements traceability as foundational to defect analysis – a defect you can’t trace back to a requirement might not be a defect at all.

Link the defect to blocking stories using “blocks.” If a defect in the authentication module prevents three stories in the current sprint from being completed, those three stories should be linked as “is blocked by” the defect. This makes the dependency visible in sprint planning and gives the Scrum Master data to escalate if the defect isn’t resolved in time.

If you’ve found a duplicate of an existing defect, link it as “duplicates” and add a comment explaining the overlap before closing the new ticket as a duplicate. Don’t close duplicates without a link – the relationship data is useful for tracking defect recurrence patterns.

Step 10: Attach Evidence

The Attachment section supports screenshots, screen recordings, log files, API response payloads, database query results, and any other supporting evidence. Add at minimum one visual that shows the actual result – either a screenshot of the error or a screenshot of the incorrect output. For API defects, attach the full request-response pair (sanitized of any PII per HIPAA or your organization’s data handling policy).

For defects involving data issues – ICD-10 code truncation, SQL query returning incorrect rows, XML transformation failures – attach the specific data payload or query result that demonstrates the problem. On a healthcare IT program, that data must be de-identified before attachment. Never attach real patient data to a Jira ticket, regardless of environment. HIPAA’s minimum necessary standard applies to defect documentation as much as to clinical data.

For intermittent defects, a screen recording is significantly more useful than a screenshot. Jira Cloud accepts video attachments. A 30-second recording showing the defect occurring is more actionable than three paragraphs describing what you saw.

Step 11: Click Create and Verify the Ticket

Click Create. Jira assigns a unique issue key (e.g., PROJ-1423) and creates the ticket in the project backlog in status “To Do” (or “Open,” depending on your workflow configuration). You receive a confirmation notification.

After creation, open the ticket and verify: all fields populated correctly, the linked issues appear under the Links section, and attachments uploaded successfully. On large Jira instances, attachments occasionally fail silently. Verify the file appears before closing the browser tab.

Add a comment immediately if there’s context that doesn’t fit the structured fields – for example, a message tagging the relevant developer: “@[Developer Name] – this reproduces in QA but not DEV. Middleware logs attached.” Comments create a conversation thread on the ticket and keep all communication in one traceable location instead of fragmented across Slack.

The Defect Lifecycle in Jira After Creation

Creating the ticket is step one of a lifecycle that doesn’t end until the defect is verified and closed. Understanding the full cycle helps QA analysts manage their open defect queue and prevents tickets from stalling at intermediate states.

The QA analyst’s job doesn’t end at creation. After the developer marks the defect Resolved, the QA analyst must retest in the environment where the fix was deployed. If the fix holds, close the defect. If it doesn’t, reopen it with a comment documenting the retest – steps taken, build version retested, and what still fails. A defect that’s reopened without retest documentation wastes the developer’s time on re-investigation.

The Reopened status is significant for metrics. Defects that are reopened multiple times – especially the same defect reopened after the same type of fix – indicate a pattern worth escalating. Per Six Sigma DMAIC methodology, recurring defect reopenings signal a root cause problem in the development or testing process, not just a one-off mistake.

Healthcare IT Scenario: Creating a Defect in Jira on an EHR Integration Program

A regional hospital network is in System Integration Testing (SIT) for a new EHR implementation. The testing team is validating the HL7 FHIR-based interface between the EHR and the external laboratory information system (LIS). During a test run, the QA analyst executes test case TC-LIS-042: “Verify that inbound lab result ORU R01 messages populate the patient chart’s Lab Results section within 60 seconds.”

The message transmits. The interface engine log shows receipt and processing. But the lab result doesn’t appear in the patient chart. After 15 minutes, no update. The QA analyst inspects the interface engine’s error log and finds: “OBX segment field 5 value exceeds maximum configured length of 50 characters. Message rejected.”

The analyst opens Jira and creates a defect. Here’s what the complete record looks like:

This defect record is complete. The developer can reproduce the problem, identify the root cause (incorrect field length configuration in the interface engine), and understand the compliance implications without any follow-up conversation. The triage team has enough to confirm severity and authorize immediate sprint assignment. The compliance officer can use this record in a HIPAA audit trail.

Defect Creation from Automated Test Failures in a CI/CD Pipeline

Manual defect creation is one path. Automated defect creation via CI/CD pipeline integration is the other. In a mature DevOps environment, a failed automated test in Jenkins, GitHub Actions, or Azure Pipelines triggers a Jira defect automatically using Jira’s REST API or a native plugin.

A Jenkins pipeline that runs a Selenium regression suite on every build can be configured to call the Jira API endpoint POST /rest/api/3/issue when a test case fails. The API payload includes: the project key, issue type (Bug), summary (auto-generated from the test case name and failure message), description (populated with the test execution log and failure stack trace), priority (mapped from the test case’s criticality label), and component (mapped from the test suite’s module tag).

The benefit: defects created from automated failures are consistent, timestamped to the exact build, and already linked to the test execution artifact. The limitation: automated defect creation produces volume. A single build failure that breaks 40 test cases creates 40 Jira tickets unless the automation is configured with deduplication logic – checking whether an open defect already exists for that test case before creating a new one.

The recommended approach is a hybrid: automated creation for genuinely new failures, with a deduplication rule that reopens the existing ticket (and adds a build reference comment) if the failure maps to a known open defect. This keeps the backlog clean and prevents the triage team from reviewing the same defect multiple times under different ticket numbers.

If your team uses Xray for Jira, automated test execution results feed directly into Jira with defects created from the test run’s failed steps. The defect is automatically linked to the test case and the test execution record, giving QA full traceability from the CI/CD run to the Jira backlog without any manual steps. This is the preferred configuration for programs where QA teams run automation at scale.

Common Mistakes When Creating Defects in Jira – and How to Fix Them

Vague Summary Lines

“Login broken” tells no one anything. The developer assigned to the authentication module has to open the ticket to understand whether it’s a UI issue, a backend API failure, a session management bug, or a third-party OAuth problem. Every ticket open costs attention. Make the title earn that open.

Fix: Apply the [Location] – [What] – [Condition] format. Rewrite “Login broken” as “Login page – Submit button returns HTTP 401 when username contains uppercase characters in Chrome 124 on QA.” That title is searchable, specific, and routes the defect to the right person without anyone reading the body.

Missing Steps to Reproduce

“The page crashes when I click Submit” is not steps to reproduce. The developer doesn’t know which page, which Submit button, what data was in the form, what the user’s role was, or what the environment state was.

Fix: Number every step. Include the URL. Include the exact data entered. Include the user role. Include any preconditions. If you can’t write reproducible steps, the defect isn’t ready to log – go back to the application and reproduce it deliberately before creating the ticket.

No Expected Result Referenced to a Requirement

Writing “it should work correctly” as the expected result is not a defect record. It’s a complaint. The expected result must reference the specification – the acceptance criterion, the requirement ID, or the business rule that defines correct behavior.

Fix: Before writing the expected result, open the linked story or requirement document and copy the relevant acceptance criterion. Cite the story ID. “Per AC-5 in Story EHR-1204: the system should display the lab result within 60 seconds of HL7 message receipt.” Now the developer, triage team, and compliance officer all know exactly what standard is being violated.

Setting Everything to Critical Priority

Priority inflation is the fastest way to make sprint planning unreliable. When the backlog is 90% Critical, the team has no signal for what actually needs to be fixed this sprint versus next.

Fix: Set priority based on documented criteria. Reserve Highest for defects that block the release-critical path, affect all users with no workaround, or create a compliance exposure. High for significant functional failures with limited workarounds. Medium for issues that affect experience but not core function. Low for cosmetic issues and minor inconsistencies. Apply the matrix consistently. If your team disagrees on severity levels, that’s a process conversation to have in triage – not something to resolve by defaulting to Highest.

Skipping Duplicate Checks

Creating a defect that already exists in the backlog duplicates triage effort, dilutes defect density metrics, and causes two developers to potentially work the same fix. Before logging any defect, search the existing backlog. Use Jira’s search (JQL: issuetype = Bug AND text ~ "Claims Entry form" AND status != Done) to find open defects matching your keywords.

If you find a possible duplicate, open the existing ticket, compare the steps and actual result, and confirm they describe the same root cause. If they’re the same, add your evidence as a comment on the existing ticket. Don’t create a new one. If they’re related but distinct, create yours and link it as “relates to.”

Custom Fields for Defects: When and How to Add Them

Jira’s default Bug issue type is a starting point. Most production programs customize it. The most common additions are a Severity field (separate from Priority), a Root Cause Category field, a Found In Environment field, a Test Case ID field, and a HIPAA/Compliance Impact field for regulated industries.

Custom fields are added by a Jira admin at the project or global level. They appear on the create form and the issue detail view. If a field needs to be mandatory – that is, a defect can’t transition to In Progress without it being set – the admin configures a workflow validator on that transition. Validators enforce data quality at the process level instead of relying on individual discipline.

The Root Cause Category field is particularly useful for Six Sigma-aligned quality programs. When defects are categorized by root cause at creation or closure – options like “Requirement Gap,” “Code Logic Error,” “Environment Issue,” “Data Quality,” “Missing Test Coverage,” or “Third-Party Integration Failure” – the resulting data enables Pareto analysis of defect root causes per sprint or per release. That analysis drives process improvement decisions, not just ticket counts.

On healthcare programs, a Compliance Impact custom field – with values like “HIPAA PHI Risk,” “HIPAA Security Rule,” “Clinical Safety,” or “None” – enables the compliance team to filter open defects with regulatory exposure in seconds. Without this field, a compliance officer has to read every open defect to find the relevant ones before an audit. With it, a JQL query surfaces the list in under a minute.

Defect Metrics You Can Drive from Jira Defect Records

Well-structured Jira defect records generate metrics that support delivery decisions. Here are the ones worth tracking.

Defect density by component – how many open defects exist per functional area. High defect density in one component signals that area needs focused regression attention or developer code review, not just more test cycles. Supports risk-based test planning per ISTQB Advanced Test Manager guidelines.

Defect escape rate – defects found after the QA gate, in UAT or production, as a percentage of total defects. A high escape rate means defects that QA should have caught are reaching later stages. This is a metric about test coverage quality and test execution rigor, not a number to minimize by logging fewer defects.

Mean time to resolution (MTTR) by severity – how long it takes Critical defects to move from Open to Closed, on average. If Critical defects take 8 days to close on a 10-day sprint, something is wrong in the triage or development process. This number drives sprint planning decisions about defect capacity allocation.

Reopen rate – what percentage of resolved defects come back as Reopened. High reopen rates indicate that fixes aren’t complete or that QA retesting isn’t rigorous enough. Either way, it’s a process signal worth investigating.

All of these metrics are generated from the data in the defect records you create. A field that isn’t populated consistently – severity, component, root cause category – produces a metric that doesn’t reflect reality. The quality of your defect creation process is the ceiling of the quality of your metrics.

Role-Specific Notes: Who Does What When Creating Defects

Different roles interact with the defect creation process differently. Understanding these distinctions prevents the most common cross-functional friction points.

The Business Analyst’s role in defect creation is underappreciated on most programs. BAs who are involved in triage – not just requirements writing – catch the defects that are actually requirement gaps much earlier. A defect that gets reclassified in triage saves a developer the cost of investigating and fixing a problem that was never specified correctly in the first place.

The Scrum Master’s relationship to defects is primarily metric-based. They monitor defect age, MTTR, and sprint-level defect capacity. If Critical defects are consistently surviving multiple sprints without resolution, that’s a capacity or process failure that needs addressing in the retrospective – not just an item to carry forward.

The Product Owner owns the go/no-go decision for releases. A defect’s impact on that decision is determined by its priority and whether it’s blocking release-critical stories. The PO should be able to generate a filtered view of all open defects tagged to the upcoming release at any time – which is only possible if Fix Version and priority fields are populated accurately.

Edge Cases: When Standard Defect Creation in Jira Doesn’t Fit

The standard flow covers most situations. These edge cases require a different approach.

Production defects. A defect found in production after go-live is not a standard bug. It may require an immediate hotfix outside the sprint cycle, a communication to affected users, a HIPAA breach assessment if PHI is involved, and a post-incident review. The Jira ticket should be created with a “Production” label and a separate “Production Issue” issue type if your project has one, to distinguish it from pre-release defects in reporting. Some organizations have a separate Jira project for production incidents that integrates with their ITSM platform.

Security vulnerabilities. A defect that reveals a security vulnerability – exposed API endpoint, SQL injection vector, broken authentication bypass – should not be created in the standard public-visible Jira project. Many organizations configure a private security project with restricted visibility. Create the ticket there, not in the main project, and notify the security team directly. An unresolved security vulnerability visible to all Jira users is itself a risk.

Defects across projects. On programs where multiple Jira projects are involved – one for the EHR, one for the integration middleware, one for the patient portal – a defect may span project boundaries. The interface between two systems fails: which project gets the ticket? The answer is wherever the fix needs to happen. If the EHR is sending a malformed message, the defect goes in the EHR project. If the middleware is rejecting a valid message, it goes in the middleware project. When you’re unsure, create the defect in the project where you found the failure, link it across projects if Jira supports cross-project linking in your instance, and let triage determine the correct home.

Defects with no reproducible steps. Some defects happen once and can’t be reproduced. Log them with whatever evidence you have – a screenshot, a log timestamp, a user report – and mark the frequency as “Observed once, unable to reproduce.” Don’t inflate the priority because you can’t reproduce it. Document what you did observe and let the developer investigate. Unconfirmed intermittent defects are valid tickets with a clear caveat – don’t suppress them, but don’t block releases on them either without more evidence.

Suggested External References:
1. Jira Bug Tracking Features – Atlassian Official Documentation (atlassian.com)
2. ISTQB Foundation Level Syllabus – Defect Reporting Standards (istqb.org)