Free Practice Questions for ISTQB ISTQB-CTFL Exam

The question is about identifying an example of testing contributing to higher quality. Quality is the degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations1. Testing is the process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects2.

Therefore, testing contributes to higher quality by verifying and validating that the software products and related work products meet the specified requirements, are fit for purpose and have no defects, or at least have a reduced number of defects. Testing also provides information about the quality of the software products and related work products to the stakeholders, who can make informed decisions based on the test results3.

Out of the four given statements, only option D is an example of testing contributing to higher quality, as it shows that testing has detected a defect (a flaw in a component or system that can cause the component or system to fail to perform its required function4) and that the defect has been resolved (fixed and confirmed) prior to release (delivery of the software product to the customer or end user). This means that testing has prevented a potential failure (an event in which a component or system does not perform a required function within specified limits) from occurring in the operational environment, and thus has improved the quality of the software product.

Option A is not an example of testing contributing to higher quality, as it is a reporting activity that summarizes the test results and evaluates the test objectives, but does not directly affect the quality of the software product or related work products. A test summary report is a document that records and communicates the outcomes of testing activities, including testcompletion criteria, test results, incident reports, test summary and evaluation, and lessons learned.

Option B is not an example of testing contributing to higher quality, as it is a planning activity that estimates the resources and time needed for testing activities, but does not directly affect the quality of the software product or related work products. A test effort estimate is an approximation of the amount of work and/or the duration of time required to perform testing activities.

Option C is not an example of testing contributing to higher quality, as it is a preparation activity that sets up the test environment (an environment containing hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test), but does not directly affect the quality of the software product or related work products. A test environment installation is a process of installing and configuring the test environment according to the test environment specification.

References:

1: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 10

2: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 11

3: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 12

4: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 13

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 13

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 77

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 78

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 79

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 80

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 81

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 82

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 83

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 84

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 85

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 86

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 87

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 88

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 89

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 90

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 91

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 92

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 93

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 94

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 95

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 96

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 97

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 98

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 99

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 100

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 101

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 102

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 103

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 104

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 105

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 106

: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 107

Statements II, III and V are true about test reports. Test reports are documents that provide information on the results and status of testing activities for a given period or phase. Test reports should give stakeholders information as basis for decisions, such as whether to release the software product, whether to continue testing, whether to change the scope or priorities of testing, etc. Test reports should summarize what happened through a period of testing, such as what test cases were executed, what defects were found, what risks were identified, what issues were encountered, what achievements were made, etc. Test reports should include information about remaining risks, such as what defects are still open, what test cases are still pending, what functionalities are still untested, what uncertainties are still unresolved, etc. Statements I and IV are not true about test reports. Test reports do not need to be approved by the test team, the development team, or the customer, unless it is specified by the test policy or the test plan. Test reports only need to be reviewed and verified by the test leader or the test manager before being distributed to the intended recipients. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, page 141.

Exploratory testing is an approach to testing that emphasizes learning, test design and test execution at the same time. Exploratory testing relies on the tester’s skills, creativity and intuition to explore the software under test and discover defects. Exploratory testing is suitable for a new project with little documentation and high probability for bugs, as it can help uncover unknown requirements, assumptions and risks. Exploratory testing is not requirements based testing, which is an approach to testing that derives test cases from documented requirements or specifications. Requirements based testing is not feasible for a new project with little documentation, as it requires clear and complete requirements to be available. Exploratory testing is not metric based approach, which is an approach to testing that uses quantitative measures to monitor and control the testing process and evaluate the quality of the software product. Metric based approach is not effective for a new project with high probability for bugs, as it may not capture all aspects of quality and may lead to false confidence or unrealistic expectations. Exploratory testing is not regression testing, which is an approach to testing that verifies that previously tested software still performs correctly after changes. Regression testing is not relevant for a new project with no previous versions or baselines. Verified References: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 5, page 47-48.

Branch coverage is a type of structural coverage metric that measures the percentage of branches or decision outcomes that are executed by the test cases. A branch is a point in the code where the control flow can take two or more alternative paths based on a condition. For example, an if-else statement is a branch that can execute either the if-block or the else-block depending on the evaluation of the condition. Branch coverage ensures that each branch is taken at least once by the test cases, and thus reveals the behavior of the software under different scenarios. Branch coverage is also known as decision coverage or all-edges coverage.

Branch coverage is suitable for testing the cases where a specific action is not allowed, because it can verify that the test cases cover all the possible outcomes of the conditions that determine the action. For example, if the program has a condition that checks if the manufacturing stage can be stopped, then branch coverage can ensure that the test cases cover both the cases where the stage can be stopped and where it cannot be stopped. This way, branch coverage can help identify any missing or incorrect branches that may lead to undesired or unsafe actions.

The other options are not correct because they are not suitable for testing the cases where a specific action is not allowed. Code coverage is a general term that encompasses various types of coverage metrics, such as statement coverage, branch coverage, data flow coverage, etc. Code coverage does not specify which type of coverage metric is used for the analysis. Data flow coverage is a type of structural coverage metric that measures the percentage of data flow paths that are executed by the test cases. A data flow path is a sequence of statements that define, use, or kill a variable. Data flow coverage is useful for testing the correctness and completeness of the data manipulation in the software, but not for testing the conditions that determine the actions. Statement coverage is a type of structural coverage metric that measures the percentage of statements or lines of code that are executed by the test cases. Statement coverage ensures that each statement is executed at least once by the test cases, but it does not reveal the behavior of the software under different scenarios. Statement coverage is a weaker criterion than branch coverage, because it does not account for the branches or decision outcomes in the code. References = ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus, Chapter 4: Test Techniques, Section 4.3: Structural Testing Techniques, Pages 51-54.

The benefits of continuous integration include: i. Allows earlier detection and easier root cause analysis of integration problems and conflicting changes. iv. Gives the development team regular feedback on whether the code is working. These benefits help in maintaining the stability and quality of the codebase by integrating and testing changes frequently and providing quick feedback to developers​​.

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

This answer is correct because the whole-team approach is a way of working in agile projects where all team members share the responsibility for the quality of the product, and collaborate on delivering value to the customer. The whole-team approach involves testers, developers, business analysts, product owners, and other stakeholders in planning, designing, developing, testing, and delivering the product. The whole-team approach fosters communication, feedback, learning, and continuous improvement within the team. References: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 3.1.1.1

To achieve 100% branch coverage of the process flow, we need to test both the true and false outcomes of the condition (User presses Cancel). Branch coverage is a type of structural testing that measures how many decision outcomes in a program have been executed by a test suite. Branch coverage can be used to assess the adequacy or completeness of a test suite.

To test the true outcome of the condition, we need a test case that simulates the user pressing Cancel after booking a bill. This test case will exit the loop and end the process flow.

To test the false outcome of the condition, we need a test case that simulates the user not pressing Cancel after booking a bill. This test case will repeat the loop and book another bill.

Therefore, we need at least two test cases to achieve 100% branch coverage of the process flow. One test case for each possible outcome of the condition.

Verified References: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer], Chapter 4, page 40-41.

A typical product risk involves issues directly related to the software product's functionality, performance, usability, reliability, etc. Option A, "Poor usability of the software," directly impacts the end-user's interaction with the software and is a quality attribute of the product itself, making it a product risk. Options B, "A problem in the code developed by a 3rd party," C, "Low quality of the configuration data, test data and tests," and D, "Problem in defining the right requirements," can be considered either product or project risks depending on the context, but option A is the most directly associated with a typical product risk concerning the quality and usability of the software.

When a manager asks when testing will be complete, the most appropriate and informative resource to provide an answer is test progress reports (Option A). Test progress reports contain detailed information on the status of testing activities, including what has been accomplished, what remains to be done, the results of the tests conducted, and any issues or risks that might impact the completion of testing. These reports allow for an informed assessment of the testing progress and estimation of when testing might be completed. Options B, C, and D do not provide the structured, detailed, and specific information required to accurately answer the manager's question about the completion of testing.