ISTQB-CTFL-AUT Practice Questions

ISO 26262 is the international standard for the functional safety of electrical and electronic (E/E) systems in road vehicles. Its primary objective is to mitigate risks by defining safety-related processes and methods. The rigor and specific requirements of these processes are tailored based on the system's Automotive Safety Integrity Level (ASIL), which represents its criticality. In contrast, Automotive SPICE (ASPICE) is a process assessment model used to evaluate the capability and maturity of a supplier's development processes. The goal of an ASPICE assessment is to determine the quality of the processes themselves, and its requirements are applied uniformly, independent of the product's specific safety criticality or ASIL.

A. This statement incorrectly reverses the roles of the standards, claiming ISO 26262 is independent of criticality and ASPICE is dependent on it.

C. This statement is incorrect for both standards, claiming ISO 26262 is independent of ASIL and ASPICE is dependent on criticality.

D. This statement incorrectly assigns the objective of determining process capability to ISO 26262; this is the primary objective of ASPICE.

---

1. ISTQB® Certified Tester Foundation Level Automotive Software Tester Syllabus Version 1.0 (2018).

Section 1.3.1, ISO 26262, page 10: "The standard defines the requirements for the processes and the work products for the development of safety-related E/E systems... The required activities and work products depend on the Automotive Safety Integrity Level (ASIL)." This confirms that ISO 26262 requirements are dependent on criticality (ASIL).

Section 1.3.2, Automotive SPICE (ASPICE), page 11: "Automotive SPICE is a framework for assessing the capability of the development processes for software-based systems... The process assessment model is used to perform a conformity assessment of the processes of an organization." This confirms ASPICE's objective is to assess process capability.

2. ISO 26262-1:2018, "Road vehicles — Functional safety — Part 1: Vocabulary".

Section 3.8, Automotive Safety Integrity Level (ASIL): The standard defines ASIL as the mechanism for specifying "the item's or element's necessary requirements of ISO 26262 and safety measures to apply for avoiding an unreasonable residual risk." This establishes the direct link between criticality (ASIL) and the required processes.

3. Weyer, T., Folmer, J., & Mäder, P. (2012). "A Comparison of Automotive SPICE and ISO 26262." Software Quality Professional, 14(4), 23-31.

Page 24: The paper states, "ISO 26262 is a standard for functional safety... The required level of rigor depends on the ASIL." It further clarifies, "Automotive SPICE is a process assessment model... It is used to evaluate the capability of development processes." This academic source clearly distinguishes the ASIL-dependent nature of ISO 26262 from the process capability focus of ASPICE.

A test environment consists of the hardware, software, instrumentation, and network configurations required to execute a test. In the automotive context, this typically includes a laboratory setting, a real-time PC for simulation (e.g., in a Hardware-in-the-Loop system), and communication devices to interface with vehicle networks like CAN or LIN. A test plan, however, is a management document. It is classified as testware and outlines the scope, approach, resources, and schedule for testing. While it governs the use of the test environment, it is not a functional component of the environment itself.

B. Laboratory: A laboratory provides the controlled physical space, power, and infrastructure necessary to house the test equipment, making it a foundational part of the test environment.

C. Real-time PC: A real-time PC is a critical component of modern automotive test environments, particularly for HIL simulation, where it executes models of the vehicle and its surroundings.

D. Communication device: Communication devices (e.g., CAN/LIN interfaces) are essential for connecting the test system to the electronic control units (ECUs) and monitoring or stimulating the vehicle's data buses.

1. ISTQB® Certified Tester Foundation Level Syllabus (v4.0), International Software Testing Qualifications Board, 2023.

Glossary, Page 79: Defines Test Environment as "The hardware, software, and other supporting infrastructure in which a test is run."

Glossary, Page 80: Defines Test Plan as "A document describing the scope, approach, resources and schedule of intended test activities." These definitions clearly distinguish the infrastructure (environment) from the documentation (plan).

2. ISTQB® Certified Tester Foundation Level - Automotive Software Tester Syllabus (v1.0), International Software Testing Qualifications Board, 2021.

Section 3.2.2, Hardware-in-the-Loop (HIL), Page 23: Describes a typical HIL test environment, which includes "a real-time processor" (Real-time PC) and "I/O interfaces" (which include Communication devices) to connect to the ECU under test. This confirms that B, C, and D are integral parts of an automotive test environment.

3. Isermann, R., Schaffnit, J., & Sinsel, S. (1999). Hardware-in-the-loop simulation for the design and testing of engine-control systems. Control Engineering Practice, 7(5), 643-653.

Section 3, Hardware-in-the-loop simulation test bench, Page 645: This academic paper details the components of a HIL test bench, explicitly listing a "real-time computer" and "process coupling hardware" (I/O boards, communication interfaces) as essential elements of the test environment.

In Automotive SPICE®, a capability level is considered fulfilled only if all its associated process attributes are rated as "Largely achieved" (L) or "Fully achieved" (F). The rating "P" stands for "Partially achieved," indicating an achievement level of more than 15% up to 50%. Since the process attribute PA1.1 (Process Performance), which is required for Capability Level 1, received a "P" rating, the minimum requirement of "L" was not met. Therefore, Capability Level 1 has not been fulfilled.

B. Fulfilling Capability Level 3 requires fulfilling levels 1 and 2 first. Since level 1 is not fulfilled, this is incorrect.

C. Fulfilling Capability Level 2 requires fulfilling level 1 first. Since level 1 is not fulfilled, this is incorrect.

D. A "P" (Partially achieved) rating is insufficient. A rating of at least "L" (Largely achieved) is required to fulfill Capability Level 1.

1. Automotive SPICE® Process Assessment Model, Version 3.1, VDA QMC, 2017.

Section 5.3.3, "Process attribute rating" (Page 21): Defines the four-point rating scale: N (Not achieved), P (Partially achieved), L (Largely achieved), and F (Fully achieved).

Section 5.3.4, "Capability level rating" (Page 22): States, "A capability level is achieved if all process attributes for that capability level are rated as Largely achieved or Fully achieved."

2. ISTQB® Certified Tester Foundation Level Automotive Software Tester Syllabus, Version 1.0, International Software Testing Qualifications Board, 2018.

Section 2.2.2, "Capability Levels and the Rating Scale" (Page 12): Explains that for a process to achieve a capability level, "all process attributes of this level must be rated as 'Largely achieved' or 'Fully achieved'." It explicitly clarifies that a 'P' rating is insufficient.

Model-in-the-Loop (MIL) testing involves executing a model of the system under test (SUT) within a completely simulated environment. This entire process runs on a host computer. The essential components for this test environment are the computer itself, the software capable of running the simulation (e.g., MATLAB/Simulink), the model of the SUT, and a model that simulates the physical environment with which the SUT interacts (e.g., vehicle dynamics, sensor inputs). This setup allows for early validation of control logic and algorithms before any code is generated or hardware is available.

B. Interface and integration tests are fundamental test types applied across various test levels, including Software-in-the-Loop (SIL) and Hardware-in-the-Loop (HIL), not exclusively in a MIL environment.

C. MIL simulations typically run on non-real-time host PCs, and the SUT is a model, not real hardware. A key benefit is that simulation time is independent of real time.

D. A real-time capable computer for capturing signals is a characteristic feature of a Hardware-in-the-Loop (HIL) test environment, where a real electronic control unit (ECU) is tested.

---

1. ISTQB® Certified Tester Foundation Level Automotive Software Tester Syllabus, Version 1.0 (2018).

Section 3.1.2, Model-in-the-Loop (MIL), Page 23: "In MIL testing, a model of the system under test (SUT) is tested in a simulated environment. The test environment consists of a computer and the corresponding simulation software, including the environmental model." This statement directly validates option A.

Section 3.1.2, Page 23: "The simulation time in MIL test environments is usually not real-time." This directly refutes option C.

Section 3.1.4, Hardware-in-the-Loop (HIL), Page 25: "The test environment includes a real-time capable computer..." This shows that the description in option D applies to HIL, not MIL.

Section 3.1.3, Software-in-the-Loop (SIL), Page 24: "Integration tests can be performed at the SIL level..." This demonstrates that integration tests are not exclusive to MIL, refuting option B.

2. Pretschner, A., Broy, M., Kruger, I. H., & Stauner, T. (2007). Software engineering for automotive systems: A roadmap. 2007 Future of Software Engineering, 35-52. IEEE.

Section 4.2, Paragraph 2: The paper describes MIL as a pure simulation environment running on a host PC where both the controller and the plant (environment) are models. This supports the composition described in option A and contradicts the real-time and real-hardware claims of options C and D. DOI: https://doi.org/10.1109/FOSE.2007.27

3. Chen, J., Liu, Z., & Wang, S. (2020). From Model-in-the-Loop to Hardware-in-the-Loop: A Survey of Simulation and Testing Technologies in Automotive Industry. IEEE Access, 8, 135635-135653.

Section III.A, Model-in-the-Loop Simulation, Page 135638: "The MIL simulation is a pure software simulation environment... The controller model and the plant model are both executed on a host computer." This confirms that the setup requires a computer, simulation software, and models for both the system and its environment, as stated in option A. DOI: https://doi.org/10.1109/ACCESS.2020.3011023

The statement, "Define the objectives for the execution of the process," is a direct characterization of an activity required for Automotive SPICE (ASPICE) Capability Level 2 (Managed). Specifically, this aligns with the Generic Practice GP 2.1.1, "Identify the objectives for the execution of the process." At Level 2, a process is not just performed (as in Level 1), but it is actively managed. This management begins with planning, which includes identifying and defining objectives related to quality, time, and budget for the process execution.

B. Capability level 0: At this level, the process is incomplete or not performed at all; therefore, no objectives are defined.

C. Capability level 1: At this level, the process is performed and achieves its purpose, but the explicit management practices like defining objectives, planning, and monitoring are not required.

D. Capability level 3: This level requires that a managed (Level 2) process is established using a standard organizational process. Defining objectives is a prerequisite inherited from Level 2.

---

1. Automotive SPICE® Process Assessment Model, Version 3.1, VDA Quality Management Center (VDA QMC), 2017.

Page 20, Section 5.3.2, Capability Level 2: Managed process: This section introduces the Process Attribute PA 2.1 Performance management. The first Generic Practice listed is GP 2.1.1: Identify the objectives for the execution of the process. The description clarifies that objectives for work products, quality, time, and budget are identified at this level.

2. ISTQB® Certified Tester Foundation Level Automotive Software Tester Syllabus, Version 1.0, International Software Testing Qualifications Board, 2021.

Page 17, Section 2.3.2, Automotive SPICE Capability Levels: The syllabus describes Level 2 as: "The process is planned and monitored. The work products are appropriately managed." Defining objectives is a fundamental part of the planning activity introduced at this level, distinguishing it from Level 1 where the process is simply "performed".

The table format and symbols (++ and +) are derived directly from the ISO 26262 standard for functional safety in road vehicles. In this standard, the symbols indicate the level of recommendation for using a specific method to achieve a certain Automotive Safety Integrity Level (ASIL). '++' signifies that a method is "highly recommended," while '+' means it is "recommended." The standard requires that a suitable set of methods be chosen and their selection justified. Therefore, the supplier's tester must select an appropriate combination of methods, giving higher priority to those marked '++', and be prepared to rationalize their choices, especially if a highly recommended method is omitted.

B. This option incorrectly reverses the strength of the recommendations, suggesting '++' (highly recommended) is weaker than '+' (recommended).

C. This option uses imprecise and overly rigid language like "must be covered," which misrepresents the nature of a recommendation, and incorrectly interprets the symbols.

D. This option also incorrectly reverses the strength of the recommendations and uses inappropriate modal verbs ("must" and "can") that do not align with the standard's intent.

1. ISO 26262-6:2018, Road vehicles — Functional safety — Part 6: Product development at the software level.

Clause 5.3, "Notation in tables": This clause explicitly defines the meaning of the symbols used in the methods tables. It states:

"++" indicates that the method is highly recommended for the corresponding ASIL.

"+" indicates that the method is recommended for the corresponding ASIL.

Clause 5.4.2, "General requirements": This clause states, "The selection of measures shall be justified." This supports the part of the correct answer that mentions the need to "explain his choice."

2. Mariani, L., & Pastore, F. (2012). A Survey on the Role of Testing in the new ISO 26262 Functional Safety Standard. Politecnico di Milano, Tech. Rep.

Section 3, "The ISO 26262 Standard": This paper discusses the structure of the standard, explaining that the tables provide "recommendations about the techniques that should be adopted for the different ASILs," reinforcing that '++' and '+' are recommendations of different strengths, not absolute mandates or options.

3. University of Stuttgart, Course: "Safety in Automotive Engineering" (Sicherheit in der Fahrzeugtechnik).

Lecture notes on ISO 26262: Course materials frequently explain that the selection of methods from the standard's tables is a key part of the safety argument. They emphasize that while "highly recommended" (++) methods are not strictly mandatory, their non-use requires a rigorous and documented justification, thus they must be given "higher consideration."

Communication databases (e.g., CAN DBC, LIN LDF, ASAM FIBEX) define the application-layer data content for a vehicle network. This includes specifying messages, the signals they contain, scaling factors, and the relationships between ECUs (Electronic Control Units). However, these databases do not define the implementation of the communication protocol itself. The protocol implementation, which covers the rules for data framing, bus arbitration, error handling, and physical signaling (OSI Layers 1 and 2), is dictated by standards like ISO 11898 for CAN and is realized in the hardware (transceivers) and low-level software drivers of the ECUs.

A. This is incorrect because the primary purpose of a communication database is to describe the signals (e.g., engine speed, wheel angle) and how they are encoded into messages for transmission over a communication channel.

C. This is incorrect because these databases explicitly map which ECUs send (output) and receive (input) specific signals, forming the basis for system-wide communication and integration testing.

D. This is incorrect because the Association for Standardization of Automation and Measuring Systems (ASAM) provides standards like FIBEX (Field Bus Exchange Format), an XML-based format used to describe automotive networks, as an alternative to proprietary formats like DBC.

---

1. ISTQB® Certified Tester Foundation Level Automotive Software Tester Syllabus, Version 1.0 (2018), Section 3.2.2 Bus systems, p. 26. This section states, "The communication is described in specific description files (e.g., DBC for CAN, LDF for LIN, FIBEX for FlexRay)." This confirms that databases describe the communication content (signals, messages), not the protocol's fundamental implementation.

2. Lawrenz, W. (2016). CAN and CANopen. Springer Vieweg. In Chapter 2, "The CAN Protocol," the text details the ISO 11898 standard which defines the protocol's data link and physical layers. In contrast, Chapter 4, "Higher Layer Protocols," discusses the application layer where signal and message definitions, typically stored in a DBC file, reside. This illustrates the clear separation between the protocol definition and the database content.

3. ASAM e.V. (2020). ASAM FIBEX V4.1.1, Field Bus Exchange Format. The introduction and scope sections of this standard specify that FIBEX is used for "describing automotive communication networks," including signals, messages, and network topology. It is a data description standard, not a protocol implementation standard.

4. Zimmermann, W., & Schmidgall, R. (2014). Bussysteme in der Fahrzeugtechnik (5th ed.). Springer Vieweg. Chapter 5, "CAN-Grundlagen," explains that the CAN protocol is defined by ISO 11898. Chapter 5.8, "Applikationsprofile und DBC-Dateien," clarifies that DBC files describe the application-specific data (signals and messages) transmitted using the underlying, separately defined CAN protocol. (DOI: https://doi.org/10.1007/978-3-658-02419-2)

According to the Automotive SPICE® (ASPICE) Process Assessment Model, testing processes such as SWE.5 (Software Integration and Integration Test) and SWE.6 (Software Qualification Test) require the development of a test specification. This test specification (Work Product 17-50) must contain test cases designed to verify the software. A fundamental part of a test case is the procedure for its execution, which details the sequence of actions. Therefore, a "Test procedure specification," which documents these execution steps, is a required artifact to fulfill the base practices (e.g., SWE.6.BP2: Develop software qualification test specification) of the model.

B. A specific "Test management report" is not a formally mandated work product by the ASPICE testing processes, though test status is reported.

C. While metrics are essential for process capability, a distinct "Test metrics report" is not a required work product; results are part of the standard test report.

D. Load testing is a specific type of non-functional testing; ASPICE does not mandate this specific test type or its corresponding report for all projects.

---

1. Automotive SPICE® Process Assessment Model, Version 3.1 (2017). VDA Quality Management Center (QMC).

Section: Software Engineering Process Group (SWE), specifically processes SWE.5 and SWE.6.

Details: Base Practice SWE.6.BP2, "Develop software qualification test specification," requires the creation of Work Product 17-50 "Test Specification." The characteristics of this work product are defined to include "Test cases" and "Test procedures for executing the test cases," which directly corresponds to a test procedure specification.

2. Fünger, N., & GrGens, G. (2018). Basiswissen Automotive SPICE®. dpunkt.verlag.

Chapter: 4, Software Engineering Prozesse (SWE).

Details: The book, explaining the practical application of ASPICE, clarifies that the test specification required by processes like SWE.5 and SWE.6 must detail the test cases, including their preconditions, input data, and step-by-step execution procedures to ensure repeatability and verifiability, which is the definition of a test procedure specification.

Requirement 142 is not verifiable at the system test level. System testing typically validates a system from a black-box perspective, focusing on external inputs and observable outputs. The requirement to "send the message M-85" describes an internal design detail—an internal communication—rather than an externally observable system behavior. Verifying this would necessitate tools to monitor internal bus traffic, which is characteristic of integration or component testing, not system testing. The ISO/IEC/IEEE 29148 standard mandates that requirements must be verifiable. Since this requirement cannot be validated through typical system test approaches, it violates this quality criterion.

A. The requirement 85 is not atomic

Requirement 85 is atomic as it describes a single, indivisible function (the motor stops when resistance is met).

B. The requirement 37 is Inconsistent on system level.

Inconsistency for requirement 37 cannot be determined because no conflicting requirements are provided in the scenario.

C. The requirement 12 is ambiguous.

Requirement 12 is not ambiguous; the terms "central lock is activated" and "windows are automatically closed" are clear and well-understood in the automotive domain.

---

1. ISO/IEC/IEEE 29148:2011, Systems and software engineering — Life cycle processes — Requirements engineering.

Section 5.2.7.8 (Verifiable): This section states, "A requirement is verifiable if its satisfaction can be checked... Non-verifiable requirements include those that are subjective... or specify internal operations of the system that cannot be observed." Requirement 142 specifies an internal operation (sending message M-85) that is not observable from a system-level, black-box perspective, thus violating this characteristic.

2. Wiegers, K., & Beatty, J. (2013). Software Requirements (3rd ed.). Microsoft Press.

Chapter 11, "Specifying Requirements": This chapter distinguishes between functional requirements and design constraints. The requirement to "send the message M-85" is a design or implementation detail, not a true system requirement. A proper system requirement would state the externally observable behavior, such as "The window shall not move when a door is open."

3. Pohl, K. (2010). Requirements Engineering: Fundamentals, Principles, and Techniques. Springer Publishing.

Section 4.3.2 (Quality Criterion: Verifiability/Testability): Pohl explains that a requirement is verifiable if a finite, cost-effective process exists to check its satisfaction. Specifying internal messages makes verification at the system level difficult and costly, as it requires moving beyond black-box testing into more intrusive grey-box or white-box methods, which are typically not the focus of a system test. This aligns with the problem in requirement 142.

Automotive SPICE® is a two-dimensional framework designed to assess the capability of development processes. The first dimension is the Process Dimension, which contains the definitions of the processes used in automotive software development (e.g., engineering, management, support). The second dimension is the Capability Dimension, which provides a measurement scale for evaluating the maturity of each process. This scale consists of six capability levels, from Level 0 (Incomplete) to Level 5 (Optimizing), allowing for a standardized assessment of an organization's process maturity.

A. Resource dimension: Resources are managed within specific processes (e.g., MAN.3 Project Management) but do not constitute a fundamental dimension of the assessment model itself.

C. Objective dimension: Process objectives are integral components of the process definitions within the Process Dimension, not a separate, distinct dimension of the model.

D. Time dimension: Time is a critical project constraint handled by management processes, but it is not a structural dimension of the Automotive SPICE® framework.

1. VDA QMC. (2017). Automotive SPICE® Process Assessment Model, Version 3.1. Section 2.2, "The two-dimensional model", p. 10. This section explicitly states: "The model is two-dimensional. One dimension consists of processes (process dimension), the other one consists of a measurement scale for the capability of the processes (capability dimension)."

2. ISTQB®. (2021). Certified Tester Foundation Level Automotive Software Tester Syllabus, Version 1.0. Section 3.2.1, "Automotive SPICE® Process Reference Model and Process Assessment Model", p. 22. The syllabus states: "The PAM is two-dimensional. The first dimension is the process dimension... The second dimension is the capability dimension, which consists of six capability levels (0-5)..."

3. Messnarz, R., et al. (2013). A new process assessment model for safety critical systems development. Journal of Software: Evolution and Process, 25(6), 603-615. The paper describes the SPICE framework, stating, "ISO/IEC 15504 is a two-dimensional standard with a process dimension and a capability dimension." (Automotive SPICE® is based on ISO/IEC 15504). DOI: https://doi.org/10.1002/smr.578