Free Practice Questions for ISTQB CTFL-Foundation Exam

For a safety-critical system, it is essential to ensure that regression tests are run and passed following defect corrections at all test levels. Additionally, tracking incidents raised and closed at all levels of testing helps ensure that all defects are addressed and the system meets safety standards. These metrics provide a comprehensive view of both the completeness of testing and the effectiveness of defect resolution.

White box testing design is characterized by its focus on the internal structure of the component or system. It involves testing based on knowledge of the code structure, architecture, and internal design. This approach contrasts with black box testing, which is based on functional specifications without any knowledge of the internal workings of the software.

When evaluating risks, both the likelihood of failure and the potential cost of impact must be considered. The risk with the highest level is determined by the product of these two factors. In this case, a 10% likelihood of failure with a potential cost of impact of $500,000 results in a higher risk (expected impact) compared to the other options. The expected impact is calculated as likelihood multiplied by impact, which is higher for option B​​.

Top of Form

Bottom of Form

According to the IEEE 829 Standard for Software Test Documentation, an incident report should include the identification of configuration items of the software or system (i), the software or system lifecycle process in which the incident was observed (ii), a description of the anomaly to enable reproduction of the incident (iii), and the classification of the cause of the incident formetrics and reporting purposes (v). The number of occurrences of the incident is not typically included.

Component testing, also known as unit testing, involves testing individual components of the software separately. This type of testing focuses on the functionality of a specific section of the code. To facilitate this process, stubs and drivers are often used. Stubs are dummy modules that simulate the behavior of lower-level modules that are not yet integrated. Drivers are used to simulate higher-level modules that control the component being tested.

The four test levels defined for a common V-model testing approach are Component, Integration, System, and Acceptance testing. These levels align with the development stages in the V-model,where each level of testing corresponds to a specific phase in the software development lifecycle, ensuring comprehensive verification and validation of the software​​.

Metrics are used to measure various aspects of the testing process, such as the percentage of work done in test environment preparation, test case preparation, and whether test milestones were met. However, metrics are not specifically used to apply to the RAD (Rapid Application Development) development model. Metrics focus on providing data to evaluate and improve the testing process rather than applying to specific development methodologies.

Testing is primarily used to identify defects in the software. While it can show the presence of defects, it cannot guarantee that no defects are present. Thus, testing helps in demonstrating that there are defects, which can then be addressed.

A valid objective of testing is to prevent defects. While correcting defects and locating defects in the code are part of the testing process, the primary goal is often to prevent defects by identifying issues early in the development cycle and improving the overall quality of the software. Ensuring no defects are present is an unrealistic objective, as testing can demonstrate the presence of defects but not their absence.