CT-AuT: How ISTQB Prepares Testers for Vehicle Software Rules

A car now runs on millions of lines of code written by several companies, and a tester who signs off a function in it answers to rules a web or mobile tester never meets: Automotive SPICE for process evidence, ISO 26262 for functional safety, AUTOSAR for the software architecture. ISTQB's CT-AuT certificate exists to teach exactly that layer. It is a 40-question, 60-minute paper, passed with 26 points, and open only to people who already hold the Foundation Level certificate.

Testers who move into automotive from other fields usually find that their test techniques transfer, while their vocabulary does not. They hear that a unit test needs evidence of a certain rating, that a requirement must trace to a test, that the amount of testing depends on a safety level, and that half the tests run on a simulated vehicle that never leaves a lab. This article follows those surprises in the order the ISTQB syllabus teaches them. You will see what the certificate covers, how the paper is built, what each standard asks of a tester, how the virtual test environments differ, which test techniques the last chapter adds, and a six-week route to the exam. The exam figures and the chapter list were read from ISTQB's CT-AuT page in October 2026.

Why does vehicle software put testers under rules a web tester never meets?

The short answer is that a failure in a vehicle can hurt someone, and the industry has written down how much evidence it expects before software ships. The CT-AuT syllabus opens its first chapter with that tension. It asks you to explain the challenges of automotive product development that come from divergent project objectives and increasing product complexity: a manufacturer wants a short development time, a low cost and high quality all at once, while the product gains more electronic control units, more functions and more suppliers every model year.

Standards are the tool the industry uses to manage that tension, and the syllabus asks you to recall which project aspects they influence: time, cost, quality, project risks and product risks. A standard that demands a certain level of test evidence changes the schedule and the budget as much as it changes the test plan, which is why a tester in this field is expected to talk about both.

The first chapter also asks you to recall the six generic stages of the system lifecycle as ISO/IEC/IEEE 24748-1 describes them: concept, development, production, utilization, support and retirement. A web tester rarely thinks past the release. A vehicle tester works inside a product that is built for years, produced in volume, used for a decade or more and supported long after that, so a fault found late can mean a field action rather than a patch. The chapter ends with the tester's contribution to, and participation in, the release process: what a tester provides as evidence, and how they work with the people who decide that a software version may leave the building.

This chapter is short, only 30 minutes of the 720 minutes ISTQB allots to the whole syllabus, and it is the easiest to pass over. Do not. Its ideas return as exam scenarios in the later chapters, where a question will describe a project with conflicting goals and ask which standard, test environment or technique fits.

What does CT-AuT certify, and what must you hold before booking?

The full name is ISTQB Certified Tester Foundation Level - Automotive Software Tester, abbreviated CT-AuT, and ISTQB files it under its Specialist stream. The syllabus ISTQB lists today is version 2.1.1, a maintenance release of the 2.1 line, and its page does not mention a successor or a retirement.

The prerequisite is stated plainly on ISTQB's page: candidates must hold the Certified Tester Foundation Level certificate. The automotive syllabus therefore does not teach what a test case, a test level or a regression test is. It assumes you know, and it compares automotive practice against the Foundation vocabulary, most explicitly in the chapter section that sets ASPICE and ISO 26262 beside CTFL on test levels. If your Foundation knowledge is a few years old, treat it as the first revision task rather than a formality.

The certificate says something narrow and useful about its holder: that they can read the testing requirements of the main automotive standards, choose a suitable test environment for a given scope, and apply a handful of techniques the automotive world expects. It does not say they can design a safety case or run an assessment. Hiring managers in the sector use it as a signal that a candidate will not need the vocabulary explained, which is a real saving when a team is working to a supplier's deadline.

• Who gains most: testers and test engineers at manufacturers and suppliers, quality engineers who review test evidence, and developers who write unit tests for embedded code.
• Who gains less: testers whose product is never installed in a vehicle, and anyone who has not yet taken the Foundation Level paper, who must do that first.
• What it does not replace: training on your employer's own process, tools and safety organisation.

How is the 40-question paper built, and where do the 720 syllabus minutes go?

The paper has 40 multiple-choice questions, worth 40 points in total, to be answered in 60 minutes. You need 26 points to pass, which is 65 percent. Candidates who take it in a second language get 25 percent extra time, according to ISTQB. ISTQB does not set the fee itself: its page says local exam providers and member boards decide it, and the figure usually quoted for the paper is USD 215. Booking runs through an exam provider, with Pearson VUE the usual route listed for ISTQB exams.

Fact	CT-AuT
Certification	ISTQB Certified Tester Foundation Level - Automotive Software Tester
Questions	40 multiple choice
Syllabus	Version 2.1.1
Duration	60 minutes (25% extra for non-native language)
Passing score	26 out of 40
Fee usually quoted	USD 215, set by the exam provider
Prerequisite	CTFL certificate

The syllabus divides its time across four chapters, and the minutes are the best guide to how much of the paper each chapter is likely to fill, because ISTQB sizes its syllabi by the study time it allots.

Chapter	Minutes	Share of 720
1. Introduction to Automotive Software Testing	30	4%
2. Standards for the Testing of E/E Systems	300	42%
3. Testing in a Virtual Environment	160	22%
4. Static Testing and Dynamic Testing	230	32%

The shares are simple arithmetic on the syllabus minutes, rounded to whole numbers; ISTQB does not print a per-chapter question count on its page. Chapter 2 alone is more than four-tenths of the syllabus, and it is also where the verbs get demanding. The learning objectives use recall for facts, explain for reasons and differences, and use, apply and design where you must work something out, such as reading a method table or designing tests for a coverage target. Expect scenario questions in those last three groups, and straight recall questions for the rest. ISTQB publishes a sample paper with answers; the question file is linked on ISTQB's site, and it is the right way to see the style before you study. Our CT-AuT syllabus page lists the same four chapters topic by topic, with the objectives in one place.

What do ASPICE, ISO 26262 and AUTOSAR each ask of a tester?

They answer three different questions. ASPICE asks whether your process is mature enough to be trusted. ISO 26262 asks whether your product is safe enough for its purpose. AUTOSAR asks how the software is structured so that parts from different suppliers fit together. The syllabus gives the first two the bulk of its 300 minutes and AUTOSAR a short, factual section, and it closes the chapter by asking you to recall the different objectives of ASPICE and ISO 26262 and explain how they differ from CTFL on test levels.

Automotive SPICE

The syllabus asks you to recall that ASPICE has two dimensions, a process dimension and a capability dimension, and to explain capability levels 0 to 3. In short, level 0 means the process is not implemented or does not achieve its purpose, level 1 means it achieves its purpose, level 2 means it is managed, and level 3 means it follows a defined, established standard process. You also need to explain the four rating levels and the capability indicators, from the tester's point of view. The four ratings run from not achieved through partially and largely to fully achieved, and an assessor gives one to each attribute of a process using the evidence in your work products.

For a tester, this chapter section is about evidence. You are asked to recall the purpose of the test-specific processes, to explain what ASPICE requires of a test strategy, including the criteria for regression verification, and to recall its requirements for testware. You must also use verification measures for software unit verification and explain the different traceability requirements. A practical way to hold this together is a chain: a requirement leads to a test specification, the specification leads to executed test results, and each link is recorded so that an assessor can follow it in either direction. If a test cannot be traced to a requirement, or a requirement has no test, the process is weak, however good the individual tests are.

ISO 26262

ISO 26262 (Wikipedia gives the background) is about functional safety of electrical and electronic systems. The syllabus wants you to explain its objective, to recall the tester's contribution to the safety culture, and to discuss the tester's role in the safety lifecycle. You recall which parts of the standard are relevant to a tester, and you recall the criticality levels called ASIL, the Automotive Safety Integrity Levels A to D, with QM for functions that need no safety measures beyond normal quality management.

The idea that earns marks is the link between ASIL and test effort. A higher level means more demanding static and dynamic techniques and a wider test scope. The syllabus asks you to explain that influence and then to use the method tables of the standard. Those tables list techniques per level and mark each as highly recommended, recommended or neither, using the symbols ++, + and o. A typical exam task gives you an ASIL and a table extract and asks which technique you must apply, which is one you can only get right by reading the table slowly. Learn the shape of a table, not its cells: the marks change with each level, and the point of the question is whether you can find the right row.

AUTOSAR

AUTOSAR is the shortest section, with two recall objectives: its project objectives, and its influence on the work of the tester. In outline, it standardises the software architecture of electronic control units so that functions can be reused and exchanged between vehicle platforms and suppliers. For a tester this means interfaces defined by the standard, test cases that can be moved between projects, and a clearer line between what the basic software does and what the application does.

Standard	Main question	What the tester produces or checks
Automotive SPICE	Is the process mature enough?	Test strategy, testware, traceability, unit verification evidence
ISO 26262	Is the product safe enough?	Techniques and scope chosen by ASIL, using the method tables
AUTOSAR	Does the software fit together?	Tests that respect standardised interfaces and layers

When you meet a comparison question, keep the three questions in that table in mind. ASPICE and ISO 26262 both influence testing, but they do not use the same language for test levels, and they do not share an objective. A tester who treats them as one standard will lose points on exactly the questions this chapter section was written to set.

How do MiL, SiL and HiL environments differ, and which one fits which test?

They differ in what is real and what is simulated. In Model-in-the-Loop testing, both the function and its environment exist as models, so you test an idea before any code exists. In Software-in-the-Loop, the actual code runs, usually compiled for a development computer, against a simulated environment. In Hardware-in-the-Loop, the real control unit runs its real software and is connected to a simulator that stands in for the rest of the vehicle. The further you go, the more the test resembles the vehicle, and the more time, equipment and money each test needs.

Chapter 3 begins with the reasons a test environment exists at all. Real vehicles are expensive, scarce, unsafe for some tests and not available early in a project. You are asked to recall the general parts of an automotive test environment, to tell closed-loop systems from open-loop ones, and to recall the essential functions, databases and protocols of an electronic control unit. In an open-loop test you apply inputs and compare outputs. In a closed-loop test the output of the unit under test feeds back into the simulated environment, which changes the next input, so the simulation has to model the vehicle's behaviour as well as send signals.

Environment	What is real	Typical strength	Typical limit
MiL	Nothing; function and environment are models	Early, cheap, fast feedback on the design	Says little about the final code or hardware
SiL	The software	Runs the production code without hardware, easy to automate	Timing and hardware effects are not visible
HiL	Software and control unit	Realistic timing, interfaces and fault behaviour	Expensive rigs, limited number, slower set-up

The syllabus does not stop at definitions. It asks you to summarise the advantages and disadvantages of each environment against criteria, to apply criteria to assign a given extent of testing to one or more environments, and to outline where each environment sits in the V-model. That last objective is the one candidates tend to skip. The V-model pairs development levels with test levels, so MiL belongs beside design, SiL beside the software levels and HiL beside system integration, and a question may ask you to place an environment on the V.

A worked assignment

Suppose a team wants to check a torque-limiting function that reacts when a sensor value passes a threshold. They want a quick check of the logic, a regression suite that runs on every code change, and one test that proves the control unit responds within its time limit when the sensor input is corrupted. The reasoning the exam rewards is simple. The logic can be examined in MiL while the design is still moving. The regression suite fits SiL, because it needs the real code but not the rig, and a build server can run it all night. The timing test belongs in HiL, because only the real unit shows real timing. Every choice is justified by what the test must prove, and none by habit.

Notice what is missing from that answer: no environment is declared the best. The syllabus is clear that boundary conditions decide, and a question that asks which environment is best without giving a test goal is a trap. Read for the goal first.

Which static and dynamic techniques does Chapter 4 add, and how does MC/DC work on one decision?

Chapter 4 adds a small set of techniques that automotive practice leans on, and one of them, modified condition/decision coverage, is the only place in the syllabus where you must do arithmetic. On the static side it covers the MISRA-C guidelines and requirements review. On the dynamic side it covers MC/DC test design, back-to-back testing, fault injection, requirements-based testing and the choice of techniques by context.

Static testing

You are asked to explain the purpose and requirements of the MISRA-C guidelines with examples. They are coding rules for the C language that restrict constructs known to cause unpredictable behaviour in embedded software, and a static analysis tool can check most of them without running the code. The second objective is to apply a requirements review using the quality characteristics from ISO/IEC/IEEE 29148 that matter to testers. A tester reads each requirement and asks whether it is unambiguous, complete and verifiable, because a requirement that cannot be tested will either block the test design or produce a test that proves nothing.

Dynamic testing

The syllabus asks you to design test cases that reach modified condition/decision coverage. A decision such as (A and B) or C has three conditions. MC/DC requires that each condition be shown to change the outcome on its own, with the others held steady. With n conditions you normally need n + 1 tests, so here four, not the eight a full truth table gives.

Test	A	B	C	Outcome
1	true	true	false	true
2	false	true	false	false
3	true	false	false	false
4	true	false	true	true

Read it pair by pair. Tests 1 and 2 differ only in A, and the outcome changes, so A is shown to matter. Tests 1 and 3 differ only in B, and the outcome changes, so B is shown to matter. Tests 3 and 4 differ only in C, and the outcome changes. Each condition has an independent pair, and that is the whole definition. In the exam you may be given a decision and asked for a minimal set, or given a set and asked whether it achieves the coverage, so practise both directions on a few expressions by hand.

The remaining objectives are explanatory. Back-to-back testing runs the same inputs through two versions of an implementation, typically the model and the generated code, and compares the outputs, so a difference points to an error in one of them. Fault injection deliberately introduces faults, such as a corrupted signal or a failed sensor, to see whether the system detects them and reaches a safe state. Requirements-based testing derives tests from the requirements, so that every requirement has at least one test and the traceability chain from Chapter 2 holds. Finally you apply context-dependent criteria to choose suitable and necessary techniques and approaches, which links back to ASIL: the safer the function has to be, the more of these techniques the standard expects.

What does a six-week route through the four chapters look like?

Six weeks suits a tester with a current CTFL certificate who can give about five hours a week. It also follows the minutes: Chapter 2 gets more than a third of the time, and Chapter 1 gets a short session. Adjust the length to your own background. A developer who already writes embedded C will move quickly through MISRA-C and slowly through ASPICE, while a process-minded quality engineer will find the reverse.

1. Week 1: Re-read your CTFL notes on test levels and test types, then work through Chapter 1: the lifecycle stages, the project aspects standards affect, and the tester's role in release.
2. Weeks 2 and 3: Chapter 2. Spend week 2 on ASPICE, drawing the traceability chain and writing the four ratings from memory. Spend week 3 on ISO 26262 and AUTOSAR, and practise the method tables with invented ASIL examples.
3. Week 4: Chapter 3. Make a one-page grid of MiL, SiL and HiL, then give yourself five test goals and place each one in an environment, with a reason.
4. Week 5: Chapter 4. Do MC/DC by hand on at least six decisions, then write one sentence each for MISRA-C, back-to-back testing and fault injection, with an example from your own work.
5. Week 6: Sit ISTQB's sample paper under exam conditions, mark it against the published answers, and revise the objectives behind every miss.

Two habits repay the effort. First, read each learning objective as a verb: if it says explain, write the explanation in two sentences; if it says apply, do an example. Second, keep a one-page list of the terms that sound alike and are not: capability level and rating, ASIL and QM, open loop and closed loop, back-to-back and regression. A good share of wrong answers on a specialist paper come from swapping such pairs under time pressure.

Timing is gentle on this paper: 60 minutes for 40 questions is a minute and a half each. Answer the recall questions at once, flag any method-table or MC/DC question, and return to them with the minutes you saved. Once you have read the syllabus, a set of extra questions from our CT-AuT practice exam page lets you mark your own answers before you pay the exam fee.

The certificate is a Foundation Level specialist credential, so it sits beside, not above, the Advanced Level tracks. Where you go next depends on your work: a tester heading toward test management or test automation in a vehicle programme will find those ISTQB tracks continue naturally, and a safety engineer may prefer to study the standards themselves in full. ISTQB's own page leaves that choice open, saying holders may move on to other Core, Agile or Specialist certifications.

Frequently Asked Questions

What is the CT-AuT exam format and passing score?

The CT-AuT paper has 40 multiple-choice questions to answer in 60 minutes, with 25 percent extra time for candidates who sit it in a non-native language. It carries 40 points, and you need 26 to pass, which is 65 percent.

Do I need CTFL before taking CT-AuT?

Yes. ISTQB's CT-AuT page states that candidates must hold the Certified Tester Foundation Level certificate. The automotive syllabus assumes Foundation vocabulary and compares automotive practice with it, so the certificate is both a rule and a useful base.

Which standards does the CT-AuT syllabus cover?

Chapter 2 covers Automotive SPICE, ISO 26262 and AUTOSAR, and compares ASPICE and ISO 26262 with CTFL on test levels. Chapter 4 adds the MISRA-C guidelines and ISO/IEC/IEEE 29148 for requirement quality, and Chapter 1 refers to ISO/IEC/IEEE 24748-1 for the lifecycle.

What is the difference between MiL, SiL and HiL testing?

In Model-in-the-Loop testing, the function and its environment are models. In Software-in-the-Loop, real code runs against a simulated environment. In Hardware-in-the-Loop, the real control unit runs its software and is connected to a simulator of the vehicle.

How many tests does MC/DC need for a decision with three conditions?

Normally four, which is the number of conditions plus one. For (A and B) or C, the sets true-true-false, false-true-false, true-false-false and true-false-true give each condition an independent pair that changes the outcome while the others stay fixed.

Select ratingPoorOkayGoodGreatAwesome

No votes yet