ISTQB CT-AuT common mistakes
ISTQB CT-AuT · Understand the traps and how to avoid them.
Treating Automotive SPICE® process capability levels (0–5) as if they were the same scale as ISO 26262 ASIL A–D, so questions asking whether a higher capability level is required for a higher ASIL are answered with a mapping that does not exist.
Both frameworks appear together in the syllabus and both use lettered or numbered maturity scales, so candidates assume a one-to-one correspondence instead of recognising that ASPICE assesses process capability while ISO 26262 assigns integrity requirements to work products.
What to do instead
Learn the two scales separately: state the six ASPICE capability levels and what each means, then state the four ASILs and their relation to hardware metrics and confirmation measures. Practise answering questions by asking which framework the question names, and reject any answer that claims ASPICE level X implies ASIL Y.
Applying ISO 26262's ASIL decomposition rule incorrectly, for example decomposing ASIL D into two ASIL B requirements without noting that decomposition requires independence between the resulting elements and must preserve the original ASIL through the allocation.
Candidates memorise the decomposition table (D into C+D, B+B, or A+C etc.) but drop the independence precondition, so they accept answers that split an ASIL without any argument for freedom from interference.
What to do instead
Memorise the permitted decomposition schemes together with the independence requirement, and for each practice question state explicitly whether the two elements are independent. If independence is not argued, the decomposition is invalid regardless of the letters used.
Describing AUTOSAR® software component testing without distinguishing the virtual functional bus from the runtime environment, or claiming that software components communicate directly with each other rather than through the RTE and VFB.
The architecture vocabulary is dense and candidates blur the layers, so they describe component-to-component calls that the standard deliberately abstracts away.
What to do instead
Draw the layering once from memory: application software components, virtual functional bus as the abstract communication model, runtime environment as the concrete implementation on an ECU, then basic software and microcontroller abstraction. Answer communication questions by naming which layer performs the routing.
Confusing MiL, SiL, PiL, and HiL boundaries, for example calling a test on a real ECU with simulated plant a software-in-the-loop test, or claiming model-in-the-loop requires the production code.
The XiL family is taught as a list rather than a progression, and candidates match the label to the tool they have seen rather than to what is real and what is simulated.
What to do instead
For every XiL question, name the two axes: what runs the control algorithm (model, generated code, production code, real ECU) and what provides the environment (model or real plant). Write one sentence per XiL level using those axes and check the question against them.
Treating back-to-back testing between a model and its generated code as a pass/fail equivalence proof, ignoring that the comparison needs a defined tolerance, identical inputs, and coverage of the relevant behaviour.
Back-to-back testing is presented as the classic MiL/SiL technique, so candidates assume any difference is a defect and any absence of difference is complete verification.
What to do instead
State the three conditions explicitly in answers: same stimulus and same initial state, a numerical tolerance justified by the model's precision, and coverage evidence that the compared scenarios exercise the behaviour of interest. Differences within tolerance are not failures; uncovered behaviour is not verified.
Claiming that testing in a virtual environment can replace real-vehicle or HiL testing for safety validation, rather than positioning virtual testing as a complement that shifts and reduces but does not eliminate physical testing.
The efficiency benefits of XiL are emphasised in study material, and candidates over-generalise them into a substitution argument that ignores model fidelity limits and the need for validation of the simulation itself.
What to do instead
Answer with the complement framing: virtual environments enable early, repeatable, and hazardous-scenario testing and reduce physical test effort, but the simulation model must itself be validated and residual real-world testing remains necessary. Name model fidelity as the limiting factor.
Failing to identify MISRA C rule violations as static analysis findings and instead classifying them as dynamic defects, or missing that static analysis can also target models and requirements, not only source code.
Candidates associate static testing narrowly with code review and forget the automotive-specific scope of static techniques across requirements, models, and code, and they confuse the timing of the technique with the artefact it examines.
What to do instead
Build a matrix of artefact versus static technique: requirements reviews and checklists, model guidelines and consistency checks for Simulink-style models, MISRA C and coding-standard checks for source code, plus metrics. Answer by locating the artefact in the question first, then naming the technique.
Describing code review or static analysis as a way to measure runtime behaviour such as timing, stack usage under load, or task scheduling, and thereby selecting a static technique for a question that requires execution.
Candidates read 'analysis' and 'verification' as interchangeable and lose the distinction between examining an artefact without executing it and observing behaviour during execution.
What to do instead
Apply a one-line test before answering: does the technique require the code to run? If yes, it is dynamic. Static techniques can reveal unreachable code, violations of rules, and complexity, but not actual execution timing. Use this test on every technique-classification question.
Choosing equivalence partitioning and boundary value analysis for continuous control-loop parameters without recognising that the input space is continuous and that robustness at and beyond boundaries, plus fault injection, is often the intended automotive dynamic technique.
Candidates default to the ISTQB Foundation techniques they know best and do not adapt them to signal-oriented, time-dependent E/E inputs such as sensor ranges, bus timeouts, and out-of-range voltages.
What to do instead
Practise describing partitions for a sensor signal including invalid ranges, then add the automotive layer: boundary values at the physical limits, fault injection of out-of-range and stuck signals, and time-dependent cases such as message loss. Match the technique to the signal type stated in the question.
Writing dynamic test cases for E/E functions without specifying preconditions, stimulus timing, and expected reaction time, so the answer omits the temporal dimension that separates a valid automotive test case from a generic input-output case.
Candidates carry over the input-process-output template from general software testing and forget that distributed functions on a bus have cycle times, timeouts, and degraded-mode reactions that must be asserted.
What to do instead
Use a fixed template for every dynamic test case answer: initial state and network state, stimulus with its timing and sequence, expected output with a tolerance and a deadline, and the degraded-mode behaviour if the stimulus is absent. Check that the timing appears in both the stimulus and the expected result.