Interview questions & answers (130)

Short answer: "I'm a test engineer with [X] years' experience in [domain]. I do manual functional and regression testing, write test cases from requirements, report defects in Jira and support automation with Python and Robot Framework. I'm ISTQB Foundation certified and I enjoy HMI testing because every detail the driver sees matters."

Use the 4-part formula: who you are → what you do daily → one achievement → why this job. Keep it under 90 seconds. Full templates are on the Final prep page.

Short answer: "I got it in [month/year]. I use it every day: test design techniques like boundary values and equivalence partitioning to write test cases, the test process (plan, design, execute, report) to organise my work, and the shared vocabulary — defect, failure, regression, severity — to communicate clearly with developers."

Give one concrete example: "When I tested the [volume / temperature] setting, I used BVA and tested min, min+1, max−1 and max. That found a bug at the maximum value."

Not certified yet? Say: "I'm preparing for it / I've studied the syllabus, and I already apply its techniques." Never claim a certificate you don't have — it's checked.

Short answer: "Three ways: I write fewer but better test cases using techniques instead of guessing; I write clearer bug reports because I separate defect from failure and severity from priority; and I talk to developers and managers in the same standard terms, so there's less confusion."

Extra point: it taught me testing is risk-based — you can't test everything (principle 2, "exhaustive testing is impossible"), so you test the most important and risky parts first.

Short answer: "The role is manual testing of automotive HMI — cluster and infotainment — on test benches, with defect reporting in Jira, regression testing, and supporting test automation with Python and Robot Framework. The quality of the HMI directly affects driver safety and brand image, which is why I like it."

Before the interview, look at the company website: which OEMs they work for, their products, their locations. Mention one fact.

Short answer: "Cars are becoming software products. The HMI is where the driver meets that software, so bugs are visible and can be safety-relevant. I like work where precision matters, and automotive has strong processes — V-model, ASPICE, traceability — that make me a better engineer."

Short answer: "Strength: I'm very detail-oriented — I notice small UI inconsistencies like wrong units or cut-off text, and I write reproducible bug reports. Weakness: I used to spend too long investigating one bug. Now I time-box analysis to about 30 minutes, then raise the ticket with what I have and keep adding information."

Always pair a weakness with what you are doing to fix it. Never say "I have no weakness" or "I'm a perfectionist".

Short answer: "Testing finds defects in the product (product-focused, corrective). Quality assurance improves the process so fewer defects are made (process-focused, preventive). Testing is part of quality control, which sits under quality management."

Short answer: "Deeper in automotive testing: strong in HMI and CAN/diagnostics, doing more automation with Python and Robot Framework, and taking responsibility for a feature area — planning its tests and guiding newer testers. Maybe ISTQB Advanced or the automotive tester certificate (CTFL-AuT)."

Short answer: "Yes, I tested [infotainment / cluster / mobile / web UI]. For example [media, Bluetooth phone, navigation, settings, warnings]. I checked function (does it work), display (texts, icons, units, layout), behaviour (transitions, timing, touch response) and robustness (power cycles, disconnects, fast inputs)."

If your HMI experience is from mobile/web apps: "My UI testing was on [mobile/web], but the skills transfer directly: checking layout, texts, states, localisation and user flows. I've studied automotive specifics such as telltales, CAN signals and driver distraction rules."

Short answer: "Examples: [cluster speed and warnings / media USB and Bluetooth / phone calls / radio / navigation / climate / settings and language / rear camera]. For each I tested normal flows, boundaries, error cases and interruptions — like an incoming call during navigation."

See the HMI chapter for a test list per feature, so you can speak about any of them.

Short answer: "In a team of [N] testers and [M] developers, working in Scrum with 2-week sprints. We had daily stand-ups, sprint planning and a review. Features were split between testers, and a test lead handled the release reports. I worked closely with developers on bug analysis."

Mention roles: product owner (priorities), Scrum master, developers, testers, test lead/manager, and the customer (OEM).

Short answer: "Mostly a test bench on my desk: the real head unit or cluster ECU, a power supply, a CAN interface with CANoe to simulate the rest of the car, plus USB and a phone. Sometimes we used remote benches through a PC connection and camera, and we booked them in a shared calendar."

Bonus: "Before testing on a remote bench, I check the software version, power state and that nobody else is using it."

Short answer: "For each telltale I check: it switches on when the signal requests it and off when it stops; the colour is right (red = danger, amber = warning, green/blue = info); the timing is within spec; the bulb check at start-up works; the priority is right when several warnings come; and it behaves safely on signal loss (timeout, invalid value)."

The full 12-point checklist is on the HMI page.

Short answer: "I simulate the failure: stop sending the CAN message (timeout), send the invalid / SNA value (like 0xFF), send out-of-range values, and physically unplug the sensor if possible. I check the display shows the defined fallback — usually dashes '---' or a 'sensor fault' warning, never a frozen old value — that a DTC is stored, and that it recovers when the signal comes back."

1. Read the requirement for signal failure: timeout time (e.g. 500 ms), what to show.
2. Normal state first: check the value shows correctly.
3. Cause the failure in CANoe: disable the message or set it to SNA.
4. Measure: after how long does the display react? Is the text right?
5. Recover: restart the message; does it go back to normal?
6. Evidence: CAN trace + photo/video + DTC read-out.

Short answer: "A power supply (12 V, with KL30 and KL15), the DUT (head unit or cluster), a CAN/LIN interface like Vector VN1630 with CANoe to simulate other ECUs, a display or the real screen, USB sticks and phones for media and Bluetooth, a debug connection for logs (DLT, ADB or serial), and a flashing tool to load new software."

A bench diagram is in Car basics.

Short answer: "Hardware: power supply, DUT, Vector CAN interface, USB media, phones, sometimes a HIL rack. Software: CANoe/CANalyzer for bus simulation and traces, DLT Viewer or ADB logcat for logs, Jira for bugs, Xray/Polarion for test cases, Python/Robot Framework for automation, and a flash tool for software updates."

Short answer: "I note the exact time the bug happened, then open the logs around that time: the CAN trace to see if the input signal was correct, and the ECU log (DLT or logcat) to see errors, warnings or crashes. If the input was right but the display was wrong, it's an HMI bug; if the input was already wrong, it's the sender. I attach the log part to the ticket."

Steps and examples: Tools & logs.

Short answer: "CAN is the network that lets ECUs in a car talk to each other. The cluster gets speed, warnings and temperatures as CAN signals. As a tester I use CANoe to send those signals (simulate the car) and to read the trace, so I can tell whether a wrong display comes from a wrong input or from the HMI."

Short answer: "A DBC is the dictionary of the CAN bus. It lists every message (ID, length, cycle time) and every signal inside it (start bit, length, factor, offset, unit, min/max). The tool uses it to turn raw bytes into real values: real = raw × factor + offset."

Example: raw 0x64 = 100, factor 0.5, offset −40 → 100 × 0.5 − 40 = 10 °C. Try the decoder on the Car basics page.

Short answer: "KL30 is permanent battery power, always on. KL15 is ignition — on when the key/start button is on. KL31 is ground. On the bench we switch KL15 to test start-up, shutdown and sleep behaviour."

Short answer: "SIL (software-in-the-loop): the software runs on a PC with simulated inputs — fast and cheap, early. HIL (hardware-in-the-loop): the real ECU is connected to a simulator that pretends to be the car — realistic and repeatable. Vehicle testing: in the real car — most realistic, but expensive and late."

Short answer: "Rules and guidelines (like AAM or NHTSA guidelines) limit what the driver can do while driving. For example, typing a destination, watching video or scrolling long lists is blocked above a speed like 5–8 km/h. I test that these functions lock at the speed threshold, show a message, and unlock when stopped."

Short answer: "First I analyse the requirement and ask questions if something is unclear or untestable. Then I plan (scope, environment, effort), design test cases with techniques like BVA and link them to the requirement, prepare the bench, execute and report bugs, retest fixes and run regression, and finally write the test report with a release recommendation."

1. Requirement analysis — read the spec, check it is clear, complete and testable. Ask: "Below 5 °C — is 5.0 included?" Record questions.
2. Test planning — what to test, what not, which bench, which software version, effort, risks, entry/exit criteria.
3. Test design — write test cases (preconditions, steps, expected results) using EP, BVA, state transition. Link each to the requirement ID (traceability).
4. Environment setup — flash the software, configure CANoe, check the bench works (smoke test).
5. Execution — run tests, mark pass/fail/blocked, collect evidence, raise defects in Jira.
6. Defect follow-up — retest fixes, run regression around the change.
7. Reporting & closure — test report: coverage, results, open bugs with risk, recommendation (release / release with known issues / don't release).

This is the STLC (software testing life cycle). Details: Testing basics.

Short answer: "I check it is clear (one meaning), complete (all cases, including errors), consistent (doesn't contradict other requirements), testable (measurable expected result) and feasible on our bench. I write down open questions and clarify them with the requirement owner before I design tests."

Example of an untestable requirement: "The warning should appear quickly." Better: "within 500 ms after the signal".

Short answer: "I check whether the bench can create the inputs (can we simulate that signal? do we have that phone, that sensor?) and observe the outputs (can we see or measure the result? do we have logs?). If not, I raise it early: we may need a new simulation, extra hardware, a HIL, or a vehicle test — and I note it as a risk in the plan."

Short answer: Same as Q23. Say each step with one output: requirement → list of questions; plan → test plan; design → test cases + traceability; setup → working bench with the right software; execution → results + defects; reporting → test report + recommendation.

Short answer: "Yes. Each test case run gets a status (pass, fail, blocked, not run), the software version, bench, date and tester. Failed tests are linked to the Jira defect. I attach evidence — screenshots, videos, CAN traces, logs. At the end we create a test report from the tool."

Short answer: "[Jira with Xray / Zephyr, Polarion, TestRail, ALM, or Excel]. Automated results come from Robot Framework's output.xml, log.html and report.html, often published through Jenkins."

Short answer: "Mainly Jira. I know others exist: Polarion, Azure DevOps, Bugzilla, Redmine. The idea is the same: a ticket with a life cycle, fields, links and history."

Short answer: "Software version and scope tested; test environment; how many tests passed, failed, blocked and not run; requirement coverage; list of open defects with severity and risk; what was not tested and why; and a release recommendation."

Short answer: "I compare the results with the exit criteria — for example: all critical tests executed, no open critical/blocker bugs, regression passed. Then I state the facts and risks: 'Release with 2 known minor issues' or 'Not recommended: 1 critical bug in the rear camera'. The final decision belongs to the project/release manager, but my data drives it."

Short answer: "Entry criteria: conditions to start testing — stable build flashed, smoke test passed, test cases ready, bench available. Exit criteria: conditions to stop — planned tests executed, coverage reached, no open critical defects, report done."

Short answer: "The document that says what, how, who, when for testing: scope (in/out), approach and test levels, environment, schedule, roles, entry/exit criteria, risks, deliverables."

Short answer: "A unique ID, clear title, link to the requirement, preconditions, numbered steps, a precise expected result for each step, test data, and priority. Anyone should be able to run it and get the same verdict."

Short answer: "A scenario is what to test, in one line: 'Check an incoming call during navigation.' A test case is how, in detail: preconditions, steps, data and expected results. One scenario usually becomes several test cases."

Short answer: "Traceability means every requirement is linked to its test cases, and every test result and defect is linked back. I create the links in the tool (Polarion/DOORS/Jira-Xray) when I write test cases, and I check the traceability matrix for requirements without tests. When a requirement changes, the links show which tests to update."

Short answer: "[Polarion / IBM DOORS / Jira with Xray / codeBeamer]. In automotive, requirements often come from the OEM in DOORS or Polarion; test cases link to the requirement ID."

Short answer: "A development model where every design step on the left has a matching test level on the right: requirements ↔ acceptance/system test, architecture ↔ integration test, detailed design ↔ unit test. It means test planning starts early, together with each design step. Automotive uses it through ASPICE."

Short answer: "[Robot Framework with Python libraries, pytest, python-can for CAN, CANoe test modules / CAPL, Jenkins for scheduled runs]. My role was [writing and maintaining test scripts / running suites and analysing failures]."

At 1–2 years, it's fine to say: "I mainly executed and analysed automated suites, and I wrote or updated simple test cases."

Short answer: "For small helper scripts: sending and reading CAN messages with python-can and cantools, parsing logs to find errors, comparing results, generating test data, and writing custom Robot Framework keywords."

Example scripts are on the Automation page.

Short answer: "Robot Framework is a keyword-driven framework: tests are readable steps like Set Vehicle Speed 50. I've [written test cases, used tags to select suites, run them from the command line, and analysed log.html for failures]. Keywords come from libraries, often our own Python libraries for CAN or the HMI."

Short answer: "Every run creates three files: output.xml (all raw results, machine-readable), log.html (step-by-step details with errors and screenshots) and report.html (the summary with pass/fail per test and tag). You can merge several runs with rebot, and Jenkins shows the trends."

Short answer: "Robot files (output.xml, log.html, report.html), CAN traces (.blf/.asc), ECU logs (DLT/logcat/serial), screenshots or videos, the software version and bench configuration, and any DTCs read from the ECU."

Short answer: "I open log.html and find the failing step and message. Then I decide: is it a real product bug, a script problem (wrong locator, timing), an environment problem (bench, power, network) or a flaky test? I re-run it manually to confirm. Only real product bugs go to a Jira defect; script issues I fix or report to the automation owner."

Short answer: "A test that passes and fails on the same software without changes — often due to timing, waits or unstable benches. I don't ignore it: I analyse the cause, replace fixed sleeps with 'wait until' checks, and quarantine it (tag it) until it's fixed so it doesn't hide real failures."

Short answer: "Automate tests that are repeated often (regression, smoke), stable, data-driven, or need precise timing. Keep manual for new or changing features, exploratory testing, visual and usability checks, and one-off tests."

Short answer: "Jenkins is a CI server: it automatically builds software, flashes the bench and runs test suites — for example every night or after each build — then publishes the Robot reports. So we get fast feedback without starting tests by hand."

Short answer: "I create a Bug with all fields (summary, steps, expected/actual, version, severity, attachments), link it to the test case and requirement, and follow it through the workflow (Open → In Progress → Resolved → Verify → Closed). I use JQL filters and dashboards to see my open bugs and bugs waiting for retest."

Example JQL: project = IVI AND status = Resolved AND reporter = currentUser()

Short answer: "CANoe from Vector is the main tool for CAN, LIN and automotive Ethernet. I used it to simulate other ECUs (send signals like speed or temperature), view the trace, use panels to change values, and log data. CAPL is its scripting language for automation inside CANoe."

Short answer: "DLT (Diagnostic Log and Trace) is the AUTOSAR/GENIVI log format; we view it in DLT Viewer. ADB logcat shows logs from Android-based head units. Both show timestamps, app/context IDs and log levels (error, warning, info, debug) to find what happened when the bug appeared."

Short answer: "False positive: the test reports a failure but there is no product bug (e.g. script or bench issue). False negative: the test passes but a bug really exists — more dangerous because we miss it."

Short answer: "With the project's flash tool — e.g. vFlash over CAN/Ethernet via UDS, or a USB update for head units. After flashing I verify the version (in the engineering menu or via diagnostics), do a power cycle and a quick smoke test before real testing."

Short answer: "A clear summary (where + what), environment (software version, hardware, bench), preconditions, numbered steps to reproduce, expected result (with requirement ID) and actual result, reproducibility (e.g. 5 of 5), severity/priority, attachments (photo/video, CAN trace, logs with timestamp), and the component and links."

Good summary: "[Cluster] Snowflake icon shown at 5.0 °C — should appear only below 5 °C". Bad summary: "Snowflake wrong". Full example: Defects page.

Short answer: Same 12 fields as Q53 — also mention Jira fields: Project, Issue type = Bug, Component, Affects Version, Labels, Assignee, Linked test case/requirement, and the time stamp of the failure so developers find it in the logs.

Short answer: "I watch the ticket and use a filter/dashboard of my open bugs. I answer developer questions quickly and add logs if they ask. I follow status changes, join the bug triage meeting if needed, and when it's Resolved with a fix version, I retest on that build and close or reopen it."

Short answer: "By the component: the project has a component list with owners (e.g. Media → media team). Jira often auto-assigns by component. If unsure, I assign to the team lead or triage owner of that area, or ask my test lead. I never guess an individual developer randomly."

Short answer: "I use the logs to narrow the cause: if the CAN input is wrong, it's the sending ECU; if the input is right but the display is wrong, it's the HMI. Then I check the component owner list or the architecture document, and confirm in triage."

Short answer: "Link it to the test case, mark the test as failed, inform the team if it's critical or blocking, follow up in triage, support the developer with information, then retest the fix and run regression around it."

Short answer: "First I check the fix is in the build I'm testing (fix version). Then retesting (confirmation testing): I run the exact steps from the ticket — if it works, I close it; if not, I reopen with new evidence. Then regression testing around the change to make sure the fix didn't break anything else. If it's an important bug, I suggest adding a test to the regression suite."

1. Check the build contains the fix (release notes / fix version).
2. Retest with the original steps, same conditions. Try the variations too (the edge values).
3. Regression of related features (impact analysis: what else does that code touch?).
4. Update the ticket: "Verified in build 2.4.1, 5/5 OK, video attached" → Closed. Or Reopen.
5. Update the regression suite if needed.

Short answer: "Retesting checks that the bug itself is fixed — same steps, planned, on failed tests. Regression testing checks that the change didn't break other things that worked before — on passed tests, often automated."

Short answer: "Through impact analysis: I ask the developer what code was changed and which features use it, then run regression for those features plus a general smoke test. For example, a fix in Bluetooth audio → I retest Bluetooth phone calls, media streaming, source switching and voice control."

Short answer: "I collect proof from the logs (e.g. the CAN trace shows the wrong value coming from the sending ECU), then raise or move the ticket to that component's team, with the evidence. I link it to my test case, mark the test as blocked or failed with the link, and follow up. I don't just close it as 'not our problem'."

Short answer: "Severity = how bad the impact is on the system (tester decides): Blocker, Critical, Major, Minor, Trivial. Priority = how soon it must be fixed (business/project decides): P1–P4. In automotive, anything safety-related (wrong speed, missing warning, rear camera) is at least Critical."

Classic examples: High severity, low priority — crash in a rarely used engineering menu. Low severity, high priority — wrong brand logo at start-up before a car show.

Short answer: "New → Open/Assigned → In Progress → Resolved/Fixed → Retest → Closed. Side paths: Reopened (fix doesn't work), Rejected (not a bug), Duplicate, Deferred (fix later), Cannot reproduce."

Short answer: "I try again myself on a clean setup, then compare our environments: software version, bench, phone model, settings, signal values. I add missing details, a video and logs, and offer to show it live on my bench. If it's intermittent, I state the rate (e.g. 2 of 10) and the conditions I noticed."

Short answer: "I keep logging on all the time, note the exact time, repeat the steps many times and write the rate (3/20). I look for a pattern: temperature, time after start-up, a specific phone, fast inputs. I raise the ticket even if it's intermittent, with all logs, because rare bugs still happen in customer cars."

Short answer: "I go back to the requirement, because it decides — not opinions. If the requirement supports me, I show it. If the requirement is unclear, I ask the requirement owner / product owner to clarify, and we update the requirement. I stay factual and polite: we both want a good product."

Short answer: "I report it immediately — ticket plus a direct message or call to my lead and the developer — with clear evidence and the impact. I don't wait for the daily meeting. Management decides whether to delay the release or accept a workaround, but they need the information fast."

Short answer: "Finding the real origin of a defect, not only the symptom — for example the wrong text was caused by a missing translation key, which was caused by no review step. Tools: the 5 Whys and fishbone diagrams. It helps prevent similar bugs."

Short answer: "A human makes an error (mistake) → it creates a defect (bug) in the code or document → when that code runs, it may cause a failure (the wrong behaviour we see)."

Example: developer typed <= instead of < (error) → wrong condition in code (defect) → snowflake shows at exactly 5 °C (failure).

Short answer: "I use layers. For every new build: an automated smoke test (does it start, basic functions work). For each fix: targeted regression based on impact analysis. Every sprint or release candidate: the core regression suite with high-priority tests. Before a big release: the full regression. I choose tests by risk: safety-relevant, often-used, recently changed and historically buggy areas first. As much as possible is automated and runs nightly."

Short answer: "By risk and impact. I pick: (1) safety-critical functions — telltales, speed, rear camera, warnings; (2) areas changed in this build and the areas connected to them; (3) most-used customer functions — phone, media, navigation; (4) areas with many past bugs; (5) tests for fixed critical bugs; (6) customer or legal requirements. I give tests priorities P1/P2/P3 and run P1 always, P2 if time allows, P3 in the full cycle."

Follow-up "what about criticality of bugs?" → "Tests for critical and major fixed bugs go into regression; tests for trivial cosmetic bugs usually don't. The more critical the old bug, the higher the test priority."

Short answer: "No. Regression time is limited, and a suite with thousands of small checks becomes too slow to run. I add a fixed bug's test when the bug was severe, safety-related, customer-visible, in a frequently changed area, or has come back before. I don't add it for trivial cosmetic bugs, one-time issues (like a wrong build config), or when an existing test already covers it."

Short answer: "The rear-camera image froze when reversing right after an incoming call. It's safety-relevant (FMVSS 111), it involves two features interacting, and that code changes often. I'd add a test so it can never come back unnoticed."

Other good examples: speed shown wrong at a unit change; warning not shown after sleep/wake; a crash when a specific phone connects; a bug that already came back once.

Short answer: "A typo in a rarely used engineering menu text. It's cosmetic, not customer-visible, and the text-check tests already cover all strings. Adding a separate test only makes regression slower."

Other examples: a bug caused by a wrong test-bench configuration; a bug in a feature that is being removed; a bug already covered by an existing test case.

Short answer: "Safety first, then changed areas, then most-used functions, then everything else. I use the P1/P2/P3 tags, run the automated suite in parallel overnight, and spend manual time on what automation can't cover. I tell the lead clearly what was not tested, so the risk is known."

Short answer: "Safety-critical tests are always run and never cut: telltales, speed display, warnings, rear camera, driver-distraction lock-outs, eCall. Non-critical ones (themes, wallpapers, cosmetic texts) are prioritised by usage and change risk and can move to the next cycle."

Short answer: "In the morning I do impact analysis with the release notes, then pick: smoke + all P1 safety tests + tests for changed areas + top customer flows. Automation runs in parallel. I report at mid-day and at the end with what passed, failed, and what's left untested, so the team can make a risk-based decision."

Short answer: "I don't skip testing silently. I agree a reduced, risk-based scope with the lead: safety and changed areas first. I report daily, write down the residual risk (what wasn't tested), and the release manager decides. After the release, we run the remaining tests and fix anything found in a maintenance release."

Short answer: "Finding out which parts of the system a change can affect. I use the release notes, the changed components, the developer's explanation and the traceability links, then choose regression tests for those areas."

Short answer: "Smoke: a wide but shallow check on every new build — does it boot, do the main functions work at all? If it fails, the build is rejected. Sanity: a narrow, deeper check of one area after a small change or fix — is that area logically working?"

Short answer: "Review it regularly: remove obsolete and duplicate tests, update tests when requirements change, fix flaky automated tests, add tests for important fixed bugs and new features, and check that execution time stays within the budget."

Short answer: "No. One problem = one ticket. Duplicates waste developer time, split the discussion and make bug statistics wrong. The second tester adds a comment to the existing ticket with extra information — another software version, another bench, a new log — which helps the developer."

Short answer: "Before creating a ticket I search Jira with key words (e.g. 'snowflake', 'outside temperature'), the component and recent dates, and check the known-issues list and release notes. I also ask in the team chat. If I find it, I comment and link; if it's slightly different, I create a new one and link it as related."

Example JQL: project = IVI AND component = Cluster AND text ~ "snowflake" AND status != Closed

Short answer: "(1) Search before creating. (2) Use a standard summary format ('[Component] What – where') so searches find it. (3) Split test areas between testers. (4) Share new findings in the daily stand-up or team chat. (5) A triage owner reviews new tickets daily and marks duplicates."

Short answer: Same as Q62: prove it with logs, move the ticket to the right team (or create one there and link), inform both teams, and follow up until it's fixed.

Short answer: "I share facts: exact steps, logs, time stamps, video. I offer to reproduce it together on the bench. I check with other testers whether they've seen it on other benches or versions. Tone matters: I talk about the problem, not the person."

Short answer: "Everyone must use the same defect database or a synchronised one, a common naming convention and clear variant info (which OEM, which car line, which software). We search before raising, link cross-team tickets, and a triage board decides ownership. Bugs found by the OEM often come through their system and are mirrored to ours."

Short answer: "Yes: (1) it's already reported — I comment on the existing ticket instead; (2) it's expected behaviour per the requirement (or a known limitation); (3) the problem is the test environment — bench, wrong software, wrong configuration, simulation error; (4) the feature is not yet implemented in this build (check the release notes); (5) it's already listed as a known issue. In those cases I comment, fix the setup, or ask for a requirement clarification."

The interviewer's hints were "lots of tickets in the system" and "several testers testing at the same time" — both point to duplicates. Say that first.

Short answer: "I don't create a new one. I add a comment with my details (version, bench, reproduction rate, logs), vote/watch it, and link my failed test case to it. If it's closed but happening again, I reopen it (or create a new one linked to it, as the project rules say)."

Short answer: "No defect. If I still think it's bad for the user — for example confusing — I raise it as an improvement / change request or ask the product owner, not as a bug. And I update my test case if my expected result was wrong."

Short answer: "No product defect. I fix the setup (reflash, correct CANoe config, change the cable/power supply) and rerun. If the bench itself is broken, I report it to the lab/bench owner or raise an environment ticket, and mark my tests as blocked, not failed."

How to tell: does it happen on another bench? With the correct software? With a known-good input? If not → environment.

Short answer: "Close: fix verified. Reject (or ask to reject): not a bug — expected behaviour, environment issue, cannot reproduce after good effort. Link: same or related problem already exists — mark as duplicate or 'relates to', or 'is caused by' another component's ticket."

Short answer: "I change one thing at a time: try another bench, reflash the correct software, check cables and power, check the CANoe simulation sends correct values, compare with a colleague. If the problem stays with the product software on a known-good setup, it's a product bug."

Short answer: "Stay factual and neutral: 'I see X, the requirement says Y, here is the video and the log.' No blame words. Offer to show it on the bench. If we still disagree, escalate to the requirement owner — the spec decides, not who is louder."

Short answer: "A regular meeting (or process) where leads, developers and testers review new defects: confirm it's valid, find duplicates, set priority and owner, and decide which release it's fixed in."

Short answer: "Report it straight away to the bench owner and my lead, mark tests as blocked, try a remote or spare bench, and use the time productively: review requirements, write or update test cases, analyse logs from earlier runs, or update automation scripts."

Short answer: "BVA is a black-box technique that tests at and around the edges of valid ranges, because developers often make mistakes there — like < instead of <=. For a range 16–28 °C, I test 15.5, 16, 16.5 and 27.5, 28, 28.5 (with a 0.5 step). In the 2-value version I take the boundary and its nearest neighbour; in the 3-value version, the boundary and both neighbours."

Short answer: "First I'd point out that the requirement overlaps: 'appears below 5' and 'disappears at 4 or above' conflict between 4 and 5 °C (at 4.5 °C, is it ON or OFF?). I'd clarify it — usually it's meant as hysteresis, e.g. ON at 4 °C or below, OFF at 5 °C or above, keeping the last state in between. Then I test both boundaries with the signal resolution (0.1 °C): 3.9, 4.0, 4.1 and 4.9, 5.0, 5.1, in both directions (cooling down and warming up), plus normal values, flicker around the boundary, and a missing/invalid signal."

If they confirm the simple rule "ON below 5 °C", the key values are 4.9 → ON, 5.0 → OFF, 5.1 → OFF, plus normal values like 3 °C and 6 °C. The must-say point: don't only test 0 °C and 10 °C — BVA means testing at and right next to the boundary.

Full step-by-step explanation and a live simulator: Test design → snowflake.

Short answer: "Cars are full of thresholds: warning temperatures, speed limits for driver-distraction lock-out, low fuel, tyre pressure, battery levels. Most threshold bugs sit exactly at the boundary. BVA finds them with few test cases, which saves bench time."

Short answer: "EP divides inputs into groups that should behave the same, and tests one value per group (e.g. −10 °C for 'cold', 20 °C for 'warm'). BVA then tests the edges between the groups (4.9, 5.0, 5.1). They're used together: EP for coverage, BVA for the risky edges."

Short answer: "With 2-value BVA: 2 per boundary (the boundary value and its closest neighbour on the other side). With 3-value BVA: 3 (just below, on, just above). For safety-relevant thresholds I use 3-value."

Short answer: "It's exactly the boundary value 5.0. 'Below 5' = temp < 5 → at 5.0 the snowflake is OFF. '5 and below' = temp <= 5 → at 5.0 it's ON. That's why testing exactly 5.0 is the most important value."

Short answer: "Start cold so the snowflake is ON. Raise the temperature in small steps using CANoe (e.g. 0.1 °C), hold each value a few seconds (longer than any filter/debounce time), and record the exact value where the icon turns off. Compare with the requirement. Keep the CAN trace and video as evidence."

Short answer: "Start warm so it's OFF, lower in 0.1 °C steps and record where it turns on. The two directions can switch at different values — that's hysteresis, used so the icon doesn't flicker when the temperature hovers around one value. I also test it hovering: 4.9 ↔ 5.1 repeatedly — the icon must not flicker."

Short answer: "It's a defect (probably <= instead of <). I first confirm: repeat it, check in the CAN trace that the value sent is really 5.0 (not 4.96 rounded to 5.0), and check the requirement version. Then I raise a ticket with the evidence."

Short answer:

Short answer: "A table of all combinations of conditions and the expected action. Example seatbelt warning: conditions = seat occupied? belt buckled? speed > 25 km/h? → 2×2×2 = 8 rules, each with 'warning yes/no'. It makes sure no combination is forgotten."

Short answer: "Testing a system that has states and events that move it between them. Phone call: Idle → Ringing (incoming call) → Active (accept) → Held → Active → Idle (end). I test every valid transition and also invalid ones (e.g. 'end call' while idle) to check nothing strange happens."

Short answer: "Error guessing: using experience to guess where bugs hide — long names, special characters, fast double-taps, power loss during an update. Exploratory testing: learning, designing and testing at the same time, without a script, usually time-boxed (e.g. 60-minute session with a goal) and with notes."

Short answer: "EP: valid 0–40, invalid <0 and >40. BVA: 0, 1, 39, 40, and try to go below 0 and above 40 (must stay at 0/40). Plus: volume keeps after power cycle, each source keeps its own volume if specified, the steering-wheel button and touch slider give the same result, the mute button, and fast repeated presses."

Short answer: "Pairing (first time, PIN confirmation), auto-reconnect after restart, several phones and brands (iPhone, Samsung, Pixel), calls (incoming, outgoing, reject, hold, two calls), contacts and call-history sync, audio quality, media streaming and metadata, connection loss and reconnection, and max number of paired devices. Plus interruptions: call during navigation announcement, reverse gear during a call."

Short answer: "Image appears within 2 s of selecting reverse (FMVSS 111), from any screen and even during start-up; guidelines move with the steering angle; image disappears when leaving reverse (after a defined time or speed); it overrides other pop-ups; behaviour when the camera is disconnected (error message, not a frozen image); day and night quality."

Short answer: "Change the language and check every screen: all texts translated (no English left, no text keys like TXT_MENU_01), no cut-off text (German is ~30% longer), correct formats for date, time, decimal and units, special characters (ä, ñ, ж), right-to-left for Arabic/Hebrew, and the language stays after a restart."

Short answer: "1) Testing shows defects are present, not that there are none. 2) Exhaustive testing is impossible. 3) Early testing saves time and money. 4) Defects cluster together. 5) Tests wear out (pesticide paradox) — update them. 6) Testing depends on context. 7) Absence-of-errors fallacy — bug-free but useless is still a failure."

Short answer: "Component (unit) — one piece of code, by developers. Integration — pieces working together. System — the whole product against requirements (where HMI testers mostly work). Acceptance — does it meet the customer's needs."

Short answer: "Functional: what the system does — the call connects, the warning appears. Non-functional: how well — start-up time, touch response time, memory, reliability, usability."

Short answer: "Black-box: testing from the requirements without looking at the code (EP, BVA, decision tables). White-box: testing based on the code structure (statement and branch coverage), usually done by developers."

Short answer: "Testing without running the software: reviewing requirements, designs, code and test cases, or static code analysis. It finds problems early — like an unclear snowflake requirement — when they're cheapest to fix."

Short answer: "Scrum delivers in short sprints (2–4 weeks). The tester joins refinement (asks questions, adds acceptance criteria), sprint planning (estimates test effort), daily stand-up (progress, blockers), tests stories during the sprint, and joins the review and retrospective."

Short answer: "Automotive SPICE is a process-quality model the OEMs use to assess suppliers. For testers it means: tests must be planned, traceable to requirements, documented and reviewed, with results recorded — so everything is auditable."

Short answer: "The functional safety standard for car electronics. It rates risks with ASIL A–D (D is highest). Safety-relevant HMI parts like certain telltales need stricter testing and evidence."

Short answer: "Boot time to the first image, the bulb check (all telltales light briefly, then turn off unless active), welcome animation, correct values appear (fuel, range, odometer), last settings restored, and no error pop-ups. Also start-up with low battery voltage and very fast KL15 off/on."

Short answer: "Sleep/wake behaviour, KL15 on/off cycles, under-voltage (e.g. 9 V, engine crank dip to 6 V), over-voltage (16 V), what's saved on shut-down (volume, last source), and that the unit really goes to sleep (no battery drain)."

Short answer: "I ask for them, but I don't stop. I collect information from the product owner, developers, similar previous products, standards and user expectations; write down my assumptions, get them confirmed, and use exploratory testing. My test notes become the base for the missing requirements."

Short answer: "I count the test cases and estimate time per case from experience (e.g. 10 min simple, 30 min complex), add time for bench setup, retests and reporting, and add a buffer (~20%) for bugs and blocked time. I compare with similar past features."

Short answer: "I list them, ask my lead which is most important if priorities conflict, work on blockers and safety topics first, and give a quick status update if something will be late. I don't silently switch tasks."

Short answer: Use Situation, Task, Action, Result. Example structure: "During [release] testing (S), I had to verify [feature] (T). I noticed [symptom] only after [condition], so I kept logs running, repeated it 20 times and found the pattern [X] (A). The developer found the root cause in [area] within a day, and we added a regression test (R)."

More STAR examples on the Final prep page. Use a real story from your work.

Short answer: "Learn the product, the bench and the tools; read the key requirements and the existing test cases; run the smoke and regression suites to learn the system; ask many questions; and start taking my own test tasks and bugs as soon as possible."

Short answer: Always say yes. Good ones: "What does a typical day look like for this role?" · "Which HMI parts would I test first — cluster or infotainment?" · "How big is the test team, and how is manual and automated testing split?" · "Which tools and benches do you use?" · "How do you measure success for this role in the first six months?"