Free ISTQB ISTQB-CTFL Practice Exam with Questions & Answers | Set: 6

Selecting the right test technique is crucial because different techniques are suited to different types of testing and can significantly increase the effectiveness of the testing process by creating tests that are more likely to find defects. While reducing the number of tests (A) and defining the number of regression cycles (D) are considerations in the testing process, they are not the primary reasons for selecting a test technique. The assertion that the only way to test a software application is by using well-proven test techniques (B) is too restrictive and does not acknowledge the adaptability required in testing to suit different contexts and objectives. Therefore, option C is the most comprehensive reason, as it focuses on the effectiveness and efficiency of testing, leading to the creation of high-quality tests that have a higher chance of finding bugs.

Comprehensive and Detailed In-Depth Explanation:Test management focuses on planning and control activities. Test planning (II) involves defining test strategies, schedules, and resources, while test monitoring and control (V) ensures that testing activities are aligned with objectives and tracked effectively. Other activities, such as test design (I) and peer review facilitation (IV), are typically handled by testers or test leads.

The minimum number of test cases needed to cover the full decision table associated with this scenario is 6. This is because the decision table has 4 conditions (type of customer and amount of sale) and 4 actions (bonus percentage). The conditions have 2 possible values each (Basic or Premium, and G1, G2 or G3), so the total number of combinations is 2 x 2 x 2 x 2 = 16. However, not all combinations are valid, as some of them are contradictory or impossible. For example, a sale cannot be both less than 300 euros and greater than 2000 euros at the same time. Therefore, we need to eliminate the invalid combinations and keep only the valid ones. The valid combinations are:

Type of customer

Amount of sale

Bonus percentage

Basic

G1

3%

Basic

G2

5%

Basic

G3

7%

Premium

G1

5%

Premium

G2

7%

Premium

G3

10%

These 6 combinations cover all the possible values of the conditions and actions, and they are the minimum number of test cases needed to cover the full decision table.

References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents,

In software testing terminology, a failure is an observable deviation of the software from its expected behavior. A defect (or bug) is the cause of the failure in the software's code. In this case, the observed slowdown is the failure, while the underlying memory leak in the application code is the defect causing this failure. This distinction is clearly outlined in the ISTQB CTFL Syllabus v4.0, which differentiates between failures (observable issues) and defects (underlying issues in the code)​​.

The key principles of software testing include: i. Testing shows the presence of defects, not their absence. iv. Defects cluster together. v. Testing is context dependent. vi. Beware of the pesticide paradox. vii. Absence of errors is a fallacy. These principles highlight the importance of recognizing the limitations and context of testing, as well as the potential for repeated tests to become less effective​​.

An incident is any event that occurs during testing that requires investigation. An incident report is a document that records the details of an incident. The next step the tester should take prior to recording the deviation is to try to recreate the incident before reporting. This can help confirm that the incident is reproducible and not caused by a random or external factor. This can also help gather more information about the incident, such as the steps to reproduce it, the expected and actual results, the severity and priority of the incident, or any screenshots or logs that can illustrate the incident. Trying to identify the code fragment causing the problem is not the next step the tester should take prior to recording the deviation, as this is a debugging activity that is usually performed by developers after receiving the incident report. Sending an email to the developer and not reporting the bug is not the next step the tester should take prior to recording the deviation, as this is an informal and unstructured way of communicating incidents that can lead to confusion, inconsistency or loss of information. Reporting the incident as is without any further action is not the next step the tester should take prior to recording the deviation, as this can result in incomplete or inaccurate incident reports that can hamper the investigation and resolution of incidents. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, Chapter 3, page 32-33.

Exercising at least one of the decision outcomes for all decisions within the code, ensures achieving full branch coverage, which is a test coverage criterion that requires that all branches in the control flow of the code are executed at least once by the test cases. A branch is a basic block of code that has a single entry point and a single exit point, and a decision is a point in the code where the control flow can take more than one direction, such as an if-then-else statement, a switch-case statement, a loop statement, etc. The decision outcomes are the possible paths that can be taken from a decision, such as the then branch or the else branch, the case branch or the default branch, the loop body or the loop exit, etc. The other statements are false, because:

The minimum number of test cases needed to achieve full branch coverage, is usually higher than that needed to achieve full statement coverage, which is a test coverage criterion that requires that all executable statements in the code are executed at least once by the test cases. This is because branch coverage is a stronger criterion than statement coverage, as it implies statement coverage, but not vice versa. For example, a single test case can achieve full statement coverage for an if-then-else statement, but two test cases are needed to achieve full branch coverage, as both the then branch and the else branch need to be exercised.

If full branch coverage has been achieved, then all unconditional branches within the code have not necessarily been exercised, as unconditional branches are branches that do not depend on any decision, and are always executed, such as a goto statement, a break statement, a return statement, etc. Unconditional branches are not part of the branch coverage criterion, as they do not represent different paths in the control flow of the code. However, they are part of the statement coverage criterion, as they are executable statements in the code.

If full branch coverage has been achieved, then all combinations of conditions in a decision table have not necessarily been exercised, as a decision table is a test design technique that represents the logical relationships between multiple conditions and their corresponding actions, in a tabular format. A decision table can have more combinations of conditions than the number of decision outcomes in the code, as each condition can have two or more possible values, such as true or false, yes or no, etc. For example, a decision table with four conditions can have 16 combinations of conditions, but the corresponding code may have only two decision outcomes, such as pass or fail. To exercise allcombinations of conditions in a decision table, a stronger test coverage criterion is needed, such as condition combination coverage, which requires that all possible combinations of condition outcomes in the code are executed at least once by the test cases. References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:

ISTQB® Certified Tester Foundation Level Syllabus v4.0, Chapter 2.3.1, Test Coverage Criteria Based on the Structure of the Software

ISTQB® Glossary of Testing Terms v4.0, Branch Coverage, Statement Coverage, Branch, Decision, Decision Outcome, Unconditional Branch, Decision Table, Condition Combination Coverage

Acceptance testing is a level of testing performed to verify that a software product meets the agreed acceptance criteria and is acceptable for delivery. Acceptance testing is often performed by the customers or system users, who are the main stakeholders of the software product. The main goal of acceptance testing is to build confidence in the system, not find defects, as defects should have been detected and fixed in earlier levels of testing. Acceptance testing is the last level of testing performed prior to system release, unless there are any changes or fixes that require re-testing. Testing of disaster recovery and backup/restore is usually part of acceptance testing, as these are important aspects of system reliability and security that affect the customer satisfaction and trust. Therefore, statement A is not correct, while statements B, C and D are correct. Verified References: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer, Chapter 2, page 20-21.

The testing of software does not demonstrate the absence of defects, but rather the presence of defects or the conformance of the software to the specified requirements1. Testingcan never prove that the software is defect-free, as it is impossible to test all possible scenarios, inputs, outputs, and behaviors of the software2. Testing can only provide a level of confidence in the quality of the software, based on the coverage, effectiveness, and efficiency of the testing activities3.

The other options are correct because:

A. Properly designed tests that pass reduce the level of risk in a system, as they verify that the system meets the expected quality attributes and satisfies the needs and expectations of the users and clients4. Risk is the potential for loss or harm due to the occurrence of an undesirable event5. Testing can help to identify, analyze, prioritize, and mitigate the risks associated with the software product and project6.

C. Software testing identifies defects, whichcan be used to improve development activities, as they provide feedback on the quality of the software and the effectiveness of the development processes7. Defects are flaws or errors in the software that cause it to deviate from the expected or required results or behavior. Testing can help to detect, report, track, and resolve the defects, and prevent them from recurring in the future.

D. Performing a review of the requirement specifications before implementing the system can enhance quality, as it can ensure that the requirements are clear, complete, consistent, testable, and aligned with the needs and expectations of the users and clients. Requirements are the specifications of what the software should do and how it should do it. Testing can help to validate that the requirements are met by the software, and verify that the software is implemented according to the requirements.

References =

1 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 10

2 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 11

3 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 12

4 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 13

5 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 97

6 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 98

7 ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 14

[8] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 15

[9] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 16

[10] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 17

[11] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 18

[12] ISTQB® Certified Tester Foundation Level Syllabus v4.0, 2023, p. 19

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