IVI Test Engineer Interview Prep
Chapter 2 · Start here

Learn with pictures

Every important idea as one picture and a few short sentences. If a chapter feels hard, come back here first. Look at the picture, read the short lines, then read the chapter.

Very easy17 picturesRead this first
How to use this page
  1. Look at the picture for 30 seconds. Follow the arrows with your finger.
  2. Read the short sentences under it.
  3. Say the green "Say" line out loud. That is your interview answer.

1. How the car works

Where does the speed on the screen come from?

Follow the arrows: from the wheel to your eyes.

Wheel sensor counts wheel turns ABS ECU works out 50 km/h CAN bus carries: Speed = 50 Cluster ECU reads the message Screen shows 50 km/h You (tester) is 50 correct?
  • The screen does not measure anything. It only shows what it hears from other ECUs.
  • If the screen shows a wrong speed, the mistake can be at any step.
  • Your job: find out which step is wrong (the logs help you).

Say: "The cluster gets the speed as a CAN signal from the ABS ECU. If the display is wrong, I check the CAN trace first to see if the input was already wrong."

What is CAN? A WhatsApp group for car computers

One ECU sends a message. Everybody hears it. Only the ones who need it read it.

Message: Speed = 50 Engine ABS Doors CAN bus (2 wires) Cluster Head unit needs speed: reads it doesn't need it: ignores
  • CAN = one shared line (2 wires). All ECUs are connected to it.
  • Every message has a number (the ID, like 0x1A0) and values inside (the signals, like speed).
  • On the test bench, your PC with CANoe can join this "group" and send fake messages, for example "Speed = 50".

Say: "CAN is the network the ECUs use to share signals. With CANoe I can simulate these signals on the bench and record the traffic in a trace."

From a raw number to a real value (the DBC formula)

The bus only carries plain numbers. The DBC file says how to turn them into real values.

real value raw factor offset 10 °C = 100 × 0.5 + (−40) on the screen from the CAN bytes from the DBC from the DBC 100 × 0.5 = 50 → 50 − 40 = 10
  • Raw = the plain number in the message (0x64 in hex = 100).
  • Factor and offset come from the DBC file (the dictionary of the CAN bus).
  • Formula to remember: real = raw × factor + offset. Try it with the decoder on the Car basics page.

Say: "The DBC defines each signal's position, factor and offset. The real value is raw times factor plus offset."

What is a test bench?

A table with the real car computer, but no car. The PC pretends to be the rest of the car.

Power supply 12 V (KL30, KL15) Device under test cluster or head unit PC CANoe + logs CAN logs Phone + USB music, calls you look at the screen You (the tester) compare with the requirement
  • Device under test (DUT) = the thing you test: the real cluster or head unit.
  • The power supply gives battery power (KL30) and ignition (KL15).
  • The PC with CANoe sends fake signals (speed, temperature, doors) and collects logs.

Say: "My bench had the real ECU, a power supply for KL30 and KL15, a Vector CAN interface with CANoe for rest-bus simulation, phones and USB for media, and a log connection."

2. Testing basics

Error → defect → failure

Three words the interviewer likes. They are three steps of one story.

1. ERROR 2. DEFECT 3. FAILURE Developer types <= instead of < if (temp <= 5) show ❄ 5.0 °C ❄ wrong at 5.0! a human mistake the mistake in the code what you SEE go wrong You find the failure. Developers fix the defect.
  • Error = a person makes a mistake.
  • Defect (bug) = that mistake is now inside the code.
  • Failure = when the code runs, you see something wrong.

Say: "An error is a human mistake. It creates a defect in the code, and when the code runs, the defect can cause a failure that I can observe."

The testing process: a road with 7 stops

This is the answer to "A customer wants a new feature. What do you do?"

1 2 3 4 5 6 7 Read therequirement Make atest plan Writetest cases Preparethe bench Run thetests Report bugs,retest fixes Write thetest report Release!
  • Step 1 is the most important: read and ask questions if something is not clear.
  • Every test case is linked to its requirement (this link is called traceability).
  • At the end, the test report helps the team decide: release or not?

Say: "I analyse the requirement, plan, design test cases linked to the requirement, prepare the bench, execute, report and retest defects, run regression, and finish with a test report and a release recommendation."

3. Bugs and Jira

A good bug report is a recipe

Someone else must be able to "cook" the same bug by following your steps.

BUG-123 Severity: Major TITLE WHERE STEPS EXPECTED ACTUAL HOW OFTEN PROOF [Cluster] Snowflake ON at 5.0 °C Software 3.2.1 · Bench B-07 1. Set 5.1 °C 2. Set 5.0 °C No snowflake (REQ-123) Snowflake is shown 5 out of 5 times video.mp4 · trace.blf · log.dlt
  • Title = where + what, in one line. Others must find it with search.
  • Expected (what should happen) vs actual (what really happened) is the heart of the report.
  • Proof: always a photo or video, plus the CAN trace and log with the time.

Say: "A good report has a clear summary, the environment and version, preconditions, numbered steps, expected and actual result with the requirement ID, the reproduction rate, and evidence: video, trace and logs."

Severity vs priority

Severity = how BAD it is. Priority = how FAST we fix it. They are different.

low severity + high priority high severity + high priority low severity + low priority high severity + low priority Wrong logo beforea big car show small, but fix today Wrong speedon the cluster fix NOW Small typoin a settings menu fix later Crash in a hiddenengineering menu bad, but few people use it PRIORITY: how fast? SEVERITY: how bad?
  • The tester suggests the severity (the technical effect).
  • The project / product owner decides the priority (business need).
  • In cars: anything about safety (speed, warnings, camera) is at least Critical.

Say: "Severity is the impact on the system; priority is the urgency of the fix. A wrong logo before a car show is low severity but high priority."

The life of a bug ticket

A ticket moves from box to box. The red arrow is what happens when the fix does not work.

New tester creates it Assigned given to a developer In progress developer fixes it Resolved fix is in a new build Retest tester checks the fix Closed it works: done! still broken? REOPEN Other endings: Rejected (not a bug) · Duplicate · Deferred (later)
  • After you create a ticket, you follow it until it is closed.
  • When it comes back as "resolved", you retest it.
  • Works → Close. Still broken → Reopen with new proof.

Say: "When a ticket is resolved, I check the fix version, retest with the original steps and run regression around it. Then I close it, or reopen it with new evidence."

Two testers, one bug = ONE ticket

Always search first. If the ticket exists, add a comment.

Tester A Tester B 1. Search Jira first! BUG-123 Snowflake at 5.0 °C Comment (Tester B): also on bench B-09, 3 out of 3 times 2. One ticket + a comment WRONG: BUG-123 BUG-124 (a copy!) ✗ Two tickets for one problem = wasted time and wrong numbers
  • Before you create a ticket: search Jira with keywords (e.g. "snowflake"), the component and recent dates.
  • Found it? Add a comment with your new information (other bench, other version, new log).
  • Not found? Create it with a clear title, so the next tester can find it.

Say: "One problem, one ticket. I search Jira before creating a defect, and if it exists I add my information as a comment and link my test case to it."

3 times you should NOT create a new ticket

Even if you see something strange, stop and check these three things first.

Already reported → add a comment Works like the requirement → not a bug (maybe suggest an improvement) Bench or setup problem → fix the setup, test again
  • Already reported: many testers test the same software. Search first.
  • Expected behaviour: read the requirement again. If it says so, it is not a bug.
  • Environment problem: old software flashed, wrong CANoe settings, loose cable. Fix it and test again.

Say: "I don't create a new ticket if it's a duplicate, if the behaviour matches the requirement, or if the cause is the test environment. Then I comment, clarify, or fix the setup instead."

4. Retest and regression

Retest vs regression: the plumber story

A plumber fixed one leak. What do you check?

RETEST: is this leak fixed? ✓ ?✓ ? ✓ ?✓ ? REGRESSION: do all the other taps still work?
  • Retest = check the one thing that was fixed. Same steps as in the bug ticket.
  • Regression = check that the fix did not break other things that worked before.
  • Always both: first retest, then regression around the change.

Say: "Retesting confirms that the defect itself is fixed. Regression testing checks that the change didn't break anything that worked before."

3,000 tests, only 1 day: the regression funnel

You can't run everything. Pour all tests into the funnel; only the most important come out.

3,000 tests in total 1. Safety (warnings, speed, camera) 2. What changed in this build 3. What drivers use most 4. Where bugs were before ≈ 300 tests today
  • Choose by risk: what is dangerous, what changed, what is used a lot, what broke before.
  • Give tests priorities: P1 always, P2 if there is time, P3 in the full run.
  • Tell your lead clearly what you did not test.

Say: "I select by risk: safety-critical functions first, then the areas changed in this build, the most-used customer functions, and areas with a history of bugs. I report what was not tested."

5. Boundary values and the snowflake

BVA: test at the border, not in the middle

Rule: "snowflake ON below 5 °C". Where do bugs hide? At 5!

COLD: ❄ ON WARM: ❄ OFF 024 6810 °C 5 °C = the boundary grey = EP (one per group) Zoom in on the border: 4.95.05.1 ONOFFOFF
  • EP (grey dots): split values into groups (cold / warm) and test one value from each group.
  • BVA (red dots): test the border value and its neighbours: 4.9, 5.0, 5.1.
  • 5.0 is the most important value: "below 5" means 5.0 is OFF. A developer who wrote <= instead of < shows it ON.

Say: "Most bugs are at the boundary, so I test the boundary value and its nearest neighbours, using the signal resolution: 4.9, 5.0 and 5.1 °C, not just 0 and 10 °C."

Hysteresis: why the snowflake does not flicker

It switches ON at one temperature and OFF at a different one. In between, it stays as it was.

getting colder ← ❄ turns ON at 4.0 °C getting warmer → ❄ turns OFF at 5.0 °C 4–5 °C: keeps its last state 3 °C4 °C 5 °C6 °C
  • Without hysteresis, at 4.9 → 5.0 → 4.9 → 5.0 the icon would blink ON, OFF, ON, OFF. That is annoying.
  • With hysteresis, the direction matters. At 4.5 °C the icon can be ON (coming from cold) or OFF (coming from warm).
  • So you test both directions: getting colder and getting warmer.

Say: "The requirement overlaps between 4 and 5 °C, so I would clarify it. It is probably hysteresis, so I test both directions at both boundaries, 3.9/4.0/4.1 and 4.9/5.0/5.1, and check that it doesn't flicker."

6. Automation and logs

What happens when you run Robot Framework

You start it with one command. You get three files. You read one of them to understand failures.

tests.robot steps in plain words robot starts the run Test bench does the steps report.html summary: 48 ✓ 2 ✗ log.html every step + errors output.xml raw data for tools Your job for each ✗ (failed test): Product bug? → create a Jira ticket Script problem? → tell the automation team Bench problem? → fix the bench, run again
  • A .robot file holds the tests as readable steps, like Set Vehicle Speed 50.
  • log.html is where you find why a test failed (the red step and the error message).
  • Not every red test is a product bug. Deciding which kind of failure it is is called triage.

Say: "After a run I get output.xml, log.html and report.html. For each failure I check log.html and decide: product defect, script issue, environment issue or flaky test. Only real defects go to Jira."

Log analysis: rewind to the moment of the bug

Like CCTV footage: go to the exact time and look at the input and the output.

bug moment CAN trace (input) ECU log (software) Screen (output) Temp = 5.0 °C snowflake=ON ❄ is shown 10:15:3010:15:3110:15:32
  • Step 1: note the exact time when you saw the bug.
  • Step 2: in the CAN trace, was the input right? Here: 5.0 °C — correct.
  • Step 3: in the ECU log and on the screen, was the output wrong? Here: snowflake ON — wrong.
  • Input right + output wrong = the bug is in the HMI software. Input already wrong = the bug is in the ECU that sends it.

Say: "I note the time of the failure, check the CAN trace to see if the input was correct, then the ECU log for errors. That tells me which component owns the bug."

7. The 10 most important answers in very simple English

These are short versions. Learn these first. When you feel confident, read the longer answers on the Q&A page.

1What is your testing process, from requirement to release?

Simple answer: "First I read the requirement and ask questions if something is not clear. Then I plan and write test cases. I prepare the bench and run the tests. I report bugs, retest the fixes and run regression. At the end I write a test report."

Picture: the road with 7 stops · Long answer: Q23

2What makes a good bug report?

Simple answer: "A clear title, the software version, the steps, what should happen, what really happened, how often it happens, and proof: a video, the CAN trace and the log."

Picture: the bug recipe · Long answer: Q53

3What do you do after a developer fixes a bug?

Simple answer: "I check that the new build has the fix. I retest with the same steps. Then I run regression around the change. If it works, I close the ticket. If not, I reopen it with new proof."

Picture: the life of a ticket · Long answer: Q59

4What is your regression strategy?

Simple answer: "A smoke test on every new build. Regression around every fix. The important tests every sprint. All tests before a big release. Safety tests always come first, and we automate what we run often."

Picture: the plumber story · Long answer: Q71

5Thousands of tests and little time: how do you choose?

Simple answer: "I choose by risk: safety first, then what changed, then what drivers use most, then the areas with old bugs. And I tell my lead clearly what I did not test."

Picture: the funnel · Long answer: Q72

6Should every fixed bug go into the regression suite?

Simple answer: "No, only the important ones. Yes for serious bugs, safety bugs and bugs that came back before — for example, the rear camera freezes after a phone call. No for tiny bugs — for example, a typo in a hidden menu."

Long answer: Q73–75

7How do you avoid duplicate tickets?

Simple answer: "One problem, one ticket. I search Jira before I create a ticket. If it already exists, I add a comment with my information."

Picture: two testers, one ticket · Long answer: Q83

8When would you NOT create a ticket?

Simple answer: "When it is already reported, when it works like the requirement says, or when the problem is my bench or setup and not the software."

Picture: 3 times not to · Long answer: Q89

9What is Boundary Value Analysis?

Simple answer: "Bugs hide at the edges. So I test the edge value and the values right next to it. For a limit of 5 °C, I test 4.9, 5.0 and 5.1."

Picture: test at the border · Long answer: Q98

10Which exact temperatures would you test for the snowflake?

Simple answer: "First I ask: at exactly 5.0 °C, is it ON or OFF? And what happens between 4 and 5 °C? Then I test 3.9, 4.0, 4.1 and 4.9, 5.0, 5.1, going colder and going warmer, and I check that it does not flicker."

Picture: hysteresis · Long answer: Q99

Tip for speaking

Short sentences are good. You do not need difficult English to pass. Clear steps + one example + honest words = a strong answer.