IVI Test Engineer Interview Prep
Reference

One-page cheat sheet

Everything important on one page. Read it in the last hour before the interview. You can also print it (Ctrl + P).

1. Process (feature → delivery)

  1. Analyse requirement: clear? testable? ask questions
  2. Plan: scope, bench, effort, risks, entry/exit
  3. Design test cases (EP, BVA…) + link to REQ
  4. Set up: flash SW, CANoe config, smoke
  5. Execute, collect evidence, raise bugs
  6. Retest + regression
  7. Report + release recommendation

2. Good bug report (12 fields)

  • Summary: [Component] what – where/when
  • Environment: SW version, HW sample, bench, variant
  • Preconditions · numbered steps
  • Expected (with REQ ID) · Actual
  • Reproducibility (3/3)
  • Evidence: video/photo, CAN trace, log + timestamp
  • Severity · priority · component · links

3. After the fix

  1. Check the build has the fix (fix version)
  2. Retest original steps (+ variations)
  3. Regression around the change (impact analysis)
  4. Close with evidence — or Reopen
  5. Add to regression suite if severe

4. Regression strategy

  • Layers: smoke (each build) → targeted (each fix) → core P1 (each sprint/RC) → full (release)
  • Choose by risk: safety, changed areas, most-used, bug history, fixed critical bugs, legal
  • Priorities P1 always / P2 if time / P3 full cycle
  • Automate stable repeated tests; run nightly

5. Fixed bug → regression?

  • Yes: severe, safety, customer-visible, often-changed code, came back before. Ex: rear camera freezes after a call.
  • No: trivial cosmetic, one-off env issue, already covered, feature removed. Ex: typo in the engineering menu.

6. Don't create a new ticket when…

  • Duplicate → comment on the existing one (search first!)
  • Expected per requirement → improvement request
  • Environment (bench, old SW, config) → fix setup, rerun
  • Not implemented yet / known issue
  • Rule: one problem = one ticket

7. BVA + snowflake

  • Test at and next to the boundary, not 0 & 10 °C
  • 3-value: 4.9 / 5.0 / 5.1 (resolution 0.1)
  • "Below 5" → 5.0 OFF · "5 and below" → 5.0 ON
  • Spec overlaps 4–5 °C → clarify; likely hysteresis: ON ≤ 4.0, OFF ≥ 5.0
  • Test both directions, flicker, SNA/timeout, °F, restart

8. Severity vs priority

  • Severity = impact (tester): Blocker, Critical, Major, Minor, Trivial
  • Priority = urgency (business): P1–P4
  • High sev / low prio: crash in rare engineering menu
  • Low sev / high prio: wrong logo before a car show
  • Safety (speed, warnings, camera) = at least Critical

9. Retest vs regression · smoke vs sanity

  • Retest: is this bug fixed?
  • Regression: did the change break anything else?
  • Smoke: wide + shallow, every build
  • Sanity: narrow + deeper, after small change
  • Error (human) → defect (code) → failure (seen)

10. Car basics

  • ECU = small computer; CAN = network between them
  • DBC: real = raw × factor + offset
  • 0xFF = 255 = often SNA; timeout → "---" + DTC
  • KL30 battery · KL15 ignition · KL31 ground
  • SIL (PC) → HIL (real ECU + simulator) → vehicle
  • UDS 0x19 read DTC · 0x14 clear · 0x22 read data

11. HMI rules & numbers

  • Telltales: red danger · amber warning · green on · blue high beam
  • Speedometer never under-reads (UN R39)
  • Indicators 90 ± 30/min (UN R48)
  • Rear camera ≤ 2 s (FMVSS 111)
  • Bulb check at start-up · driver-distraction lock above ~8 km/h
  • BT: HFP calls · A2DP music · AVRCP controls · PBAP contacts

12. Tools

  • CANoe simulate + trace (CAPL) · CANalyzer analyse
  • DLT Viewer / adb logcat ECU logs
  • Jira bugs (JQL) · Xray/Polarion test cases & traceability
  • vFlash flashing · Jenkins nightly runs
  • Log analysis: time of bug → CAN input right? → ECU log errors?

13. Robot Framework

  • Keyword-driven, Python-based; sections: Settings, Variables, Test Cases, Keywords
  • robot --include smoke tests/
  • Output: output.xml, log.html, report.html
  • rebot --merge a.xml b.xml
  • Failure triage: product bug / script / environment / flaky

14. Spot-the-defect: 8-point scan

  1. Text (typos, language mix, cut-off)
  2. Units (km/h vs mph, °C vs °F)
  3. Numbers (30 Feb, 25:10, 00:75, 21:30 AM)
  4. Consistency (needle vs digital, bar vs %)
  5. Icons & colours
  6. Layout (overlap, missing, tilted)
  7. State (wrong highlight, play/pause)
  8. Logic & safety (snowflake at 13 °C)

15. ISTQB quick facts

  • 7 principles: presence of defects · exhaustive impossible · early testing · clustering · tests wear out · context · absence-of-errors fallacy
  • Levels: component, integration, system, acceptance
  • CTFL v4.0: 40 Q · 60 min · 65%
  • Verification = built right · Validation = right thing

16. How to answer

  • Short answer first (20 s), then detail
  • Always give an example
  • Clarify unclear requirements
  • Say "I", be honest about gaps
  • STAR for "tell me about a time…"
  • Ask 2–3 questions at the end