Bugs, Jira & defect reports
Writing defect tickets is a main part of this job and a main part of the interview. After this chapter you can write a perfect bug report and answer every "what would you do with this bug?" question.
- A bug report is a recipe: another person must be able to make the same bug happen.
- It needs: a clear title, the version, steps, expected vs actual, and proof (video, trace, log).
- Severity = how bad it is. Priority = how fast to fix it.
- Search first: one problem = one ticket.
Think of it like reporting a car accident to the insurance company: where, when, what happened, and photos as proof.
See it as a picture: Bug recipe · Severity vs priority · Ticket life · Duplicates · When not to raise
The words: bug, defect, issue, ticket
- Defect = bug = fault: something in the software that doesn't match the requirement. "Issue" is often used the same way.
- Failure: what you see on the screen when the defect shows up.
- Ticket: one bug report in Jira, with an ID such as IVI-1433. You "raise", "log" or "file" a ticket.
- Jira: the most common web tool for tickets. Others: Polarion, ALM, Redmine, Bugzilla, Azure DevOps.
A perfect bug report, field by field
A good bug report lets a developer who has never seen the problem reproduce it on the first try, understand how bad it is, and start fixing — without asking you a single question.
| # | Field | What to write | Example |
|---|---|---|---|
| 1 | Summary (title) | [Area] what goes wrong + when. Short and specific | [Cluster] Snowflake shown at exactly 5.0 °C; spec requires < 5.0 °C |
| 2 | Environment | SW build, HW sample, bench ID, variant/market, language, units, phone model + OS if relevant | SW 24.3.1, C-sample, bench B-03, EU, EN, °C |
| 3 | Preconditions | State before the steps | Ignition ON, cluster started, Outside_Temp = 6.0 °C |
| 4 | Steps to reproduce | Numbered, minimal, exact values | 1. Set Outside_Temp = 5.0 °C 2. Wait 3 s |
| 5 | Expected result | What should happen + requirement ID | No snowflake (REQ-HMI-TEMP-012) |
| 6 | Actual result | What really happened, facts only | Snowflake shown after 0.4 s |
| 7 | Reproducibility | How often: 5/5, 2/10, "once in 8 h" | 3/3 |
| 8 | Severity / priority | Your proposed severity; priority is usually set in triage | Severity: Minor |
| 9 | Evidence | Screenshot, video, CAN trace, DLT/logcat log, timestamps, Robot log.html | video.mp4, trace.blf (10:15:32), cluster.dlt |
| 10 | Analysis (optional but valued) | What you found in logs/traces | Bus value correct; HMI logic likely uses ≤ |
| 11 | Impact analysis | Who/what is affected, safety relevance, other variants, workaround | False warning; all EU variants; no workaround needed |
| 12 | Links & classification | Requirement, test case, related/duplicate tickets; component; affected version; labels | REQ-HMI-TEMP-012, TC-TEMP-003; component Cluster-HMI |
"A clear summary with the area and the problem; the environment — build, bench, variant; preconditions and numbered steps with exact values; expected result with the requirement ID and the actual result; how often it happens; severity; and evidence: screenshots or video, CAN traces and logs with timestamps. I add my own analysis and the impact, and link the requirement and the test case. The goal is that the developer can reproduce it on the first try."
How to write each part well
The summary
Formula: [Component] + what is wrong + under which condition. Someone scanning a list of 500 tickets must understand the bug from the title alone.
| Bad summary | Why bad | Good summary |
|---|---|---|
| Snowflake bug | Which bug? When? | [Cluster] Snowflake shown at exactly 5.0 °C; spec requires < 5.0 °C |
| Bluetooth not working | Too vague | [BT] iPhone 15 not auto-reconnecting after ignition cycle (Android OK) |
| Crash!!! | No information | [Media] Head unit restarts when USB stick is removed during MP3 playback |
| Wrong text | Where? Which text? | [Settings/DE] "Einstellungen" button label cut off to "Einstellun" in German |
Steps to reproduce
- Start from a known state (preconditions).
- Number the steps; one action per step.
- Use exact values ("set 5.0 °C", not "set a low temperature").
- Minimal: remove steps that aren't needed to trigger the bug.
- Try them yourself once more exactly as written before submitting.
Evidence (the JD asks for this explicitly)
| Evidence | When | Tip |
|---|---|---|
| Screenshot | Visual bugs | Mark the problem area with a red box |
| Video | Timing, flicker, sequences | Show a clock or the trace timestamp in the video if possible |
| CAN trace (.blf/.asc) | Anything depending on signals | Write the timestamp of the problem in the ticket |
| Log (DLT, logcat) | Crashes, errors, wrong logic | Trim to the relevant time window, but keep the original |
| Automation report | Failures from test runs | Link log.html and point to the failing step |
| Crash dump | Crashes, resets | Attach it; developers need it |
Impact analysis (explicitly in the JD)
Impact analysis answers: "How bad is this, and for whom?" Ask yourself:
- Safety: could the driver be misled or distracted? (wrong speed, missing warning)
- Function: is a function lost completely, partly, or just cosmetic?
- Scope: which variants, languages, markets, phones are affected?
- Frequency: every time, or rarely?
- Workaround: can the user avoid it? (e.g. reconnect the phone)
- Other features: does it affect other tests (blocked tests)?
"Impact: The driver sees an ice warning at exactly 5.0 °C when there is no ice risk (false warning). Affects all EU variants using this cluster software. No safety function is lost; could reduce trust in the warning. Also causes TC-TEMP-004 to fail. No workaround needed."
Bad report vs good report
Bad
Title: Music problem
Description: Sometimes the music stops. Please fix asap.
Problems: no build, no steps, no expected result, no evidence, no frequency, emotional wording.
Good
Title: [Media] BT audio stops after incoming call ends (iPhone 15, iOS 18)
Env: SW 24.3.1, bench B-02
Steps: 1. Play BT music 2. Receive call 3. Accept 4. End call after 10 s
Expected: Music resumes (REQ-MED-045)
Actual: Music stays paused; source shows "Playing"
Repro: 4/5
Evidence: video, logcat 14:02:11
Severity vs priority
Severity = how bad the effect is (a technical judgement; the tester proposes it). Priority = how soon it must be fixed (a business decision; the project / product owner decides, usually in triage).
Typical severity levels
| Severity | Meaning | Automotive HMI example |
|---|---|---|
| Blocker | Testing or use is impossible | Head unit doesn't boot; cluster black screen |
| Critical | Main or safety function broken, no workaround | Wrong speed shown; rear camera doesn't appear; brake warning missing |
| Major | Important function broken, workaround may exist | Bluetooth doesn't reconnect (manual reconnect works); navigation arrow wrong |
| Minor | Small function problem or clear visual issue | Progress bar doesn't match time; text slightly cut off |
| Trivial | Cosmetic, barely noticeable | 2-pixel misalignment in a sub-menu |
Names differ between companies (e.g. A/B/C, S1–S4). Always follow your project's definitions.
The four combinations (classic interview question)
| High priority | Low priority | |
|---|---|---|
| High severity | Speedometer shows wrong speed. Head unit reboots when reverse is selected. | Crash only in a language that isn't released yet, or only with 5,000 contacts plus a rare character |
| Low severity | Car maker's brand name misspelled on the start-up screen (visible to every customer, embarrassing) | Small misalignment on a rarely used service screen |
How to decide severity
- Is safety or a legal rule affected? → Critical (or higher).
- Is a whole function lost? Is there a workaround? → Major if lost with workaround, Critical without.
- Is it only visual? → Minor / Trivial.
- How often and how many users? Frequent + many users pushes it up.
The defect life cycle
| Status | Meaning | Who moves it |
|---|---|---|
| New / Open | Just created | You (reporter) |
| Triage / Analysis | Checked: valid? duplicate? priority? which team? | Triage team / defect manager / proxy team |
| Assigned | A developer or team is responsible | Triage |
| In progress | Developer is working on it | Developer |
| Resolved / Ready for retest | Fix done, available in a build (fix version) | Developer |
| Closed / Verified | You retested and it works | You |
| Reopened | Retest failed, bug still there | You (with evidence) |
| Rejected / Works as designed | Not a bug | Triage / developer (with explanation) |
| Duplicate | Same as another ticket; linked | Triage or you |
| Deferred / Postponed | Real, but fixed later | Product owner |
| Cannot reproduce / Need info | Developer can't see it; needs more data | Developer → back to you |
After you create a ticket: tracking it
- Watch the ticket (Jira notifications) and check your filter/dashboard daily.
- Attend or follow triage: be ready to explain and demonstrate.
- Answer developer questions fast; add logs if they ask.
- When it's "Ready for retest": check the fix version and release notes — is the fix really in your build?
- Retest the exact steps, then test around it (neighbouring cases) and run regression for the affected area.
- Update the ticket: "Verified in 24.3.2 on bench B-03; TC-03/04 pass; regression of temperature tests pass" → Close. Or Reopen with new evidence.
How do you know whom to assign it to?
- Use the project's component ownership list (which team owns Media, Bluetooth, Cluster…) and set the component field.
- In many projects you don't assign to a person at all: the triage team / proxy team dispatches it.
- Use evidence: the CAN trace shows whether the input was right. Right input + wrong screen → HMI team. Wrong value on the bus → the sending ECU's team or supplier.
- Never guess a random developer; ask your lead if unsure.
Duplicates and many testers
If two testers find the same bug, there must be one ticket, not two. Duplicates waste developer time, split the information, and mess up the bug statistics.
How to check before creating
- Search Jira: component + keywords ("snowflake", "ice warning", "5.0"), error messages from the log, open status. Example JQL:
project = IVI AND text ~ "snowflake" AND status != Closed - Check the known issues list in the release notes.
- Ask in the team chat: "Has anyone seen X on 24.3.1?"
If it already exists
- Don't create a new one. Add a comment with your new information: another build, another bench, another frequency, extra logs. This makes the existing ticket stronger.
- If your case differs (other trigger, other screen), create a new ticket and link it as "related".
How teams avoid duplicates
- Split feature ownership: one tester per area.
- Daily stand-up: mention new bugs you found.
- Shared "found today" chat or board.
- Triage marks duplicates and links them to the original.
"No, one ticket. Before creating a ticket I search Jira and the known-issues list. If it exists, I add my evidence as a comment — my build, bench and how often I saw it — which helps the developer. Duplicates waste triage time and split the information."
When NOT to raise a new ticket
The interviewer asked: "Even when you're sure you found a bug, are there situations where you shouldn't create a ticket?" Yes. Follow this decision path:
| Situation | What to do instead |
|---|---|
| Already reported (duplicate) | Comment on the existing ticket with new evidence; link |
| Behaviour matches the requirement ("works as designed") | No defect. If the behaviour is bad for users, ask the requirement owner or raise a change request |
| Caused by the test environment / hardware (wrong build flashed, loose cable, wrong CAN config, broken USB hub) | Fix the environment and re-run; record as environment issue; test = Blocked until fixed |
| Known issue listed in the release notes | Link your test result to it; no new ticket |
| Feature not implemented in this build yet | Check release notes/feature list; mark test "not applicable yet" or blocked |
| Seen once, no evidence, can't reproduce | Note it, watch for it, turn on extra logging; raise when you have data (some projects want a ticket anyway — follow the process) |
| Many tickets in the system, many testers | Search first; coordinate in the team; one owner per area |
"Yes. I don't raise a new ticket if it's already reported — then I add my evidence to the existing one; if the behaviour is actually as specified — then I clarify with the requirement owner; if the test environment caused it — then I fix the bench and re-run; or if it's a known issue in the release notes. With many testers on the same software, searching first and coordinating avoids duplicates."
Environment problem or product bug?
A big part of the job is telling these apart. Checks:
- Is the right build flashed? (compare version on screen with the planned one)
- Does it happen on another bench too?
- Are cables, power supply, USB hub, antenna, phone OK? Is the CAN configuration/DBC the right version?
- Did it work on the previous build on the same bench? (If yes and nothing changed on the bench, it's probably the software.)
- Do the logs show hardware errors (e.g. "USB device not found")?
Intermittent bugs ("sometimes it happens")
- Try to find the pattern: after sleep? only the first time? only with a certain phone? only when fast?
- Run it many times (manually or with automation) and count: "3 out of 20".
- Keep logging and tracing running all the time, so when it happens you have the data.
- Report with the rate and all the conditions you know; mark it as intermittent.
Bug caused by another component or supplier
- Collect proof where it comes from (e.g. trace shows the sending ECU transmits the wrong value).
- Assign/move the ticket to that component, or raise it in that team's/supplier's system as the process says.
- Link the tickets, inform the proxy team.
- Mark your test as failed or blocked, with the link.
When a developer says "not a bug"
- Stay calm and factual. Go back to the requirement: quote its ID and exact text.
- If the requirement is unclear, involve the requirement owner / proxy team to decide.
- Show evidence (video, trace). Offer to demonstrate on the bench.
- Accept the decision when it's made and documented; if the requirement is bad, suggest a change request.
Jira in practice
Issue types and important fields
Issue types: Bug, Task, Story, Epic (plus test types if Xray is used: Test, Test Set, Test Plan, Test Execution). Fields: Summary, Description, Component, Affects Version, Fix Version, Priority, Severity (custom), Labels, Assignee, Reporter, Attachments, Links.
JQL: searching Jira
| You want | JQL |
|---|---|
| My tickets ready to retest | reporter = currentUser() AND status = "Ready for Test" |
| Open cluster bugs, most important first | project = IVI AND issuetype = Bug AND component = Cluster AND status != Closed ORDER BY priority DESC |
| Search for a duplicate | project = IVI AND text ~ "snowflake" AND status != Closed |
| Critical bugs from the last 7 days | project = IVI AND priority in (Blocker, Critical) AND created >= -7d |
| Bugs fixed in a build | project = IVI AND fixVersion = "24.3.2" AND status in (Resolved, "Ready for Test") |
Save useful searches as filters and show them on a dashboard (charts of bugs by status/severity).
Xray / Zephyr (tests inside Jira)
These add-ons store test cases and test executions in Jira. You create a Test Execution for a build, run each test, set PASS/FAIL, attach evidence, and link failed tests to bug tickets. This gives traceability: requirement ↔ test ↔ execution ↔ defect.
Quick answers for the interview
How do you track a bug after creating the ticket?
I watch it and use a Jira filter for my open tickets. I follow it through triage, answer questions quickly and add logs if needed. When it's ready for retest, I check the fix is in my build, retest, test around it, run the related regression, and then close it with a comment or reopen it with evidence.
How do you determine severity and priority?
Severity from the impact: safety or legal relevance, whether a function is lost, if there's a workaround, how often and how visible. I propose the severity; the priority is decided with the project or product owner, based on release plans and customer impact, usually in triage.
What would you do if the failure is caused by the test environment?
I verify it first: check the flashed build, try another bench, check cables, power and configuration. If it's the environment, I don't raise a software defect. I fix or report the bench problem, mark the affected tests as blocked, and re-run them when the environment is fixed, noting it in the execution report.
When would you close, reject or link a defect instead of creating a new one?
Close: after a successful retest. Reject: when it works as designed, is caused by the environment, or can't be reproduced after investigation. Link: when it's a duplicate or related to an existing ticket, or its root cause is in another component's ticket.