·
8 min
How to Write a Bug Report: ISTQB Template, Fields and Example
Roman Kirchmeier - Autemos
A bug report (defect report) records when and where a failure occurred, what it looks like and what status it has, so that developers and testers can reproduce it and fix it. The ISTQB CTFL 4.0.1 syllabus lists eleven typical contents for it, from a unique identifier to references.
The eleven fields follow as a copyable template, with a filled-in payment example and the rules from Mozilla's bug writing guidelines. The report is the first step in defect management in software testing. Every detail missing here comes back later as a question from the developer.
TL;DR: According to the ISTQB glossary, a bug report documents the occurrence, nature and status of a defect. The CTFL 4.0.1 syllabus lists eleven typical fields, among them test environment, test steps, expected and actual results, severity and priority. Mozilla calls the steps to reproduce the most important part of any report. One report covers exactly one problem.
Figure 1: The 11 typical bug report fields per ISTQB
What is a bug report?
A bug report is a defect management document that records an observed anomaly so that others can reproduce it and act on it. The official ISTQB glossary defines a defect report, with bug report as its synonym, as “Documentation of the occurrence, nature, and status of a defect” (ISTQB Glossary, 2026).
The syllabus names three objectives for a defect report (ISTQB CTFL v4.0.1, 2024):
Give those responsible enough information to resolve the issue.
Provide a means of tracking the quality of the work product.
Give ideas for improving the development and test process.
According to the syllabus, reported anomalies “may turn out to be real defects or something else”, such as a false-positive result or a change request. ISO/IEC/IEEE 29119-3 has document templates and calls defect reports “incident reports”; its field list is paywalled, so the template below follows the free syllabus.
Which fields belong in a bug report according to ISTQB?
CTFL syllabus 4.0.1, section 5.5, says “a defect report logged during dynamic testing typically includes” eleven items: identifier, title, date and author, test object and test environment, context, description of the failure, expected and actual results, severity, priority, status and references (ISTQB CTFL v4.0.1, 2024). The table turns that list into a template you can copy.
Field | What goes in | Example |
|---|---|---|
Identifier | Unique ID, usually assigned by the tool | PAY-1482 |
Title | Short summary of the anomaly (Mozilla: under 60 characters) | Domestic payment: 1'250.50 shows as 125'050.00 |
Date, organization, author | Date observed, issuing organization, name and role | 2026-10-14, QA Payments, M. Keller (test analyst) |
Test object and test environment | Application, version or build, environment, browser or device | E-banking web 4.12.0, TEST environment, Chrome on Windows 11 |
Context | Test case, test activity, SDLC phase, test technique or test data | Test case TC-PAY-031, system test, boundary value analysis, test customer 7 |
Description of the failure | Steps to reproduce, test logs, database dumps, screenshots or recordings | 5 steps, screenshot of the confirmation page, log excerpt |
Expected and actual results | What the test basis says should happen and what did happen | Expected CHF 1'250.50, shown CHF 125'050.00 |
Severity | Degree of impact on the interests of stakeholders or on requirements | High |
Priority | Priority to fix | 1 |
Status | Current state in the workflow | Open |
References | Links to the test case, requirement and related reports | Story PAY-210 “Swiss amount format” |
Defect management tools can fill in the identifier, date, author and initial status automatically, according to the syllabus. In regulated environments, record the build precisely enough that an auditor can find the tested state months later. Each status value from “open” to “rejected” has a fixed place in the bug life cycle.
Severity and priority are two separate fields: one describes the impact, the other the order in which fixes happen. How teams set scales for both is explained in the comparison of severity and priority of defects.
What does a filled-in report look like?
A filled-in report states the environment, the reproduction rate, numbered steps and the expected and actual results, with observations kept apart from assumptions, as Mozilla's guidelines ask (Mozilla Bug Writing Guidelines, accessed 2026). The fictional example below shows this for a transfer form in the e-banking app of a Swiss bank.
PAY-1482: Domestic payment: 1'250.50 shows as 125'050.00
Environment: TEST, e-banking web 4.12.0, Chrome on Windows 11, test customer 7
Reproducibility: every attempt (5 of 5)
Severity and priority: high, 1
References: test case TC-PAY-031, story PAY-210
Steps to reproduce
Log in to e-banking as test customer 7.
Open “Payments”, then “Domestic payment”.
Paste the beneficiary IBAN from test data set 3.
Type 1'250.50 into the “Amount” field.
Click “Next” and check the confirmation page.
Expected result: The confirmation page shows CHF 1'250.50, as specified in story PAY-210.
Actual result: The confirmation page shows CHF 125'050.00. Entering 1250.50 without the apostrophe gives the correct amount.
Observation: The failure occurs only for amounts with a thousands apostrophe. Screenshot and browser console excerpt are attached.
Assumption (unconfirmed): Both separators are stripped on save.
The counter-test with 1250.50 narrows down the cause without prescribing a fix. The assumption is marked as unconfirmed, so nobody mistakes it for a finding.
Which rules make a report easy to reproduce?
A report is useful when a developer can reproduce the failure from its steps alone. Mozilla's bug writing guidelines put that rule first: “Steps to reproduce are the most important part of any bug report.” If a developer can reproduce the bug, Mozilla says, it is very likely to be fixed (Mozilla Bug Writing Guidelines, accessed 2026). The other rules on the same page work as a checklist before you submit:
Figure 2: What research shows about bug report quality
One problem per report: file a separate report for each issue.
State reproducibility: at will, occasionally or not at all.
Keep facts apart from assumptions: observations first, hypotheses clearly marked.
Name the earliest version in which the problem can be reproduced.
Describe the problem, and keep proposed fixes out of the title.
What does research say about report quality?
Developers need different details from the ones users supply: the analysis of 466 responses from Apache, Eclipse and Mozilla developers and users revealed an “information mismatch between what developers need and what users supply.” Most developers consider steps to reproduce, stack traces and test cases helpful, and those are the items users find hardest to provide (Zimmermann et al., IEEE TSE, 2010).
Missing reproducibility costs time. In the MSR study by Joorabchi, Mirzaaghaei and Mesbah, non-reproducible reports made up 17% of all reports in the studied repositories and stayed active around three months longer than others (Joorabchi et al., MSR, 2014). Precise steps, a full environment description and named test data give the developer what they need to reproduce the failure.
How do you write a good report summary?
A good summary names the symptom, the location and the condition in under 60 characters. Mozilla says it should identify a report quickly and uniquely: “It should explain the problem, not your suggested solution.” Mozilla's own pair is “Cancelling a File Copy dialog crashes File Manager” (good) and “Software crashes” (bad) (Mozilla Bug Writing Guidelines, accessed 2026).
Figure 3: Weak vs. better report summaries (examples)
Weak summary | What's missing | Better summary |
|---|---|---|
Payment broken | Location and symptom | Domestic payment: 1'250.50 shows as 125'050.00 |
Please fix amount parser | Describes a fix, not the problem | Amount with apostrophe multiplied by 100 after “Next” |
Login error | Uniqueness | Smartcard login aborts after PIN entry (TEST) |
Several bugs in payment form | One problem per report | One report per bug, each with its own title |
Date wrong?? | Observation, not a guess | Execution date jumps 2 days after 10 p.m. |
Test case or bug report: what goes where?
A test case defines before execution what is checked and which result to expect; a bug report documents a deviation from that result afterwards. The test case stays valid across many test runs. The report exists only once a failure occurs and gets closed when the defect is fixed or another decision is made. Structure and fields are covered in the article test case: template and examples.
The two documents are linked. The syllabus lists the test case in the defect report as context and as a reference. In practice, you copy preconditions and steps from the test case, add the actual result and reference the test case ID. If test executions live in Jira, link the report straight to the failed execution, as described in the article on test management with Xray in Jira.
What evidence does a failed automated test run provide?
A failed automated test run delivers most of the items that most developers rated helpful in Zimmermann et al.: the steps to reproduce, the test case itself and, depending on the framework, a stack trace (our editorial reading, not a measurement).
Figure 4: From failed test run to bug report
Before filing, check whether the failure lies in the product. At Google, about 1.5% of all test runs reported a “flaky” result (Google Testing Blog, 2016). About 84% of the pass-to-fail transitions Google observed involved a flaky test (Google Testing Blog, 2016).
Autemos is AI-assisted software for functional test automation across web, mobile, API and desktop. Autemos is not a defect tracker. It doesn't replace Jira, Azure DevOps or Bugzilla, and it doesn't create bug tickets automatically. Severity, priority and root cause analysis stay with your team. A failed Autemos run contributes the following evidence:
The visual test workflow is the step sequence, so a failed run can be repeated.
Web tests export as Playwright code and mobile tests as Appium code. That code runs without Autemos, so developers can rerun the test outside the tool.
Results land in Autemos reports and Allure reports; logs and telemetry can go to Splunk or Dynatrace.
Test executions sync bidirectionally with Jira/Xray.
Per-environment configuration (DEV, TEST, STAGING, PROD) records where the run took place.
Every self-healing action appears in the report and can be reviewed, rejected or rolled back. A changed locator shows up as a change to the test, not as a product defect.
Once a defect is fixed, the AI chat can draft a regression test workflow from the Jira ticket. Every AI-generated step needs team approval before it runs.
Templates in GitHub and Jira
Issue trackers enforce fields through forms. GitHub issue forms let you define different input types, required checks, default assignees and default labels, and the setting “required: true” makes a field mandatory (GitHub Docs, accessed 2026). Atlassian has a ready-made Jira template with summary, steps, expected and actual results, environment and severity. Which test management tools ship such forms is in the tool comparison.
Frequently asked questions
Is a defect report the same as a bug report?
Yes, the two terms mean the same document. The ISTQB glossary lists “bug report” as a synonym of “defect report”, and the standard ISO/IEC/IEEE 29119-3 calls them “incident reports”.
Which details matter most when you file a bug?
According to Mozilla, the steps to reproduce are the most important part of the report. Next come expected and actual results, the test environment with version or build, and evidence such as logs, stack traces or screenshots.
Who sets severity and priority?
Your team's defect management process decides. At Mozilla, the QA team sets an initial severity for bugs filed or reproduced by QA, and changing a severity requires a comment explaining the rationale (Mozilla triage policy, accessed 2026). Mozilla rates severity on a four-level scale, S1 to S4 (Mozilla BMO User Guide, accessed 2026).
What should you do if a bug can't be reproduced?
File the bug anyway and state whether it reproduces at will, occasionally or not at all, as Mozilla asks. Attach the time and the logs, and for data-driven tests the data set. In a 2014 MSR study, non-reproducible reports made up 17% of all reports and stayed active around three months longer.
Does Autemos create bug reports automatically?
No, Autemos doesn't create bug tickets. It supplies the evidence listed above; your team writes and rates the report in its own tracker.
Conclusion
A good bug report can be reproduced without a follow-up question. The eleven fields from the CTFL 4.0.1 syllabus give the structure, and Mozilla's rules give the quality: steps first, one problem per report, facts kept apart from assumptions and a summary that describes the problem. In one MSR study, non-reproducible reports made up 17% and stayed active around three months longer.
Copy the template into your form in Jira, GitHub or Azure DevOps and link every report to its test case. What happens after the report is covered in the overview of defect management. If you'd like to see how failed Autemos runs supply reproducible steps and evidence your team can attach to its reports, book a demo.
