ISTQB® CTFL 4.0 Sample Exam Questions

Describes the desired outcome of testing, focusing on reducing risk and increasing confidence in the product's quality.

Incorporating testers into various SDLC stages helps catch defects early, improving the overall process.

Testing principle highlighting the need for regularly updating regression tests, as old tests might not effectively reveal new defects.

A testing principle warning against the assumption that the absence of found defects indicates product quality.

The process of analyzing the testing requirements and goals, including identifying what needs to be tested.

Various factors, including SDLC, product risks, and regulatory requirements, influence the chosen testing approach.

Tasks primarily associated with the testing role, including planning, analyzing test basis, and creating test plans.

Possessing domain knowledge, being a strong team player, and utilizing critical thinking are vital skills for a tester.

The whole team approach encourages collaboration between testers and business representatives, allowing testers to contribute to the overall strategy and create acceptance tests.

The rule applies across sequential, incremental, and iterative SDLC models, emphasizing the presence of corresponding test activities for each development stage.

Acceptance Test Driven Development (ATDD) prioritizes creating tests based on acceptance criteria to guide the development process.

Shift left approach involves integrating testing activities earlier in the SDLC, such as reviewing requirements before formal acceptance or writing component tests before code.

Retrospectives are valuable because they allow identifying and analyzing process weaknesses, enabling continuous improvement initiatives.

Test levels map to specific failure types. Component testing focuses on module logic, component integration testing addresses inter-component communication, system testing checks system behavior, and acceptance testing aligns with user needs.

Tests re-executed after defects are fixed are considered regression tests. These tests aim to ensure that the fix did not introduce new issues.

The main benefits of static testing include finding defects earlier and cheaper, detecting potential issues that dynamic testing might miss, and identifying inconsistencies in requirements.

Early and frequent feedback helps to identify and address requirements misunderstandings, reducing the risk of later issues.

Technical reviews are most likely used when the review process involves a scribe, focuses on quality evaluation, is led by the author, has individual preparation, and produces a review report.

Factors contributing to successful reviews include dedicated time, breaking down large work products, maintaining a respectful environment, and objectively handling identified failures.

Experience-based test techniques rely heavily on the tester's knowledge and experience of the software and the business domain, unlike techniques that rely on design information or coverage metrics.

Equivalence partitioning (EP) aims to cover all valid and invalid input values for a given input parameter, ensuring that representative values from each equivalence class are tested.

Boundary Value Analysis (BVA) focuses on testing values at the boundaries of input ranges and partitions, aiming to identify potential edge-case issues.

Decision tables are a technique for representing complex decision logic, showing different combinations of conditions and their corresponding actions.

In state transition testing, each valid transition between states needs to be covered by at least one test case, ensuring that the system behaves correctly in different states.

Statement coverage ensures that every line of code or statement has been executed at least once. This doesn't necessarily mean that all paths or logic branches are covered.

White-box testing focuses on the internal code structure, considering all implementation details. It helps identify gaps in requirements implementation and uses coverage metrics to guide further testing.

Error guessing involves using knowledge and experience of common defects or errors to proactively identify potential issues during testing.

Exploratory testing is a flexible approach that allows testers to investigate the software based on their intuition and experience, making it particularly useful when time is tight and detailed documentation is missing.

Acceptance criteria should be documented in a clear and concise way, such as using the given/when/then format, which helps to ensure that there is a common understanding of the requirements among all stakeholders.

Testers add value during planning by participating in risk identification and assessment for user stories, ensuring that testing focuses on the most critical areas and potential issues.

Exit criteria define the conditions that need to be met before testing of a system can be considered complete. These criteria often include achieving a specific defect density, completing regression testing, and reaching a stable test environment.

The three-point estimation technique provides a more realistic estimate for test effort by considering the most optimistic, most likely, and most pessimistic scenarios.

Test cases are prioritized based on their criticality and dependencies. Higher-priority test cases, especially those with dependencies, should be executed earlier in the testing process.

Agile testing quadrants categorize test activities based on their focus and purpose. Quadrant 1 involves technology-facing tests supporting the development team, Quadrant 2 focuses on business-facing tests also supporting the development team, Quadrant 3 involves business-facing tests critiquing the product, and Quadrant 4 involves technology-facing tests critiquing the product.

Risk mitigation involves implementing measures to reduce the likelihood or impact of identified risks. This can be done through various strategies, such as implementing specific testing activities or improving processes.

A burndown chart visually tracks the amount of work remaining in a sprint or iteration, providing a clear picture of progress towards the sprint goal.

Configuration management is a process that ensures that changes to testware are tracked and managed appropriately, preventing accidental overwrites or unauthorized modifications.

To be fully informative, a defect report should include all relevant details, such as the expected result, actual result, test environment, and test item. This helps developers understand and reproduce the issue.

Data preparation tools support test design and implementation by creating and managing data sets for testing. This can be crucial for scenarios involving large volumes of data or specific data combinations.

A potential risk of test automation is the insufficient allocation of resources for maintaining testware. If test scripts are not regularly updated and maintained, they might become outdated or unreliable, leading to false positives or missed defects.

Debugging involves analyzing the code to identify and correct the root cause of a defect. It is done by developers or specialized debugging teams.

While the terms are sometimes used interchangeably, testing focuses on detecting defects and verifying product functionality, while QA encompasses a broader approach to quality, including processes, standards, and improvement.

The incorrectly coded upper boundary in this scenario represents a defect, as it deviates from the expected behaviour and allows invalid input values.

This testware output is produced during test design, specifically in the exploratory testing phase, where the focus is on exploring the software behaviour with various inputs to discover potential defects.

Traceability helps to connect test cases to requirements and other work products, facilitating impact analysis during changes. This helps to select the right test cases for regression testing, ensuring that changes do not introduce new issues.

Independence in testing helps to minimize bias and ensures that the testing process is objective. This is especially important when testing complex systems or when the development and testing teams hold different perspectives.

In the V-model, static testing and test planning can be performed during the initial phases of the SDLC. Dynamic test execution and acceptance test execution happen later in the cycle.

DevOps practices offer advantages such as faster product releases, constant availability of executable software, and efficient regression testing through automation. Setting up test automation frameworks does not necessarily become less expensive with DevOps.

The test performed is a non-functional test, specifically a performance test, as it measures the system's ability to meet predefined performance criteria, in this case, processing time for orders.

Data migration testing is typically performed as part of maintenance testing, which focuses on ensuring the quality of changes and updates made to an existing software system.

All the listed work products, including business requirements, schedule, test budget, third-party executable code, and user stories with acceptance criteria, can be reviewed to ensure their quality and to identify potential issues.

Static testing involves analyzing work products without executing code. It focuses on identifying defects early in the SDLC, including analyzing coding standards, identifying discrepancies from requirements, and finding missing security requirements. It does not identify failures caused during runtime.

Formal review processes consist of multiple activities, including planning, distribution, preparation, review, recording, and defect resolution.

During a formal review, management plays a crucial role by taking overall responsibility, ensuring the smooth running of review meetings, and mediating discussions if necessary.

The minimal set of test inputs for achieving 100% 3-point BVA coverage includes the boundary values: 10, 12, and 14. This covers both valid and invalid values, including the edge cases.

Branch testing ensures that each decision outcome in a decision statement in the code has been exercised at least once. However, this is not necessarily guaranteed with 100% statement coverage.

The test technique used is checklist-based testing, as it involves evaluating the user interface against a predefined set of best practices.

The collaborative approach emphasizes the joint effort of business representatives, developers, and testers in creating user stories. This ensures that the stories effectively capture business value, are clear to implement, and can be tested.

The mentioned part of the test plan belongs to the Test Approach section, as it outlines the specific testing techniques and approaches that will be used, including the required coverage level for critical components.

When consensus is not reached in planning poker, but the variation in estimations is small, it's acceptable to choose the number with the most votes. It's not necessary to remove the feature or involve the product owner in this case.

The test pyramid emphasizes having more tests at lower levels, such as unit tests, and fewer tests at higher levels, such as UI tests. This approach prioritizes testing core functionality at lower levels, which leads to a more efficient and sustainable testing process.

High risk impact does not automatically translate to high risk likelihood. Risk likelihood and impact are independent factors. It's important to assess both to determine the overall severity of a risk.

Project risks are external factors that can affect the project's success. In this scenario, management moving testers to another project and stakeholders having inaccurate expectations are project risks, as they can directly impact the testing process and resources.

Product risk analysis helps to determine the testing scope and thoroughness by identifying and analyzing potential issues that could affect the product's quality. In this scenario, high performance risks lead to detailed performance efficiency testing, ensuring that the product meets performance requirements.

Common metrics for reporting on the quality level of the test object include defect density (defects found per work product size) and defect leakage (defects discovered later in the SDLC). Other options might be useful for specific purposes but are less widely used for reporting on overall quality.

Information on branch coverage is least useful for business representatives, as it is a technical metric primarily relevant to developers and testers. Business representatives are primarily interested in metrics that reflect the product's usability, functionality, and compliance with requirements.