Free Practice Questions for ISTQB ISTQB-CTFL Exam

Matching the descriptions with the test techniques:

Black-box test techniques use the external description of the software, including requirements, use cases, and user stories.

White-box test techniques use the internal structure of the software system, including software architecture and code.

Black-box test techniques can reveal deviations from the requirements as they validate the external behavior of the software.

Both black-box and white-box test techniques are applicable to functional and non-functional testing.

Good testing practice dictates that each test level (e.g., unit testing, integration testing, system testing) should have distinct test objectives aligned with the phase of the software development lifecycle it addresses. This ensures that testing is effective and relevant at each stage. According to the ISTQB CTFL Syllabus v4.0, establishing clear test objectives that are consistent with the development phase helps in achieving specific goals and improving the overall quality of the software product​​.

The correct statement is B. According to the ISTQB CTFL syllabus, the testing quadrants help to categorize tests based on their purpose and whether they are technology-facing or business-facing, and whether they support the team or critique the product. Quadrant Q2 includes tests that are business-facing and support the team, such as automated acceptance tests produced during Behavior-Driven Development (BDD) and Acceptance Test-Driven Development (ATDD)​​ .

Quadrant Q3 includes business-facing tests that critique the product, such as exploratory testing, usability testing, and user acceptance testing. These tests are typically manual and focus on evaluating the product from a user perspective, rather than being part of a continuous integration process​​.

Quadrant Q4 includes technology-facing tests that critique the product, such as performance tests, security tests, and other non-functional tests, which can be automated but are not related to unit tests produced during TDD .

The principle of early testing is applicable to all recognized software development models, including sequential, iterative, and incremental models. Starting test activities early in the lifecycle helps in identifying and addressing defects as soon as possible, which can save time and costs by preventing defects from propagating to later stages of development. This proactive approach enhances the overall quality and efficiency of the software development process. Reference: ISTQB CTFL Syllabus V4.0, Section 1.3

The support offered by a performance testing tool is often leveraged by testers to run load tests, which are tests that simulate a large number of concurrent users or transactions on the system under test, in order to measure its performance, reliability, and scalability. Performance testing tools can help testers to generate realistic workloads, monitor system behavior, collect and analyze performance metrics, and identify performance bottlenecks. The other statements are false, because:

A test data preparation tool is a tool that helps testers to create, manage, and manipulate test data, which are the inputs and outputs of test cases. Test data preparation tools are not directly related to running automated regression test suites, which are test suites that verify that the system still works as expected after changes or modifications. Regression test suites are usually executed by test execution tools, which are tools that can automatically run test cases and compare actual results with expected results.

A bug prediction tool is a tool that uses machine learning or statistical techniques to predict the likelihood of defects in a software system, based on various factors such as code complexity, code churn, code coverage, code smells, etc. Bug prediction tools are not used by testers to track the bugs they found, which are the actual defects that have been detected and reported during testing. Bugs are usually tracked by defect management tools, which are tools that help testers to record, monitor, analyze, and resolve defects.

A continuous integration tool is a tool that enables the integration of code changes from multiple developers into a shared repository, and the execution of automated builds and tests, in order to ensure the quality and consistency of the software system. Continuous integration tools are not used by testers to automatically generate test cases from a model, which are test cases that are derived from a representation of the system under test, such as a state diagram, a decision table, a use case, etc. Test cases can be automatically generated by test design tools, which are tools that support the implementation and maintenance of test cases, based on test design specifications or test models. References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 3.4.1, Types of Test Tools

ISTQB® Glossary of Testing Terms v4.0, Performance Testing Tool, Test Data Preparation Tool, Bug Prediction Tool, Continuous Integration Tool, Test Execution Tool, Defect Management Tool, Test Design Tool

Comprehensive and Detailed In-Depth Explanation:

Business, development, and testing (C) are the three key perspectives in agile user story refinement:

Business (Product Owner, Stakeholders) – Ensures the story aligns with user needs and business goals.

Development (Developers) – Provides insights on feasibility and technical constraints.

Testing (Testers, QA) – Ensures testability, acceptance criteria, and risk identification.

(A) is incorrect because the product owner is part of business stakeholders.

(B) is incorrect because architecture is part of development, but not the primary driver of user stories.

(D) is incorrect because acceptance testing is a process, not a stakeholder group.

A cross-functional team collaboration ensures well-defined, testable, and feasible user stories.

A defect is a flaw in a component or system that can cause the component or system to fail to perform its required function. A defect can cause harm to the end customer, the company, or both, depending on the impact and severity of the failure. In this case, the defect in the code causes the system to lock down accounts that have an overdraft higher than $1000, instead of $10,000. This can cause harm to the end customer, as they may lose access to their funds and face inconvenience or financial difficulties. This can also cause harm to the company, as they may lose customer trust and satisfaction, face legal issues or complaints, or incur additional costs for fixing the defect and restoring the accounts. Verified References: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 1, page 3-4.