ISTQB Certified Tester Foundation Level Free Sample Questions

The principle of 'shift left' encourages moving testing activities earlier in the lifecycle. By performing more thorough component and component integration testing as soon as code is available, defects can be found and fixed closer to when they were introduced. This is more efficient and prevents them from escalating into more complex issues found during system testing. UAT is too late, maintenance testing is post-release, and static analysis alone might miss runtime integration issues.

Interoperability testing is crucial for an IoT system to ensure that the diverse components (sensors, hub, cloud, mobile app), which may be from different vendors or use different protocols, can communicate and work together correctly.

Security testing is paramount for IoT devices as they are often targets for cyber-attacks. Ensuring data privacy, secure communication between devices and the cloud, and protection against unauthorized access is a critical non-functional requirement.

Inspections are the most formal type of review. They are characterized by a rigorously defined process, specified entry and exit criteria, formal roles (like Moderator, Scribe, Reviewer), and the collection of metrics to improve both the product and the review process itself. The author does not lead the meeting, and the primary goal is defect detection, not brainstorming.

A major risk in test automation is setting unrealistic expectations. Stakeholders may believe automation is a 'silver bullet' that replaces manual testing entirely and finds all bugs. In reality, automation is best for repetitive tasks like regression testing, but it requires significant investment in creation and maintenance, and it is not a substitute for the critical thinking and exploratory abilities of a manual tester.

The absence-of-errors fallacy states that finding and fixing a large number of defects does not guarantee the success of a system if the system itself does not meet user needs or is unusable. In this case, even though all specified requirements were tested and passed (absence of errors), the system was still unsafe because the requirements missed a critical real-world scenario. Verification (testing against requirements) was done, but validation (ensuring it's fit for purpose) failed.

The role of the test manager is not to unilaterally approve or block a release but to provide clear, data-driven information to stakeholders so they can make an informed business decision. The most professional and appropriate action is to communicate the exact testing status, including coverage of high-risk areas and the specific residual risks (open defects, untested areas). This allows stakeholders to formally accept the risk before proceeding.

A good title (e.g., 'Crash on file upload with >10MB PNG file') immediately informs the developer of the problem's nature and context.

This is the most critical part of a defect report. Without clear, repeatable steps, the developer may be unable to find, diagnose, or fix the bug.

Clearly stating what happened (actual result: 'Application crashes') versus what should have happened (expected result: 'File uploads successfully and a confirmation message appears') defines the failure and removes ambiguity.

Static testing involves examining work products (like source code) without executing them. Static analysis tools automate this process by checking the code against predefined rules and patterns to find potential defects, such as the null pointer exception mentioned. It is not dynamic testing because the code was not run.

This statement describes regression testing. The primary purpose of confirmation testing is to verify that the original reported defect has been successfully fixed. Regression testing is the separate activity performed to check for unintended side effects (new defects) in unchanged parts of the software.

Product risks are related to the quality and characteristics of the software itself (what it does). A failure to secure data is a quality issue inherent to the product. Project risks are related to the management and execution of the project (how it's built), such as staff leaving, budget cuts, or schedule delays.