Your Path to Success: How to Pass the iSQI CTFL_Syll2018 ISTQB Certified Tester Foundation Level (Syllabus 2018) Exam

A decision table is a specification-based test technique that involves creating a table that shows the combinations of inputs and outputs for a system under test based on certain conditions and rules. A decision table can be used to design test cases that cover all possible scenarios and outcomes for a system under test. Some statements about decision tables are:

• I. Generally, decision tables are generated for low risk test items: This statement is false because decision tables can be generated for any level of risk test items depending on the complexity and variability of the system under test. Decision tables are especially useful for testing systems that have many inputs, outputs, conditions, and rules that affect their behavior or performance.
• II. Test cases derived from decision tables can be used for component tests: This statement is true because decision tables can be used to design test cases for any level or type of testing, including component tests. Component tests are tests that verify individual components or units of software in isolation from other components or systems.
• III. Several test cases can be selected for each column of the decision table: This statement is true because each column of the decision table represents a unique combination of inputs and outputs for the system under test based on certain conditions and rules. Therefore, each column can be used as a basis for selecting one or more test cases that cover that combination.
• IV. The conditions in the decision table represent negative tests generally: This statement is false because the conditions in the decision table can represent both positive and negative tests depending on the requirements and expectations of the system under test. Positive tests are tests that verify that the system under test behaves as expected under valid or normal inputs or conditions. Negative tests are tests that verify that the system under test handles errors or exceptions gracefully under invalid or abnormal inputs or conditions.

You can find more information about decision tables in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.

Pair programming is a software development technique where two programmers work together on the same code at the same workstation. One programmer, called the driver, writes the code while the other programmer, called the navigator, reviews the code and provides feedback and suggestions. Pair programming is not only a coding technique but also an informal review method because it involves constant communication and collaboration between the programmers who check each other’s work and share their knowledge and skills. Pair programming can improve the quality and productivity of software development by reducing defects, increasing code readability, enhancing learning opportunities, and fostering creativity and innovation. Pair programming is usually used in agile methods such as Extreme Programming (XP), Scrum, or Kanban. It is not an alternative term for code inspection, which is a formal review method where a group of reviewers examine a piece of code in a structured and systematic way following predefined rules and roles. It is also not done with developer and tester pairing together because pair programming requires both programmers to have similar levels of expertise and familiarity with the code they are working on. You can find more information about pair programming in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 31.

The most important report improvement is A. Add an impact analysis. An impact analysis is an assessment of how the defect affects the functionality, usability, performance, reliability, security, or other aspects of the system under test. An impact analysis can help prioritize and classify the defect based on its severity and urgency. An impact analysis can also help determine the root cause and possible solutions for the defect. An impact analysis is an essential part of a defect report because it provides useful information for decision-making and improvement processes.

The other report improvements are not as important as adding an impact analysis because they do not provide as much information or value for decision-making and improvement processes. For example:

• B. Add information about which developer should fix the bug: This report improvement is not necessary because it is not part of the information that is required to describe, reproduce, and prioritize the defect. The assignment of developers to fix bugs is part of the defect management process, which involves assigning, tracking, resolving, and verifying defects.
• C. Add the time stamp when the incident happened: This report improvement is not very useful because it does not provide much information about the cause or effect of the defect. The time stamp when the incident happened is only relevant if it is related to some external factors or events that could influence the behavior or performance of the system under test.
• D. Add information about which web browser was used: This report improvement is not very relevant because it does not affect the functionality or usability of the system under test. The web browser used is only relevant if it is related to some compatibility or interoperability issues that could cause defects or failures in the system under test.

You can find more information about defect reports and impact analysis in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 5.

The requirement given in the image specifies an additional fee of $3 that is charged during the weekend, with some exceptions and discounts based on the age of the visitors. To test this requirement, we can use boundary value analysis, which is a specification-based test technique that involves testing the values at or near the boundaries of an equivalence partition. An equivalence partition is a set of values that are expected to be treated in the same way by the system under test. For example, based on the requirement, we can identify the following equivalence partitions for the input age:

• EP1: Age < 0 (invalid)
• EP2: Age = 0 (valid, no charge)
• EP3: 0 < Age < 7 (valid, no charge)
• EP4: Age = 7 (valid, 20% discount)
• EP5: 7 < Age < 13 (valid, 20% discount)
• EP6: Age = 13 (valid, 20% discount)
• EP7: 13 < Age < 65 (valid, full charge)
• EP8: Age = 65 (valid, 50% discount)
• EP9: Age > 65 (valid, 50% discount)

The boundary values for each equivalence partition are the values at or near the edges of the partition. For example, the boundary values for EP3 are 1 and 6. The boundary values for EP4 are 6 and 7. The boundary values for EP5 are 7 and 12. And so on.

To test this requirement using boundary value analysis, we need to select one value from each boundary and test it with different combinations of weekend and weekday. For example, we can select the following values:

• BV1: Age = -1 (from EP1)
• BV2: Age = 0 (from EP2 and EP3)
• BV3: Age = 6 (from EP3 and EP4)
• BV4: Age = 7 (from EP4 and EP5)
• BV5: Age = 12 (from EP5 and EP6)
• BV6: Age = 13 (from EP6 and EP7)
• BV7: Age = 64 (from EP7 and EP8)
• BV8: Age = 65 (from EP8 and EP9)
• BV9: Age = 66 (from EP9)

We can then create test cases using these values and different combinations of weekend and weekday. For example:

• TC1: Age = -1, Weekend = Yes -> Invalid input
• TC2: Age = -1, Weekend = No -> Invalid input
• TC3: Age = 0, Weekend = Yes -> No charge
• TC4: Age = 0, Weekend = No -> No charge
• TC5: Age = 6, Weekend = Yes -> No charge
• TC6: Age = 6, Weekend = No -> No charge
• TC7: Age = 7, Weekend = Yes -> $2.40 ($3 - 20% discount)
• TC8: Age = 7, Weekend = No -> No charge
• TC9: Age = 12, Weekend = Yes -> $2.40 ($3 - 20% discount)
• TC10: Age = 12, Weekend = No -> No charge
• TC11: Age = 13, Weekend = Yes -> $2.40 ($3 - 20% discount)
• TC12: Age = 13, Weekend = No -> No charge
• TC13: Age = 64, Weekend = Yes -> $3
• TC14: Age = 64, Weekend = No -> No charge
• TC15: Age = 65, Weekend = Yes -> $1.50 ($3 - 50% discount)
• TC16: Age = 65, Weekend = No -> No charge
• TC17: Age = 66, Weekend = Yes -> $1.50 ($3 - 50% discount)
• TC18: Age =

66, Weekend = No -> No charge

Therefore, we need a minimum of 18 valid test cases to achieve 100% boundary value coverage based on input age.

$3.01 is not a valid output boundary value because it is not a possible output value based on the requirement. The output values can only be $0, $1.50, $2.40, or $3 depending on the input age and weekend status.

You can find more information about boundary value analysis in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.

Testing has several objectives that aim to provide information and confidence about the quality and risk level of the software product and to support decision-making and improvement processes. Some of these objectives are:

• Finding defects: Testing is the process of finding defects or failures in the software product that do not meet its requirements or expectations.
• Providing information for decision-making: Testing is the process of providing information about the quality and risk level of the software product based on the observed behavior and results under certain conditions and assumptions. This information can help stakeholders make informed decisions about releasing, deploying, accepting, or improving the software product.
• Gaining confidence about the level of quality of the software: Testing is the process of gaining confidence that the software product meets its requirements and expectations and provides value to the users and customers.
• Analyzing and removing the cause of failures: Testing is not only the process of finding defects but also the process of analyzing and removing the cause of failures that lead to defects. This objective is related to debugging, which is a development activity that involves locating, diagnosing, and fixing errors in the code or design of the software product.

You can find more information about the objectives of testing in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 1, Section 1.2.

To achieve 100% statement coverage, you need to execute every statement in the code at least once. In this case, you need two test cases: one where condition A is true and one where condition A is false. This way, you can cover both the DO B statement and the END IF statement. You can find more information about statement coverage in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 4, Section 4.31.

The statement that does not describe how testing contributes to higher quality is “The testing of software demonstrates the absence of defects”. This statement is false because testing cannot prove that a software system is defect-free or has a certain level of quality because there might be some untested inputs or outputs that could reveal defects or failures. Testing can only provide information about the quality and risk level of a software system based on the observed behavior and results under certain conditions and assumptions. The other statements describe how testing contributes to higher quality by:

• Performing a review of the requirement specifications before implementing the system can enhance quality: This statement is true because reviewing the requirement specifications can help identify and prevent defects, ambiguities, inconsistencies, or incompleteness in the requirements before they are implemented in the system, which can save time and effort and improve customer satisfaction.
• Properly designed tests that pass reduce the level of risk in a system: This statement is true because passing tests can increase confidence that the system meets its requirements and expectations and provides value to the users and customers. Passing tests can also reduce the probability or impact of failures or defects in the system that could cause harm or loss.
• Software testing identifies defects, which can be used to improve development activities: This statement is true because identifying defects can help analyze and remove their causes and prevent them from recurring in future development activities. Identifying defects can also help improve development processes, methods, standards, tools, techniques, etc., by providing feedback and lessons learned.

You can find more information about how testing contributes to higher quality in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 1.

Memory leaks are errors that occur when a program does not release memory that it has allocated, causing the system to run out of memory and slow down or crash. Memory leaks cannot be detected by structure-based testing techniques, which are based on the code structure and logic. Structure-based testing techniques can only find errors that are related to the control flow, data flow, or logic of the program. For example, they can find errors such as features that are only partially implemented, data structures that are used before initialization, or division by zero. To detect memory leaks, you need dynamic analysis tools that monitor the memory usage of the program during execution. You can find more information about structure-based testing techniques and dynamic analysis tools in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 4, Sections 4.2 and 4.31.

The ‘Standard for Software Test Documentation’ specification (IEEE 829) is a standard that defines a set of documents that can be used to document the test process and its outcomes. The standard provides an outline for each document, specifying its purpose, content, and format. However, the standard does not prescribe how to apply it in different contexts or projects. It is up to each organization or project to decide how to adapt the standard to their specific needs and situation. Therefore, the standard is not a rigid or mandatory requirement that must be followed strictly by all testers. Rather, it is a flexible and adaptable guideline that can be used as a reference or a starting point for creating test documentation regimes. You can find more information about IEEE 829 and test documentation in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 51.

Functional testing is an example of black-box dynamic testing. Functional testing is the process of testing the functionality or behavior of a software system based on its requirements or specifications. Functional testing does not require any knowledge of the internal structure or implementation of the system under test; it only focuses on what the system does rather than how it does it. Functional testing is also an example of dynamic testing because it involves executing the software system with selected inputs and observing its outputs and effects on the environment. Dynamic testing is different from static testing, which involves examining the software system without executing it, such as code inspection, static analysis, etc. You can find more information about functional testing and dynamic testing in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 21.