Question #1
Which of the following is correct with regards to debugging?
- A . Debugging identifies the cause of a failure
- B . Debugging is often performed by test engineers
- C . Debugging is considered part of the testing activities
- D . Debugging is intended to find as many defects as possible in the code
Correct Answer: A
A
Explanation:
Debugging is the process of finding, analyzing and removing the causes of failures in software. Debugging is not considered part of testing, but rather a development activity that can involve testing. Debugging is not intended to find as many defects as possible, but rather to fix the specific failure that was observed. Debugging is usually performed by developers, not by test engineers.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 1, page 6.
A
Explanation:
Debugging is the process of finding, analyzing and removing the causes of failures in software. Debugging is not considered part of testing, but rather a development activity that can involve testing. Debugging is not intended to find as many defects as possible, but rather to fix the specific failure that was observed. Debugging is usually performed by developers, not by test engineers.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 1, page 6.
Question #2
Which statement about use case testing is true?
- A . The lest cases are designed to find defects in the data flew.
- B . The test cases are designed to be used by real users, not by professional testers
- C . The test cases are always designed by customers or end users.
- D . The test cases are designed to find defects in the process flow.
Correct Answer: D
D
Explanation:
Use case testing is a technique that helps identify test cases that exercise the whole system on a transaction by transaction basis from start to finish. Use cases are descriptions of how users interact with the system to achieve a specific goal. Use case testing is not focused on data flow, but rather on process flow. Use case testing can be performed by professional testers, customers or end users,
depending on the context. Use case testing does not require the test cases to be designed by customers or end users, but rather by anyone who has access to the use case specifications.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 4, page 36.
D
Explanation:
Use case testing is a technique that helps identify test cases that exercise the whole system on a transaction by transaction basis from start to finish. Use cases are descriptions of how users interact with the system to achieve a specific goal. Use case testing is not focused on data flow, but rather on process flow. Use case testing can be performed by professional testers, customers or end users,
depending on the context. Use case testing does not require the test cases to be designed by customers or end users, but rather by anyone who has access to the use case specifications.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 4, page 36.
Question #3
A software module to be used in a mission critical application incorporates an algorithm for secure transmission of data.
Which review type is most appropriate to ensure high quality and technical correctness of the algorithm?
- A . Walkthrough
- B . Informal Review
- C . Technical Review
- D . Management Review
Correct Answer: C
C
Explanation:
A technical review is a type of formal review that involves a team of technical experts who evaluate a software product against a set of predefined quality criteria. A technical review is suitable for ensuring high quality and technical correctness of complex or critical software components, such as algorithms, architectures or designs. A technical review is not a walkthrough, which is an informal review led by the author of the work product. A technical review is not an informal review, which is a review that does not follow a defined process and has no formal entry or exit criteria. A technical review is not a management review, which is a type of formal review that focuses on business aspects and project progress.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 3, page 29-30.
C
Explanation:
A technical review is a type of formal review that involves a team of technical experts who evaluate a software product against a set of predefined quality criteria. A technical review is suitable for ensuring high quality and technical correctness of complex or critical software components, such as algorithms, architectures or designs. A technical review is not a walkthrough, which is an informal review led by the author of the work product. A technical review is not an informal review, which is a review that does not follow a defined process and has no formal entry or exit criteria. A technical review is not a management review, which is a type of formal review that focuses on business aspects and project progress.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 3, page 29-30.
Question #4
Which of the following is NOT a deciding factor m determining the extent of testing required?
- A . Level of risk of the product or features
- B . Budget to do testing
- C . A particular tester involved in testing
- D . Time available to do testing
Correct Answer: C
C
Explanation:
The extent of testing required for a software product depends on various factors, such as the level of risk, the budget, and the time available. The level of risk reflects the potential impact of failures on the stakeholders and the environment. The budget determines how much resources can be allocated for testing. The time available defines the schedule and deadlines for testing activities. The particular tester involved in testing is not a deciding factor for the extent of testing required, as testing should be based on objective criteria and not on personal preferences or abilities.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 2, page 14-15.
C
Explanation:
The extent of testing required for a software product depends on various factors, such as the level of risk, the budget, and the time available. The level of risk reflects the potential impact of failures on the stakeholders and the environment. The budget determines how much resources can be allocated for testing. The time available defines the schedule and deadlines for testing activities. The particular tester involved in testing is not a deciding factor for the extent of testing required, as testing should be based on objective criteria and not on personal preferences or abilities.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 2, page 14-15.
Question #4
Which of the following is NOT a deciding factor m determining the extent of testing required?
- A . Level of risk of the product or features
- B . Budget to do testing
- C . A particular tester involved in testing
- D . Time available to do testing
Correct Answer: C
C
Explanation:
The extent of testing required for a software product depends on various factors, such as the level of risk, the budget, and the time available. The level of risk reflects the potential impact of failures on the stakeholders and the environment. The budget determines how much resources can be allocated for testing. The time available defines the schedule and deadlines for testing activities. The particular tester involved in testing is not a deciding factor for the extent of testing required, as testing should be based on objective criteria and not on personal preferences or abilities.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 2, page 14-15.
C
Explanation:
The extent of testing required for a software product depends on various factors, such as the level of risk, the budget, and the time available. The level of risk reflects the potential impact of failures on the stakeholders and the environment. The budget determines how much resources can be allocated for testing. The time available defines the schedule and deadlines for testing activities. The particular tester involved in testing is not a deciding factor for the extent of testing required, as testing should be based on objective criteria and not on personal preferences or abilities.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 2, page 14-15.
Question #4
Which of the following is NOT a deciding factor m determining the extent of testing required?
- A . Level of risk of the product or features
- B . Budget to do testing
- C . A particular tester involved in testing
- D . Time available to do testing
Correct Answer: C
C
Explanation:
The extent of testing required for a software product depends on various factors, such as the level of risk, the budget, and the time available. The level of risk reflects the potential impact of failures on the stakeholders and the environment. The budget determines how much resources can be allocated for testing. The time available defines the schedule and deadlines for testing activities. The particular tester involved in testing is not a deciding factor for the extent of testing required, as testing should be based on objective criteria and not on personal preferences or abilities.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 2, page 14-15.
C
Explanation:
The extent of testing required for a software product depends on various factors, such as the level of risk, the budget, and the time available. The level of risk reflects the potential impact of failures on the stakeholders and the environment. The budget determines how much resources can be allocated for testing. The time available defines the schedule and deadlines for testing activities. The particular tester involved in testing is not a deciding factor for the extent of testing required, as testing should be based on objective criteria and not on personal preferences or abilities.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 2, page 14-15.
Question #4
Which of the following is NOT a deciding factor m determining the extent of testing required?
- A . Level of risk of the product or features
- B . Budget to do testing
- C . A particular tester involved in testing
- D . Time available to do testing
Correct Answer: C
C
Explanation:
The extent of testing required for a software product depends on various factors, such as the level of risk, the budget, and the time available. The level of risk reflects the potential impact of failures on the stakeholders and the environment. The budget determines how much resources can be allocated for testing. The time available defines the schedule and deadlines for testing activities. The particular tester involved in testing is not a deciding factor for the extent of testing required, as testing should be based on objective criteria and not on personal preferences or abilities.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 2, page 14-15.
C
Explanation:
The extent of testing required for a software product depends on various factors, such as the level of risk, the budget, and the time available. The level of risk reflects the potential impact of failures on the stakeholders and the environment. The budget determines how much resources can be allocated for testing. The time available defines the schedule and deadlines for testing activities. The particular tester involved in testing is not a deciding factor for the extent of testing required, as testing should be based on objective criteria and not on personal preferences or abilities.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 2, page 14-15.
Question #8
If not ST certified with 5-10 years of testing experience – allow limited access.
What would be the results for:
A – ST certified. 12 years of testing experience
B – Not ST certified. 7 years of testing experience
C – Not ST certified. 3 years of testing experience
- A . A – unknown
B – limned access
C- unknown - B . A – full access
B – limited access
C – unknown - C . A – full access
B – limited access
C – limited access - D . A – unknown
B – full access
C – unknown
Correct Answer: B
B
Explanation:
The correct answer can be derived by applying the given rules to each case:
A is ST certified and has 12 years of testing experience, which is more than 10 years. Therefore, A does not match any of the rules and the result is unknown.
B is not ST certified and has 7 years of testing experience, which is between 5 and 10 years.
Therefore, B matches rule 3 and the result is limited access.
C is not ST certified and has 3 years of testing experience, which is less than 5 years. Therefore, C does not match any of the rules and the result is unknown.
Verified Reference: This question does not require any external references, as it is based on logical reasoning.
B
Explanation:
The correct answer can be derived by applying the given rules to each case:
A is ST certified and has 12 years of testing experience, which is more than 10 years. Therefore, A does not match any of the rules and the result is unknown.
B is not ST certified and has 7 years of testing experience, which is between 5 and 10 years.
Therefore, B matches rule 3 and the result is limited access.
C is not ST certified and has 3 years of testing experience, which is less than 5 years. Therefore, C does not match any of the rules and the result is unknown.
Verified Reference: This question does not require any external references, as it is based on logical reasoning.
Question #9
A system computes prices for bus tickets.
The price depends on
– the passenger type (baby, child, adult, senior citizen, student, military)
– the travelling type (as single or in a group)
– the distance (zone 1. 2. 3)
– the kind of transport (ordinary, express)
Which of the following test techniques is the most appropriate one for testing the price computation?
- A . Statement coverage
- B . State transition testing
- C . Equivalence partitioning
- D . Use case testing
Correct Answer: C
C
Explanation:
Equivalence partitioning is a technique that divides the input data and output results of a software component into partitions of equivalent data. Each partition should contain data that is treated in the same way by the component. Equivalence partitioning can be used to reduce the number of test cases by selecting one representative value from each partition. Equivalence partitioning is suitable for testing the price computation, as it can identify different partitions based on the passenger type, the travelling type, the distance and the kind of transport. Equivalence partitioning is not statement coverage, which is a technique that measures how many executable statements in a source code are executed by a test suite. Statement coverage is not appropriate for testing the price computation, as it does not consider the input data or output results. Equivalence partitioning is not state transition testing, which is a technique that models how a system transitions from one state to another depending on events or conditions. State transition testing is not relevant for testing the price computation, as it does not involve any states or transitions. Equivalence partitioning is not use case testing, which is a technique that tests how users interact with a system to achieve a specific goal. Use case testing is not applicable for testing the price computation, as it does not focus on a single function or component.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 4, page 37-38.
C
Explanation:
Equivalence partitioning is a technique that divides the input data and output results of a software component into partitions of equivalent data. Each partition should contain data that is treated in the same way by the component. Equivalence partitioning can be used to reduce the number of test cases by selecting one representative value from each partition. Equivalence partitioning is suitable for testing the price computation, as it can identify different partitions based on the passenger type, the travelling type, the distance and the kind of transport. Equivalence partitioning is not statement coverage, which is a technique that measures how many executable statements in a source code are executed by a test suite. Statement coverage is not appropriate for testing the price computation, as it does not consider the input data or output results. Equivalence partitioning is not state transition testing, which is a technique that models how a system transitions from one state to another depending on events or conditions. State transition testing is not relevant for testing the price computation, as it does not involve any states or transitions. Equivalence partitioning is not use case testing, which is a technique that tests how users interact with a system to achieve a specific goal. Use case testing is not applicable for testing the price computation, as it does not focus on a single function or component.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 4, page 37-38.
Question #10
Which test approach will best fit a new project, with little documentation and high probability for bugs?
- A . Exploratory testing
- B . Requirements based testing
- C . Metric based approach
- D . Regression testing
Correct Answer: A
A
Explanation:
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 Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 5, page 47-48.
A
Explanation:
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 Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 5, page 47-48.
Question #11
The following requirement is given “Set X to be the sum of Y and Z”.
All the following four implementations have bugs.
Which one of the following bugs can be caught by Static Analysis?
- A . int x = 1. int y = 2. int y = 3. X = y=z;
- B . int x = 1. int y = 2. int z = 3. X = z-y
- C . int x = 1. Int y = 2. Int z = 3. Z = x +y
- D . int y = 2 Int z = 3. Y = z+y
Correct Answer: A
A
Explanation:
Static analysis is a technique that analyzes the source code or other software artifacts without executing them. Static analysis can detect defects such as syntax errors, coding standards violations, potential security vulnerabilities, or logical flaws. Static analysis can catch the bug in the first implementation, as it contains two syntax errors: the variable y is declared twice, and the assignment statement X = y=z is invalid. Static analysis cannot catch the bugs in the other three implementations, as they are logical errors that do not violate any syntax rules, but produce incorrect results.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 3, page 25-26.
A
Explanation:
Static analysis is a technique that analyzes the source code or other software artifacts without executing them. Static analysis can detect defects such as syntax errors, coding standards violations, potential security vulnerabilities, or logical flaws. Static analysis can catch the bug in the first implementation, as it contains two syntax errors: the variable y is declared twice, and the assignment statement X = y=z is invalid. Static analysis cannot catch the bugs in the other three implementations, as they are logical errors that do not violate any syntax rules, but produce incorrect results.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 3, page 25-26.
Question #12
For a mandatory input field "ZIP code" the following rules are given:
1 – The valid ZIP code format is 5 numeric digits.
2 – The code has to exist in the post office’s official ZIP code list
Using equivalence classes partitioning, how many test cases are required to test this field?
- A . 8
- B . 3
- C . 6
- D . 4
Correct Answer: D
D
Explanation:
Equivalence classes partitioning is a technique that divides the input data and output results of a software component into partitions of equivalent data. Each partition should contain data that is treated in the same way by the component. Equivalence classes partitioning can be used to reduce the number of test cases by selecting one representative value from each partition.
For the ZIP code field, there are four equivalence classes based on the given rules:
Valid ZIP code format and valid ZIP code value (e.g., 12345)
Valid ZIP code format and invalid ZIP code value (e.g., 99999)
Invalid ZIP code format and valid ZIP code value (e.g., 1234)
Invalid ZIP code format and invalid ZIP code value (e.g., ABCDE)
Therefore, four test cases are required to test this field, one for each equivalence class.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 4, page 37-38.
D
Explanation:
Equivalence classes partitioning is a technique that divides the input data and output results of a software component into partitions of equivalent data. Each partition should contain data that is treated in the same way by the component. Equivalence classes partitioning can be used to reduce the number of test cases by selecting one representative value from each partition.
For the ZIP code field, there are four equivalence classes based on the given rules:
Valid ZIP code format and valid ZIP code value (e.g., 12345)
Valid ZIP code format and invalid ZIP code value (e.g., 99999)
Invalid ZIP code format and valid ZIP code value (e.g., 1234)
Invalid ZIP code format and invalid ZIP code value (e.g., ABCDE)
Therefore, four test cases are required to test this field, one for each equivalence class.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 4, page 37-38.
Question #13
A bank software has a feature of locking down accounts that have and overdraft higher than $10,000.
Due to a bug in the code, the system locks down accounts once they reached $1000 overdraft.
Based on this context, which of the following is correct statement
- A . It is an example of a defect that it goes undetected, will cause harm to the end customer and to the company (the bank)
- B . It is an example of a defect, that if goes undetected, will cause harm to the end customer but not to the company (the bank)
- C . It is an example of a defect that if goes undetected, will not cause harm to the end customer, but will cause harm to the company (the bank)
- D . It is an example of a defect that if goes undetected, will not cause any real harm to either the end customer or to the company (the bank)
Correct Answer: A
A
Explanation:
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 Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 1, page 3-4.
A
Explanation:
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 Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 1, page 3-4.
Question #14
Which of the following is a function of a dynamic analysis tool?
- A . Provide support for traceability of tests, test results and incidents to source documents
- B . Monitor the allocation, use and de-allocation of memory during run-time of a program
- C . Execute programs step-by-step in order to reproduce failures and find corresponding defects
- D . Provide support for release of baselines consisting of configuration items
Correct Answer: B
B
Explanation:
A dynamic analysis tool is a tool that performs analysis of a software product based on its behavior during execution. A dynamic analysis tool can monitor various aspects of a program’s run-time performance, such as memory usage, CPU load, response time, or resource leaks. A dynamic analysis tool can monitor the allocation, use and de-allocation of memory during run-time of a program, which can help detect defects such as memory leaks, buffer overflows, or memory corruption. A dynamic analysis tool cannot provide support for traceability of tests, test results and incidents to source documents, as this is a function of a test management tool. A dynamic analysis tool cannot execute programs step-by-step in order to reproduce failures and find corresponding defects, as this is a function of a debugging tool. A dynamic analysis tool cannot provide support for release of baselines consisting of configuration items, as this is a function of a configuration management tool.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 6, page 56-57.
B
Explanation:
A dynamic analysis tool is a tool that performs analysis of a software product based on its behavior during execution. A dynamic analysis tool can monitor various aspects of a program’s run-time performance, such as memory usage, CPU load, response time, or resource leaks. A dynamic analysis tool can monitor the allocation, use and de-allocation of memory during run-time of a program, which can help detect defects such as memory leaks, buffer overflows, or memory corruption. A dynamic analysis tool cannot provide support for traceability of tests, test results and incidents to source documents, as this is a function of a test management tool. A dynamic analysis tool cannot execute programs step-by-step in order to reproduce failures and find corresponding defects, as this is a function of a debugging tool. A dynamic analysis tool cannot provide support for release of baselines consisting of configuration items, as this is a function of a configuration management tool.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 6, page 56-57.
Question #15
Which sequence of state transition stated in the answer choices is correct in accordance with the following figure depicting me life-cycle of a defect?
- A . S0->S1->S2->S3->S4
- B . S0->S1->S2->S3->S5^>S1
- C . S0->S1->S2->S3->S5->S1->S2->S3
- D . S0->S1->S2->S3->S5->S3->S4
Correct Answer: C
C
Explanation:
The figure depicts the life-cycle of a defect using state transition testing. State transition testing is a technique that models how a system transitions from one state to another depending on events or conditions. The figure shows six states (S0 to S5) and seven transitions (T0 to T6). The correct sequence of state transitions that follows the figure is S0->S1->S2->S3->S5->S1->S2->S3.
This sequence represents the following scenario:
S0: The defect is not yet detected (initial state).
T0: The defect is detected by testing (event).
S1: The defect is reported and registered (state).
T1: The defect is assigned to a developer for fixing (event).
S2: The defect is being fixed by the developer (state).
T2: The developer fixes the defect and delivers a new version (event).
S3: The defect is verified by testing (state).
T5: The testing fails to confirm that the defect is fixed (event).
S5: The defect is rejected by testing (state).
T6: The defect is reassigned to a developer for fixing (event).
S1: The defect is reported and registered (state).
T1: The defect is assigned to a developer for fixing (event).
S2: The defect is being fixed by the developer (state).
T2: The developer fixes the defect and delivers a new version (event).
S3: The defect is verified by testing (state).
The other sequences are incorrect, as they do not follow the transitions shown in the figure.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 4, page 40-41.
C
Explanation:
The figure depicts the life-cycle of a defect using state transition testing. State transition testing is a technique that models how a system transitions from one state to another depending on events or conditions. The figure shows six states (S0 to S5) and seven transitions (T0 to T6). The correct sequence of state transitions that follows the figure is S0->S1->S2->S3->S5->S1->S2->S3.
This sequence represents the following scenario:
S0: The defect is not yet detected (initial state).
T0: The defect is detected by testing (event).
S1: The defect is reported and registered (state).
T1: The defect is assigned to a developer for fixing (event).
S2: The defect is being fixed by the developer (state).
T2: The developer fixes the defect and delivers a new version (event).
S3: The defect is verified by testing (state).
T5: The testing fails to confirm that the defect is fixed (event).
S5: The defect is rejected by testing (state).
T6: The defect is reassigned to a developer for fixing (event).
S1: The defect is reported and registered (state).
T1: The defect is assigned to a developer for fixing (event).
S2: The defect is being fixed by the developer (state).
T2: The developer fixes the defect and delivers a new version (event).
S3: The defect is verified by testing (state).
The other sequences are incorrect, as they do not follow the transitions shown in the figure.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 4, page 40-41.
Question #16
Which of the following statements about Experience Based Techniques (EBT) is correct?
- A . EBT use tests derived from the test engineers’ previous experience with similar technologies.
- B . EBT is based on the ability of the test engineer to implement various testing techniques.
- C . EBT is done as a second stage of testing, after non-experienced-based testing took place.
- D . EBT require broad and deep knowledge in testing but not necessarily in the application or technological domain.
Correct Answer: A
A
Explanation:
Experience based techniques (EBT) are techniques that use the knowledge, intuition and skills of the test engineers to design and execute tests. EBT use tests derived from the test engineers’ previous experience with similar technologies, domains, applications or systems. EBT are not based on the ability of the test engineer to implement various testing techniques, but rather on their personal judgment and creativity. EBT are not done as a second stage of testing, after non-experience-based testing took place, but rather as a complementary or alternative approach to other techniques. EBT require broad and deep knowledge in both testing and the application or technological domain, as this can help the test engineer identify potential risks, scenarios or defects.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 5, page 48-49.
A
Explanation:
Experience based techniques (EBT) are techniques that use the knowledge, intuition and skills of the test engineers to design and execute tests. EBT use tests derived from the test engineers’ previous experience with similar technologies, domains, applications or systems. EBT are not based on the ability of the test engineer to implement various testing techniques, but rather on their personal judgment and creativity. EBT are not done as a second stage of testing, after non-experience-based testing took place, but rather as a complementary or alternative approach to other techniques. EBT require broad and deep knowledge in both testing and the application or technological domain, as this can help the test engineer identify potential risks, scenarios or defects.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 5, page 48-49.
Question #17
Software was found lo take much more time than the stated requirement of less than one second to save a file. Upon investigation it was found that there was an unnecessary check inside a loop which was slowing down the file-save operation. The software not being able to meet the desired response time is an example of
- A . It is not a defect
- B . Defect
- C . Error
- D . Failure
Correct Answer: D
D
Explanation:
A failure is an event in which a component or system does not perform a required function within specified limits. A failure is observable by the software users or other stakeholders. A failure is caused by one or more defects in the software. In this case, the software not being able to meet the desired response time is an example of a failure, as it deviates from the stated requirement and affects the user experience. It is not a defect, which is a flaw in the software that causes the failure. It is not an error, which is a human action that produces an incorrect result. It is not a non-defect, as it clearly violates a specified requirement.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 1, page 4.
D
Explanation:
A failure is an event in which a component or system does not perform a required function within specified limits. A failure is observable by the software users or other stakeholders. A failure is caused by one or more defects in the software. In this case, the software not being able to meet the desired response time is an example of a failure, as it deviates from the stated requirement and affects the user experience. It is not a defect, which is a flaw in the software that causes the failure. It is not an error, which is a human action that produces an incorrect result. It is not a non-defect, as it clearly violates a specified requirement.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 1, page 4.
Question #18
Which of the following statements about independent testing is WRONG?
- A . Independent testing is necessary because developers don’t know any testing.
- B . Independent testing is best suited for the system test level.
- C . A certain degree of independence makes the tester more effective at finding defects.
- D . Independent test teams may find other types of detects than developers who are familiar with the system’s structure.
Correct Answer: A
A
Explanation:
Independent testing is testing performed by a person or group that is independent of the development team. Independent testing can have various degrees of independence, ranging from testers who are part of the same organization as developers to testers who are external contractors or consultants. Independent testing can have various benefits, such as reducing bias, increasing objectivity, improving quality, or providing different perspectives. Independent testing is not necessary because developers don’t know any testing, as this is a wrong and disrespectful statement. Developers can perform various types of testing, such as unit testing, component testing, or integration testing. However, independent testing can complement developer testing by providing additional levels of verification and validation, such as system testing, acceptance testing, or non-functional testing.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 2, page 16-17.
A
Explanation:
Independent testing is testing performed by a person or group that is independent of the development team. Independent testing can have various degrees of independence, ranging from testers who are part of the same organization as developers to testers who are external contractors or consultants. Independent testing can have various benefits, such as reducing bias, increasing objectivity, improving quality, or providing different perspectives. Independent testing is not necessary because developers don’t know any testing, as this is a wrong and disrespectful statement. Developers can perform various types of testing, such as unit testing, component testing, or integration testing. However, independent testing can complement developer testing by providing additional levels of verification and validation, such as system testing, acceptance testing, or non-functional testing.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 2, page 16-17.
Question #19
In which of the following cases you would NOT execute maintenance testing?
- A . Retirement of the software or system
- B . Modifications to a released software or system
- C . Migration of the system data to a replacement system
- D . Update to the Maintainability requirements during the development phase
Correct Answer: D
D
Explanation:
Maintenance testing is testing performed on a software product after delivery to correct defects or improve performance or other attributes. Maintenance testing can be triggered by various situations, such as modifications to a released software or system, migration of the system data to a replacement system, or retirement of the software or system. Maintenance testing is not executed when there is an update to the maintainability requirements during the development phase, as this is not a maintenance situation but rather a change request that should be handled by the development process.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 2, page 18-19.
D
Explanation:
Maintenance testing is testing performed on a software product after delivery to correct defects or improve performance or other attributes. Maintenance testing can be triggered by various situations, such as modifications to a released software or system, migration of the system data to a replacement system, or retirement of the software or system. Maintenance testing is not executed when there is an update to the maintainability requirements during the development phase, as this is not a maintenance situation but rather a change request that should be handled by the development process.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 2, page 18-19.
Question #20
Manager responsibilities in formal review includes ad except one of the following:
- A . Planning the review
- B . Determines if the review objectives have been met
- C . Decide on the execution of reviews
- D . Allocate time for review
Correct Answer: B
B
Explanation:
A formal review is a type of review that follows a defined process with formal entry and exit criteria and roles and responsibilities for participants. A formal review can have various roles involved, such as manager, moderator, author, reviewer and scribe. The manager responsibilities in formal review include all except one of the following:
Planning the review (correct responsibility)
Determines if the review objectives have been met (incorrect responsibility)
Decide on the execution of reviews (correct responsibility)
Allocate time for review (correct responsibility) The responsibility of determining if the review objectives have been met belongs to the moderator role, not to the manager role.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 3, page 28-29.
B
Explanation:
A formal review is a type of review that follows a defined process with formal entry and exit criteria and roles and responsibilities for participants. A formal review can have various roles involved, such as manager, moderator, author, reviewer and scribe. The manager responsibilities in formal review include all except one of the following:
Planning the review (correct responsibility)
Determines if the review objectives have been met (incorrect responsibility)
Decide on the execution of reviews (correct responsibility)
Allocate time for review (correct responsibility) The responsibility of determining if the review objectives have been met belongs to the moderator role, not to the manager role.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 3, page 28-29.
Question #21
Which ONE of the following statements about acceptance testing is NOT correct?
- A . Testing of disaster recovery and backup/restore is usually NOT part of acceptance testing.
- B . The customers or system users are often responsible for the acceptance testing.
- C . The main goal of acceptance testing is to build confidence in the system, not find defects.
- D . Acceptance testing is the last level of testing performed prior to system release.
Correct Answer: A
A
Explanation:
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 Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 2, page 20-21.
A
Explanation:
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 Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 2, page 20-21.
Question #22
Which are the MAIN goals of risk management in a software project?
- A . To increase the success probability for the project regardless of costs.
- B . To increase focus on preventative processes and to increase satisfaction for the testers.
- C . To control contractual problems and minimize the impacts of company policies.
- D . To reduce the probability of undesired situations and to reduce the effect of potential impact.
Correct Answer: D
D
Explanation:
Risk management is a process that identifies, analyzes, evaluates and mitigates risks in a software project. Risks are factors that may negatively affect the quality, schedule, budget or scope of a software project. The main goals of risk management in a software project are to reduce the probability of undesired situations and to reduce the effect of potential impact. This can be achieved by applying various strategies, such as avoidance, transfer, reduction or acceptance. Risk management does not aim to increase the success probability for the project regardless of costs, as this may not be feasible or realistic. Risk management does not aim to increase focus on preventative processes and to increase satisfaction for the testers, as these are secondary or indirect outcomes. Risk management does not aim to control contractual problems and minimize the impacts of company policies, as these are specific types of risks that may not apply to all projects.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 2, page 14-15.
D
Explanation:
Risk management is a process that identifies, analyzes, evaluates and mitigates risks in a software project. Risks are factors that may negatively affect the quality, schedule, budget or scope of a software project. The main goals of risk management in a software project are to reduce the probability of undesired situations and to reduce the effect of potential impact. This can be achieved by applying various strategies, such as avoidance, transfer, reduction or acceptance. Risk management does not aim to increase the success probability for the project regardless of costs, as this may not be feasible or realistic. Risk management does not aim to increase focus on preventative processes and to increase satisfaction for the testers, as these are secondary or indirect outcomes. Risk management does not aim to control contractual problems and minimize the impacts of company policies, as these are specific types of risks that may not apply to all projects.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 2, page 14-15.
Question #23
A team’s test strategy was to invest equal effort in testing each of a system’s modules. After running one test cycle, it turned out that most of the critical bugs were detected in one of the system’s modules.
Which testing principal suggests a change to the current test strategy for the next test cycle?
- A . Pesticide Paradox
- B . Early testing
- C . Absence-of-errors fallacy
- D . Defect clustering
Correct Answer: D
D
Explanation:
Defect clustering is a testing principle that states that a small number of modules contain most of the defects detected during pre-release testing, or are responsible for most of the operational failures. Defect clustering can be explained by Pareto’s principle (also known as the 80-20 rule), which states that approximately 80% of the problems are found in 20% of the modules. Defect clustering suggests a change to the current test strategy for the next test cycle, as it implies that more effort should be allocated to test the modules that have shown high defect density or criticality. Pesticide paradox is another testing principle that states that if the same tests are repeated over and over again, eventually they will no longer find any new defects. Pesticide paradox suggests a change to the current test strategy for the next test cycle, but not based on defect clustering, but rather on test diversity and coverage. Early testing is a testing principle that states that testing activities should start as early as possible in the software development life cycle and should be focused on defined objectives. Early testing does not suggest a change to the current test strategy for the next test cycle, but rather a proactive approach to prevent defects from occurring or propagating. Absence-of-errors fallacy is a testing principle that states that finding and fixing defects does not help if the system built is unusable and does not fulfill the users’ needs and expectations. Absence-of-errors fallacy does not suggest a change to the current test strategy for the next test cycle, but rather a focus on quality attributes and user requirements.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 1, page 9-10.
D
Explanation:
Defect clustering is a testing principle that states that a small number of modules contain most of the defects detected during pre-release testing, or are responsible for most of the operational failures. Defect clustering can be explained by Pareto’s principle (also known as the 80-20 rule), which states that approximately 80% of the problems are found in 20% of the modules. Defect clustering suggests a change to the current test strategy for the next test cycle, as it implies that more effort should be allocated to test the modules that have shown high defect density or criticality. Pesticide paradox is another testing principle that states that if the same tests are repeated over and over again, eventually they will no longer find any new defects. Pesticide paradox suggests a change to the current test strategy for the next test cycle, but not based on defect clustering, but rather on test diversity and coverage. Early testing is a testing principle that states that testing activities should start as early as possible in the software development life cycle and should be focused on defined objectives. Early testing does not suggest a change to the current test strategy for the next test cycle, but rather a proactive approach to prevent defects from occurring or propagating. Absence-of-errors fallacy is a testing principle that states that finding and fixing defects does not help if the system built is unusable and does not fulfill the users’ needs and expectations. Absence-of-errors fallacy does not suggest a change to the current test strategy for the next test cycle, but rather a focus on quality attributes and user requirements.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 1, page 9-10.
Question #24
In what way do Configuration Management effects testing?
- A . Without proper configuration management, test planning cannot proceed.
- B . Proper configuration management ensures that testers can uniquely identity the tested item
- C . Configuration management is important for developers, not for testers
- D . There is very little influence of configuration management practices on the test project.
Correct Answer: B
B
Explanation:
Configuration management is a process that establishes and maintains consistency among work products throughout their life cycle.
Configuration management affects testing in various ways, such as:
Proper configuration management ensures that testers can uniquely identify the tested item, which can help traceability, reproducibility and accountability.
Proper configuration management ensures that testers have access to consistent versions of software components and testware, which can help reliability, compatibility and efficiency. Proper configuration management ensures that testers can track changes and defects in software components and testware, which can help verification, validation and reporting.
Proper configuration management ensures that testers can control the configuration of the test environment, which can help stability, security and performance. Configuration management is not a prerequisite for test planning, as test planning can proceed without configuration management, although it may be less effective or accurate. Configuration management is not important for developers only, but for testers as well, as it affects the quality and consistency of the testing process and products. Configuration management has a significant influence on the test project, as it affects various aspects of testing, such as traceability, reproducibility, reliability, compatibility, efficiency, verification, validation, reporting, stability, security and performance.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 6, page 60-61.
B
Explanation:
Configuration management is a process that establishes and maintains consistency among work products throughout their life cycle.
Configuration management affects testing in various ways, such as:
Proper configuration management ensures that testers can uniquely identify the tested item, which can help traceability, reproducibility and accountability.
Proper configuration management ensures that testers have access to consistent versions of software components and testware, which can help reliability, compatibility and efficiency. Proper configuration management ensures that testers can track changes and defects in software components and testware, which can help verification, validation and reporting.
Proper configuration management ensures that testers can control the configuration of the test environment, which can help stability, security and performance. Configuration management is not a prerequisite for test planning, as test planning can proceed without configuration management, although it may be less effective or accurate. Configuration management is not important for developers only, but for testers as well, as it affects the quality and consistency of the testing process and products. Configuration management has a significant influence on the test project, as it affects various aspects of testing, such as traceability, reproducibility, reliability, compatibility, efficiency, verification, validation, reporting, stability, security and performance.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 6, page 60-61.
Question #25
During system testing phase of a word processor, a tester finds that on opening a file from a particular set of files, which are part of a critical workflow, the word processor crashes.
Which of the following is the next step the tester should take poor to recording the deviation?
- A . Try to recreate the incident before reporting
- B . Try to identify the code fragment causing the problem
- C . Send an email to the developer and not report the bug
- D . Report the incident as is without any further action
Correct Answer: A
A
Explanation:
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 Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 3, page 32-33.
A
Explanation:
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 Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 3, page 32-33.
Question #26
Which of the following statements about decision tables are TRUE?
I) Generally, decision tables are generated for low risk test items.
II) Test cases derived from decision tables can be used for component tests.
III) Several test cases can be selected for each column of the decision table.
IV) The conditions in the decision table represent negative tests generally.
- A . I, Ill
- B . I, IV
- C . II, IV
- D . II, Ill
Correct Answer: D
D
Explanation:
A decision table is a technique that shows combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects). A decision table consists of four quadrants: conditions (inputs), actions (outputs), condition entries (values) and action entries (results).
The following statements about decision tables are true:
II, Test cases derived from decision tables can be used for component tests. Decision tables can be used to test components that have multiple inputs and outputs that depend on logical combinations of conditions. Decision tables can help cover all possible combinations or scenarios in a systematic way.
III, Several test cases can be selected for each column of the decision table. A column of a decision table represents a unique combination of condition entries and action entries. Several test cases can be selected for each column by varying other input values or expected results that are not part of the decision table. The following statements about decision tables are false:
I, Generally, decision tables are generated for low risk test items. Decision tables are not related to risk level, but rather to complexity level. Decision tables are generated for test items that have complex logic or multiple conditions and actions that need to be tested.
IV, The conditions in the decision table represent negative tests generally. The conditions in the decision table represent both positive and negative tests, depending on whether they are valid or invalid inputs for the test item.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 4, page 42-43.
D
Explanation:
A decision table is a technique that shows combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects). A decision table consists of four quadrants: conditions (inputs), actions (outputs), condition entries (values) and action entries (results).
The following statements about decision tables are true:
II, Test cases derived from decision tables can be used for component tests. Decision tables can be used to test components that have multiple inputs and outputs that depend on logical combinations of conditions. Decision tables can help cover all possible combinations or scenarios in a systematic way.
III, Several test cases can be selected for each column of the decision table. A column of a decision table represents a unique combination of condition entries and action entries. Several test cases can be selected for each column by varying other input values or expected results that are not part of the decision table. The following statements about decision tables are false:
I, Generally, decision tables are generated for low risk test items. Decision tables are not related to risk level, but rather to complexity level. Decision tables are generated for test items that have complex logic or multiple conditions and actions that need to be tested.
IV, The conditions in the decision table represent negative tests generally. The conditions in the decision table represent both positive and negative tests, depending on whether they are valid or invalid inputs for the test item.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 4, page 42-43.
Question #27
Consider the following statements about risk-based testing.
I) Risk-based testing has the objective to reduce the level of protect risks.
II) Tests should be prioritized to find tie critical detects as early as possible.
III) Non-testing activities may also help to reduce risk
IV) Risks have to be reassessed on a regular basis.
V) The project stakeholders can give useful input to determine the risks
- A . I III IV and V are true. II is false.
- B . II, III IV and V are correct. I is false.
- C . I, II and IV are true. III and V are false.
- D . II, Ill and V are true. 1 ants Iv are false.
Correct Answer: B
B
Explanation:
The following statements about risk-based testing are correct:
II) Tests should be prioritized to find tie critical detects as early as possible. Risk-based testing involves prioritizing tests based on risk level, which reflects both the likelihood and impact of defects or failures. Tests with higher risk level should be executed earlier than tests with lower risk level, in order to find and fix critical defects as soon as possible.
III) Non-testing activities may also help to reduce risk. Risk-based testing does not only involve testing activities, but also other activities that can help mitigate risks, such as reviews, inspections, audits, simulations or prototyping.
B
Explanation:
The following statements about risk-based testing are correct:
II) Tests should be prioritized to find tie critical detects as early as possible. Risk-based testing involves prioritizing tests based on risk level, which reflects both the likelihood and impact of defects or failures. Tests with higher risk level should be executed earlier than tests with lower risk level, in order to find and fix critical defects as soon as possible.
III) Non-testing activities may also help to reduce risk. Risk-based testing does not only involve testing activities, but also other activities that can help mitigate risks, such as reviews, inspections, audits, simulations or prototyping.
Question #28
As the last stage of a test cycle of an embedded device, you are performing exploratory testing. You observed that some character. (A, X and Z) sent via a serial port to the device do not get registered on the device whereas they should be. You suspect that this could be due to a wrong configuration of the "bit parity" parameter.
Which of the following items of an incident report would you be UNABLE to write down based on this information?
- A . Expected result
- B . Test case identifier
- C . Test setup details
- D . Actual result
Correct Answer: B
B
Explanation:
An incident report is a document that records the details of an incident.
An incident report typically contains the following items:
Identifier: A unique identifier for the incident report
Summary: A concise summary of the incident
Description: A detailed description of the incident, including the steps to reproduce it, the expected and actual results, and any relevant screenshots or logs
Severity: The degree of impact that the incident has on the system
Priority: The level of urgency for resolving the incident
Status: The current state of the incident, such as new, open, resolved, closed, etc.
Resolution: The action taken to resolve the incident, such as fix, workaround, reject, etc. Based on the information given in the question, the tester would be able to write down all of these items except for the test case identifier. A test case identifier is a unique identifier for a test case that is used to link it to other test artifacts, such as test plans, test scripts, test results or incident reports. However, since the tester is performing exploratory testing, there is no predefined test case that can be associated with the incident. 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 does not use formal test cases or scripts, but rather uses test charters or missions that guide the tester’s actions and objectives.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 3, page 32-33; Chapter 5, page 47-48.
B
Explanation:
An incident report is a document that records the details of an incident.
An incident report typically contains the following items:
Identifier: A unique identifier for the incident report
Summary: A concise summary of the incident
Description: A detailed description of the incident, including the steps to reproduce it, the expected and actual results, and any relevant screenshots or logs
Severity: The degree of impact that the incident has on the system
Priority: The level of urgency for resolving the incident
Status: The current state of the incident, such as new, open, resolved, closed, etc.
Resolution: The action taken to resolve the incident, such as fix, workaround, reject, etc. Based on the information given in the question, the tester would be able to write down all of these items except for the test case identifier. A test case identifier is a unique identifier for a test case that is used to link it to other test artifacts, such as test plans, test scripts, test results or incident reports. However, since the tester is performing exploratory testing, there is no predefined test case that can be associated with the incident. 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 does not use formal test cases or scripts, but rather uses test charters or missions that guide the tester’s actions and objectives.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 3, page 32-33; Chapter 5, page 47-48.
Question #29
Which of the following statements about re-testing and regression testing are TRUE?
I, Re-testing should be performed after a defect is fixed.
II, Regression testing should always be performed after a defect is fixed.
III, Re-testing and regression testing may be performed at any test level.
IV, Regression testing may include functional, non-functional and structural testing.
V, Re-testing should be included in the debugging activity.
- A . I, III, Iv
- B . II, v
- C . I, Ill
- D . II, IV, V
Correct Answer: A
A
Explanation:
The following statements about re-testing and regression testing are true:
I) Re-testing should be performed after a defect is fixed. Re-testing is a type of testing that verifies that a defect has been successfully resolved by executing a test case that previously failed due to that defect. Re-testing should be performed after a defect is fixed and delivered to ensure that it does not cause any new failures or side effects.
III) Re-testing and regression testing may be performed at any test level. Re-testing and regression testing are not limited to a specific test level, but can be applied at any level depending on the context and objectives. For example, re-testing and regression testing can be performed at unit level, integration level, system level or acceptance level.
IV) Regression testing may include functional, non-functional and structural testing. Regression testing is a type of testing that verifies that previously tested software still performs correctly after changes. Regression testing may include various types of testing depending on the scope and purpose of the changes. For example, regression testing may include functional testing to check if the software meets its requirements, non-functional testing to check if the software meets its quality
attributes, or structural testing to check if the software meets its design or code standards. The following statement about re-testing and regression testing is false:
II) Regression testing should always be performed after a defect is fixed. Regression testing is not always necessary after a defect is fixed, as some defects may have a low impact or low likelihood of affecting other parts of the software. Regression testing should be performed after a defect is fixed only if there is a risk of introducing new defects or causing existing defects due to the changes made to fix the defect.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 2, page 19; Chapter 4, page 45.
A
Explanation:
The following statements about re-testing and regression testing are true:
I) Re-testing should be performed after a defect is fixed. Re-testing is a type of testing that verifies that a defect has been successfully resolved by executing a test case that previously failed due to that defect. Re-testing should be performed after a defect is fixed and delivered to ensure that it does not cause any new failures or side effects.
III) Re-testing and regression testing may be performed at any test level. Re-testing and regression testing are not limited to a specific test level, but can be applied at any level depending on the context and objectives. For example, re-testing and regression testing can be performed at unit level, integration level, system level or acceptance level.
IV) Regression testing may include functional, non-functional and structural testing. Regression testing is a type of testing that verifies that previously tested software still performs correctly after changes. Regression testing may include various types of testing depending on the scope and purpose of the changes. For example, regression testing may include functional testing to check if the software meets its requirements, non-functional testing to check if the software meets its quality
attributes, or structural testing to check if the software meets its design or code standards. The following statement about re-testing and regression testing is false:
II) Regression testing should always be performed after a defect is fixed. Regression testing is not always necessary after a defect is fixed, as some defects may have a low impact or low likelihood of affecting other parts of the software. Regression testing should be performed after a defect is fixed only if there is a risk of introducing new defects or causing existing defects due to the changes made to fix the defect.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 2, page 19; Chapter 4, page 45.
Question #30
Which of the following can be considered a VALID exit criterion?
I Estimates of defect density or reliability measures.
II, The completion and publication of an exhaustive Test Report.
III, Accuracy measures, such as code, functionality or risk coverage.
IV Residual risks such as lack of code coverage in certain areas.
- A . I, III, IV
- B . I, II, III
- C . III, IV
- D . II, III, IV
Correct Answer: A
A
Explanation:
An exit criterion is a condition that defines when a test activity has been completed or when a test phase can be concluded.
An exit criterion can be based on various factors, such as:
I) Estimates of defect density or reliability measures. These are quantitative measures that indicate how many defects are present in the software product or how likely it is to fail under certain conditions. These can be used as exit criteria to ensure that the software product meets a certain level of quality or performance before moving to the next phase or releasing it to the customer.
III) Accuracy measures, such as code coverage, functionality coverage or risk coverage. These are quantitative measures that indicate how much of the software product has been tested in terms of its code, functionality or risk. These can be used as exit criteria to ensure that the test suite is adequate or complete before moving to the next phase or releasing it to the customer.
IV) Residual risks, such as lack of code coverage in certain areas, unresolved defects or unknown factors. These are qualitative measures that indicate the remaining risks or uncertainties associated with the software product after testing. These can be used as exit criteria to ensure that the residual risks are acceptable or manageable before moving to the next phase or releasing it to the customer. The following factor is not a valid exit criterion:
II) The completion and publication of an exhaustive Test Report. This is not a valid exit criterion, as it does not reflect the quality or completeness of the testing process or product. A test report is a document that summarizes the results and outcomes of a test activity or phase. A test report can be used as an input for deciding whether to exit a test activity or phase, but it is not a condition that defines when to exit.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 2, page 13; Chapter 6, page 58-59.
A
Explanation:
An exit criterion is a condition that defines when a test activity has been completed or when a test phase can be concluded.
An exit criterion can be based on various factors, such as:
I) Estimates of defect density or reliability measures. These are quantitative measures that indicate how many defects are present in the software product or how likely it is to fail under certain conditions. These can be used as exit criteria to ensure that the software product meets a certain level of quality or performance before moving to the next phase or releasing it to the customer.
III) Accuracy measures, such as code coverage, functionality coverage or risk coverage. These are quantitative measures that indicate how much of the software product has been tested in terms of its code, functionality or risk. These can be used as exit criteria to ensure that the test suite is adequate or complete before moving to the next phase or releasing it to the customer.
IV) Residual risks, such as lack of code coverage in certain areas, unresolved defects or unknown factors. These are qualitative measures that indicate the remaining risks or uncertainties associated with the software product after testing. These can be used as exit criteria to ensure that the residual risks are acceptable or manageable before moving to the next phase or releasing it to the customer. The following factor is not a valid exit criterion:
II) The completion and publication of an exhaustive Test Report. This is not a valid exit criterion, as it does not reflect the quality or completeness of the testing process or product. A test report is a document that summarizes the results and outcomes of a test activity or phase. A test report can be used as an input for deciding whether to exit a test activity or phase, but it is not a condition that defines when to exit.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 2, page 13; Chapter 6, page 58-59.
Question #31
Which of the following statements about testware are correct?
I When closing the test activities, all the testware resources can be uninstalled and released
II All the testware should be subject to Configuration Management
III, The testware. at the end of the project, should be transferred to the organization responsible for maintenance
IV The developers are responsible for the correct installation of the testware
- A . II, Ill
- B . I, Ill
- C . I, IV
- D . II, IV
Correct Answer: A
A
Explanation:
Testware is a term that refers to all artifacts produced during the testing process, such as test plans, test cases, test scripts, test data, test results, defect reports, etc.
The following statements about testware are correct:
II) All the testware should be subject to Configuration Management. Configuration management is a process that establishes and maintains consistency among work products throughout their life cycle. Configuration management applies to all testware, as it helps ensure their quality and consistency, track their changes and defects, control their versions and access rights, and link them to other artifacts.
III) The testware at the end of the project should be transferred to the organization responsible for maintenance. Maintenance testing is testing performed on a software product after delivery to correct defects or improve performance or other attributes. Maintenance testing requires testware from previous testing activities or phases, such as test cases, test data, test results, etc. Therefore, the testware at the end of the project should be transferred to the organization responsible for maintenance testing, such as support team or maintenance team. The following statements about testware are incorrect:
I) When closing the test activities, all the testware resources can be uninstalled and released. This statement is incorrect, as some testware resources may still be needed for future testing activities or phases, such as maintenance testing or regression testing. Therefore, when closing the test activities, some testware resources should be archived and stored for future use, while others can be uninstalled and released.
IV) The developers are responsible for the correct installation of the testware. This statement is incorrect, as the testers are responsible for the correct installation of the testware. The testers should ensure that they have access to all necessary testware resources and that they are installed and configured properly before starting the test execution.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 6, page 58-61.
A
Explanation:
Testware is a term that refers to all artifacts produced during the testing process, such as test plans, test cases, test scripts, test data, test results, defect reports, etc.
The following statements about testware are correct:
II) All the testware should be subject to Configuration Management. Configuration management is a process that establishes and maintains consistency among work products throughout their life cycle. Configuration management applies to all testware, as it helps ensure their quality and consistency, track their changes and defects, control their versions and access rights, and link them to other artifacts.
III) The testware at the end of the project should be transferred to the organization responsible for maintenance. Maintenance testing is testing performed on a software product after delivery to correct defects or improve performance or other attributes. Maintenance testing requires testware from previous testing activities or phases, such as test cases, test data, test results, etc. Therefore, the testware at the end of the project should be transferred to the organization responsible for maintenance testing, such as support team or maintenance team. The following statements about testware are incorrect:
I) When closing the test activities, all the testware resources can be uninstalled and released. This statement is incorrect, as some testware resources may still be needed for future testing activities or phases, such as maintenance testing or regression testing. Therefore, when closing the test activities, some testware resources should be archived and stored for future use, while others can be uninstalled and released.
IV) The developers are responsible for the correct installation of the testware. This statement is incorrect, as the testers are responsible for the correct installation of the testware. The testers should ensure that they have access to all necessary testware resources and that they are installed and configured properly before starting the test execution.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 6, page 58-61.
Question #32
A QA manager of a start-up company needs to implement within a week a low cost incident management tool.
Which of the following is the best option?
- A . Document incidents on a large board in the lab
- B . Purchase and deploy an incident management tool
- C . Manage the incidents through E-mails and phone calls
- D . Manage the incidents in a spreadsheet posted on the intranet
Correct Answer: D
D
Explanation:
An incident is any event that occurs during testing that requires investigation. An incident management tool is a software tool that supports recording and tracking incidents throughout their life cycle. A QA manager of a start-up company needs to implement within a week a low cost incident management tool. The best option for this case is to manage the incidents in a spreadsheet posted on the intranet. This option has several advantages over other options:
It is low cost, as it does not require purchasing any additional software or hardware.
It is easy to implement within a week, as it does not require installing or configuring any complex software or hardware.
It is accessible and transparent, as it can be viewed and updated by anyone who has access to the intranet.
It is structured and organized, as it can store and display various information about incidents, such as identifier, summary, description, severity, priority, status, resolution, etc.
The other options are not suitable for this case, as they have several disadvantages over the chosen option:
Documenting incidents on a large board in the lab is not a good option, as it is not accessible or transparent to anyone who is not physically present in the lab. It is also not structured or organized, as it may not store or display all the necessary information about incidents.
Purchasing and deploying an incident management tool is not a good option, as it is not low cost or easy to implement within a week. It may require spending a significant amount of money and time on acquiring, installing and configuring the software or hardware.
Managing the incidents through emails and phone calls is not a good option, as it is not structured or organized. It may lead to confusion, inconsistency or loss of information about incidents.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 3, page 32-33.
D
Explanation:
An incident is any event that occurs during testing that requires investigation. An incident management tool is a software tool that supports recording and tracking incidents throughout their life cycle. A QA manager of a start-up company needs to implement within a week a low cost incident management tool. The best option for this case is to manage the incidents in a spreadsheet posted on the intranet. This option has several advantages over other options:
It is low cost, as it does not require purchasing any additional software or hardware.
It is easy to implement within a week, as it does not require installing or configuring any complex software or hardware.
It is accessible and transparent, as it can be viewed and updated by anyone who has access to the intranet.
It is structured and organized, as it can store and display various information about incidents, such as identifier, summary, description, severity, priority, status, resolution, etc.
The other options are not suitable for this case, as they have several disadvantages over the chosen option:
Documenting incidents on a large board in the lab is not a good option, as it is not accessible or transparent to anyone who is not physically present in the lab. It is also not structured or organized, as it may not store or display all the necessary information about incidents.
Purchasing and deploying an incident management tool is not a good option, as it is not low cost or easy to implement within a week. It may require spending a significant amount of money and time on acquiring, installing and configuring the software or hardware.
Managing the incidents through emails and phone calls is not a good option, as it is not structured or organized. It may lead to confusion, inconsistency or loss of information about incidents.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 3, page 32-33.
Question #33
Which of the following statements regarding inspection is NOT true?
- A . An inspection may be led by a trained moderator who shall not be the author.
- B . The main purpose of an inspection is to find solutions to the problems.
- C . An inspection can be performed by peers.
- D . An inspection shall follow a formal process based on rules and checklists with entry and exit criteria
Correct Answer: B
B
Explanation:
An inspection is a type of review that follows a defined process with formal entry and exit criteria and roles and responsibilities for participants. An inspection can be performed by peers with different roles, such as moderator, author, reviewer and scribe.
The following statement about inspection is not true:
B) The main purpose of an inspection is to find solutions to the problems. This statement is not true, as the main purpose of an inspection is to find defects or issues in a work product, not to find solutions to the problems. Finding solutions to the problems is a debugging or problem-solving activity that is usually performed by the author or developer after receiving the inspection report.
The following statements about inspection are true:
A) An inspection may be led by a trained moderator who shall not be the author. This statement is true, as an inspection requires a moderator role who leads the inspection process and ensures that it follows the rules and standards. The moderator should be trained in inspection techniques and should not be the author of the work product under inspection, in order to avoid bias or conflict of interest.
C) An inspection can be performed by peers. This statement is true, as an inspection involves peer review, which means that the work product under inspection is evaluated by people who have similar roles or expertise as the author, but who are not directly involved in creating or modifying the work product.
D) An inspection shall follow a formal process based on rules and checklists with entry and exit criteria. This statement is true, as an inspection follows a formal process that consists of six main steps: planning, kick-off meeting, individual preparation, review meeting, rework and follow-up. Each step has defined rules and checklists to guide the participants and ensure consistency and quality. Each step also has entry and exit criteria to ensure that the prerequisites and objectives are met before moving to the next step.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 3, page 28-29.
B
Explanation:
An inspection is a type of review that follows a defined process with formal entry and exit criteria and roles and responsibilities for participants. An inspection can be performed by peers with different roles, such as moderator, author, reviewer and scribe.
The following statement about inspection is not true:
B) The main purpose of an inspection is to find solutions to the problems. This statement is not true, as the main purpose of an inspection is to find defects or issues in a work product, not to find solutions to the problems. Finding solutions to the problems is a debugging or problem-solving activity that is usually performed by the author or developer after receiving the inspection report.
The following statements about inspection are true:
A) An inspection may be led by a trained moderator who shall not be the author. This statement is true, as an inspection requires a moderator role who leads the inspection process and ensures that it follows the rules and standards. The moderator should be trained in inspection techniques and should not be the author of the work product under inspection, in order to avoid bias or conflict of interest.
C) An inspection can be performed by peers. This statement is true, as an inspection involves peer review, which means that the work product under inspection is evaluated by people who have similar roles or expertise as the author, but who are not directly involved in creating or modifying the work product.
D) An inspection shall follow a formal process based on rules and checklists with entry and exit criteria. This statement is true, as an inspection follows a formal process that consists of six main steps: planning, kick-off meeting, individual preparation, review meeting, rework and follow-up. Each step has defined rules and checklists to guide the participants and ensure consistency and quality. Each step also has entry and exit criteria to ensure that the prerequisites and objectives are met before moving to the next step.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, Chapter 3, page 28-29.
Question #34
Which of the following options cover the test types performed during typical system testing phase:
I) Usability
II) Requirements based scenarios
III) Testing parts of the code in isolation
IV) Correct order of parameters in API calls
- A . I, Ill
- B . I, II
- C . II, IV
- D . III, IV
Correct Answer: B
B
Explanation:
System testing is a level of testing performed to evaluate the behavior and quality of a whole software product or system.
System testing can include various types of testing, such as:
I) Usability testing: A type of testing that evaluates how easy, efficient and satisfying it is to use the software product or system from the user’s perspective.
II) Requirements based scenarios testing: A type of testing that verifies that the software product or
system meets its specified requirements or user stories by executing realistic scenarios or workflows. System testing does not include the following types of testing, as they are more suitable for lower levels of testing, such as unit testing or integration testing:
III) Testing parts of the code in isolation: A type of testing that verifies the functionality and quality of individual software components or units by isolating them from other components or units.
IV) Correct order of parameters in API calls: A type of testing that verifies the functionality and quality of software components or units that communicate with each other through application programming interfaces (APIs) by checking the correct order and format of parameters in API calls.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 2, page 20-21; Chapter 4, page 34-35.
B
Explanation:
System testing is a level of testing performed to evaluate the behavior and quality of a whole software product or system.
System testing can include various types of testing, such as:
I) Usability testing: A type of testing that evaluates how easy, efficient and satisfying it is to use the software product or system from the user’s perspective.
II) Requirements based scenarios testing: A type of testing that verifies that the software product or
system meets its specified requirements or user stories by executing realistic scenarios or workflows. System testing does not include the following types of testing, as they are more suitable for lower levels of testing, such as unit testing or integration testing:
III) Testing parts of the code in isolation: A type of testing that verifies the functionality and quality of individual software components or units by isolating them from other components or units.
IV) Correct order of parameters in API calls: A type of testing that verifies the functionality and quality of software components or units that communicate with each other through application programming interfaces (APIs) by checking the correct order and format of parameters in API calls.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 2, page 20-21; Chapter 4, page 34-35.
Question #35
A mid-size software product development company has analyzed data related to defects detected in its product and found out that detects fixed in earlier builds are getting re-opened after a few months.
The company management now seeks your advice in order to reverse this trend and prevent re-opening of defects fixed earlier.
What would be your FIRST recommendation to the company?
- A . Automate existing test suits so that lesser time is spent on execution of each test, and more tests can be executed m the available time thus leading to a lower probability of defects slipping by
- B . Verify existing regression test suite are adequate, and augment it, if required, in order to ensure that defects fixed earlier get re-tested in each subsequent build
- C . Analyze the product modules containing maximum defects, and get them thoroughly tested and defects fixed as a one-time activity
- D . If required, tram the teams responsible for development and testing of the modules containing maximum number of defects, and if this does not help, replace them with more knowledgeable people
Correct Answer: B
B
Explanation:
Regression testing is a type of testing that verifies that previously tested software still performs correctly after changes. Regression testing can help prevent re-opening of defects fixed earlier by ensuring that they do not cause any new failures or side effects. The first recommendation to the company is to verify existing regression test suite are adequate, and augment it, if required, in order to ensure that defects fixed earlier get re-tested in each subsequent build. This can help improve the coverage and effectiveness of regression testing and detect any regression defects as soon as possible. Automating existing test suites may also help reduce the time and effort required for regression testing, but this is not the first recommendation, as automation may not be feasible or cost-effective for all test cases. Analyzing the product modules containing maximum defects and getting them thoroughly tested and defects fixed as a one-time activity may also help reduce the defect density and improve the quality of those modules, but this is not the first recommendation, as it does not address the root cause of re-opening defects fixed earlier. Training or replacing the teams responsible for development and testing of the modules containing maximum number of defects may also help improve their skills or performance, but this is not the first recommendation, as it may not be necessary or appropriate for all teams.
Verified Reference: [A Study Guide to the ISTQB®
Foundation Level 2018 Syllabus – Springer], Chapter 2, page 19; Chapter 4, page 45.
B
Explanation:
Regression testing is a type of testing that verifies that previously tested software still performs correctly after changes. Regression testing can help prevent re-opening of defects fixed earlier by ensuring that they do not cause any new failures or side effects. The first recommendation to the company is to verify existing regression test suite are adequate, and augment it, if required, in order to ensure that defects fixed earlier get re-tested in each subsequent build. This can help improve the coverage and effectiveness of regression testing and detect any regression defects as soon as possible. Automating existing test suites may also help reduce the time and effort required for regression testing, but this is not the first recommendation, as automation may not be feasible or cost-effective for all test cases. Analyzing the product modules containing maximum defects and getting them thoroughly tested and defects fixed as a one-time activity may also help reduce the defect density and improve the quality of those modules, but this is not the first recommendation, as it does not address the root cause of re-opening defects fixed earlier. Training or replacing the teams responsible for development and testing of the modules containing maximum number of defects may also help improve their skills or performance, but this is not the first recommendation, as it may not be necessary or appropriate for all teams.
Verified Reference: [A Study Guide to the ISTQB®
Foundation Level 2018 Syllabus – Springer], Chapter 2, page 19; Chapter 4, page 45.
Question #36
Which of the following does MOT describe a reason why testing is necessary?
- A . The customer decided that 100% branch coverage shall be achieved
- B . The acquisition of test automation tools was based on the assumption that it will be used m all projects
- C . For avionics and pharmaceutical systems software testing is mandated by standards
- D . The risks associated with delivering the system are far higher than the cost of testing
Correct Answer: B
B
Explanation:
Testing is necessary for various reasons, such as:
To detect defects and failures that may affect the quality, performance, reliability or security of a software product or system
To verify that a software product or system meets its specified requirements, expectations and standards
To validate that a software product or system fulfills its intended purpose and satisfies its stakeholders’ needs
To provide information and feedback about the status and risks of a software product or system
To comply with regulations or contractual obligations that mandate testing for certain types of software products or systems The following statements describe some reasons why testing is necessary:
A) The customer decided that 100% branch coverage shall be achieved. This is a reason why testing is necessary, as it reflects a contractual obligation or a quality standard that requires testing to measure and achieve a certain level of code coverage.
C) For avionics and pharmaceutical systems software testing is mandated by standards. This is a reason why testing is necessary, as it reflects a regulation or a compliance requirement that mandates testing for certain types of software products or systems that have high safety or security risks.
D) The risks associated with delivering the system are far higher than the cost of testing. This is a reason why testing is necessary, as it reflects a risk-based approach that considers testing as an investment to reduce the probability and impact of potential failures or defects.
The following statement does not describe a reason why testing is necessary:
B) The acquisition of test automation tools was based on the assumption that it will be used m all projects. This is not a reason why testing is necessary, as it reflects a business decision or a resource allocation that does not justify the need or purpose of testing. Test automation tools are not always suitable or beneficial for all projects, and testing can be performed with or without test automation tools.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 1, page 5-6.
B
Explanation:
Testing is necessary for various reasons, such as:
To detect defects and failures that may affect the quality, performance, reliability or security of a software product or system
To verify that a software product or system meets its specified requirements, expectations and standards
To validate that a software product or system fulfills its intended purpose and satisfies its stakeholders’ needs
To provide information and feedback about the status and risks of a software product or system
To comply with regulations or contractual obligations that mandate testing for certain types of software products or systems The following statements describe some reasons why testing is necessary:
A) The customer decided that 100% branch coverage shall be achieved. This is a reason why testing is necessary, as it reflects a contractual obligation or a quality standard that requires testing to measure and achieve a certain level of code coverage.
C) For avionics and pharmaceutical systems software testing is mandated by standards. This is a reason why testing is necessary, as it reflects a regulation or a compliance requirement that mandates testing for certain types of software products or systems that have high safety or security risks.
D) The risks associated with delivering the system are far higher than the cost of testing. This is a reason why testing is necessary, as it reflects a risk-based approach that considers testing as an investment to reduce the probability and impact of potential failures or defects.
The following statement does not describe a reason why testing is necessary:
B) The acquisition of test automation tools was based on the assumption that it will be used m all projects. This is not a reason why testing is necessary, as it reflects a business decision or a resource allocation that does not justify the need or purpose of testing. Test automation tools are not always suitable or beneficial for all projects, and testing can be performed with or without test automation tools.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 1, page 5-6.
Question #37
Which of the following statements is CORRECT?
- A . Test cases are made up of input values, expected results and actual results developed to cover test objectives
- B . Test cases describe items or events to test that are derived from the test basis during the test analysis activity
- C . Test cases are sequences of actions for test execution specified during the test implementation activity
- D . Test cases are derived during the test design activity to cover test objectives or test conditions
Correct Answer: C
C
Explanation:
A test case is a set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition. A test case is a sequence of actions for test execution that can be followed by a tester or a test automation tool. A test case is specified during the test implementation activity, which is the activity that prepares the testware needed for test execution. A test case does not include actual results, as these are obtained during test execution and compared with the expected results. A test case does not describe items or events to test, as these are derived from the test basis during the test analysis activity. A test case is not derived during the test design activity, as this is the activity that specifies the test conditions or objectives that need to be tested.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 3, page 23-24; Chapter 4, page 34.
C
Explanation:
A test case is a set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition. A test case is a sequence of actions for test execution that can be followed by a tester or a test automation tool. A test case is specified during the test implementation activity, which is the activity that prepares the testware needed for test execution. A test case does not include actual results, as these are obtained during test execution and compared with the expected results. A test case does not describe items or events to test, as these are derived from the test basis during the test analysis activity. A test case is not derived during the test design activity, as this is the activity that specifies the test conditions or objectives that need to be tested.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 3, page 23-24; Chapter 4, page 34.
Question #38
Given the following requirement:
Requirement ID: 2 8
Requirement Description Additional Entrance Fee
Detailed Description
An additional fee of S3 is charged during the weekend, but
1) Visitors aged under 7 are not charged.
2) Visitors aged 7 to 13 inclusive get a 20% discount off the additional fee.
3) Visitors aged greater than 65 get a 50% discount off the additional fee.
Age should be an integer of 0 or above.
Weekend means Friday to Sunday inclusive.
Which of the following statements is NOT correct?
- A . Thursday is a valid input boundary value.
- B . A minimum of 6 valid test cases are derived from boundary value analysis based on input age.
- C . $3.01 is a valid output boundary value.
- D . 7 and 13 are boundary values for the equivalence partition including age 10.
Correct Answer: A
A
Explanation:
Boundary value analysis is a technique that tests boundary values between partitions of equivalent data. Boundary values are values at the edge of an equivalence partition or at the smallest incremental distance on either side of an edge. Boundary value analysis can be applied to both input and output values. Based on the given requirement, we can identify two input values: age and weekend. Age should be an integer of 0 or above, and weekend means Friday to Sunday inclusive. The following statement is not correct:
A) Thursday is a valid input boundary value. This statement is not correct, as Thursday is not a boundary value for the input weekend. The boundary values for the input weekend are Friday and Sunday, as they are at the edge of the equivalence partition that represents weekend days. The following statements are correct:
B) A minimum of 6 valid test cases are derived from boundary value analysis based on input age. This statement is correct, as we can derive six valid test cases based on input age by using the minimum and maximum values for each equivalence partition defined by the requirement. The equivalence partitions for input age are: under 7 (0 to 6), 7 to 13 inclusive (7 to 13), and greater than 65 (66 and above). The minimum and maximum values for each partition are: 0 and 6, 7 and 13, and 66 and any value above it.
C) $3.01 is a valid output boundary value. This statement is correct, as $3.01 is a boundary value for the output additional fee. The additional fee can have four possible values depending on the input age: $0 (for visitors aged under 7), $2.40 (for visitors aged 7 to 13 inclusive with a 20% discount), $1.50 (for visitors aged greater than 65 with a 50% discount), and $3 (for visitors aged between 14 and 65). The boundary values for the output additional fee are $0 and $3, as they are at the edge of an equivalence partition or at the smallest incremental distance on either side of an edge. Therefore, $3.01 is a valid output boundary value, as it is at the smallest incremental distance above $3.
D) 7 and 13 are boundary values for the equivalence partition including age 10. This statement is correct, as 7 and 13 are boundary values for the equivalence partition that represents visitors aged 7 to 13 inclusive. This partition includes age 10, which is an internal value within the partition.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 4, page 37-38.
A
Explanation:
Boundary value analysis is a technique that tests boundary values between partitions of equivalent data. Boundary values are values at the edge of an equivalence partition or at the smallest incremental distance on either side of an edge. Boundary value analysis can be applied to both input and output values. Based on the given requirement, we can identify two input values: age and weekend. Age should be an integer of 0 or above, and weekend means Friday to Sunday inclusive. The following statement is not correct:
A) Thursday is a valid input boundary value. This statement is not correct, as Thursday is not a boundary value for the input weekend. The boundary values for the input weekend are Friday and Sunday, as they are at the edge of the equivalence partition that represents weekend days. The following statements are correct:
B) A minimum of 6 valid test cases are derived from boundary value analysis based on input age. This statement is correct, as we can derive six valid test cases based on input age by using the minimum and maximum values for each equivalence partition defined by the requirement. The equivalence partitions for input age are: under 7 (0 to 6), 7 to 13 inclusive (7 to 13), and greater than 65 (66 and above). The minimum and maximum values for each partition are: 0 and 6, 7 and 13, and 66 and any value above it.
C) $3.01 is a valid output boundary value. This statement is correct, as $3.01 is a boundary value for the output additional fee. The additional fee can have four possible values depending on the input age: $0 (for visitors aged under 7), $2.40 (for visitors aged 7 to 13 inclusive with a 20% discount), $1.50 (for visitors aged greater than 65 with a 50% discount), and $3 (for visitors aged between 14 and 65). The boundary values for the output additional fee are $0 and $3, as they are at the edge of an equivalence partition or at the smallest incremental distance on either side of an edge. Therefore, $3.01 is a valid output boundary value, as it is at the smallest incremental distance above $3.
D) 7 and 13 are boundary values for the equivalence partition including age 10. This statement is correct, as 7 and 13 are boundary values for the equivalence partition that represents visitors aged 7 to 13 inclusive. This partition includes age 10, which is an internal value within the partition.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 4, page 37-38.
Question #39
Out of the following. what is not needed to specify in defect report?
- A . Test environment details
- B . How to reproduce the defect
- C . How to fix the defect
- D . Seventy and priority
Correct Answer: C
C
Explanation:
A defect report is a document that records the details of a defect found during testing.
A defect report typically contains the following items:
Identifier: A unique identifier for the defect report
Summary: A concise summary of the defect
Description: A detailed description of the defect, including the steps to reproduce it, the expected and actual results, and any relevant screenshots or logs Severity: The degree of impact that the defect has on the system
Priority: The level of urgency for resolving the defect
Status: The current state of the defect, such as new, open, resolved, closed, etc.
Resolution: The action taken to resolve the defect, such as fix, workaround, reject, etc. Out of these items, the one that is not needed to specify in a defect report is how to fix the defect.
How to fix the defect is a technical solution that is usually determined by the developer who is assigned to resolve the defect.
How to fix the defect is not part of the defect report, but rather part of the code change or patch that is delivered to fix the defect. The other items are needed to specify in a defect report, as they provide essential information for identifying, tracking and resolving defects.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 3, page 32-33.
C
Explanation:
A defect report is a document that records the details of a defect found during testing.
A defect report typically contains the following items:
Identifier: A unique identifier for the defect report
Summary: A concise summary of the defect
Description: A detailed description of the defect, including the steps to reproduce it, the expected and actual results, and any relevant screenshots or logs Severity: The degree of impact that the defect has on the system
Priority: The level of urgency for resolving the defect
Status: The current state of the defect, such as new, open, resolved, closed, etc.
Resolution: The action taken to resolve the defect, such as fix, workaround, reject, etc. Out of these items, the one that is not needed to specify in a defect report is how to fix the defect.
How to fix the defect is a technical solution that is usually determined by the developer who is assigned to resolve the defect.
How to fix the defect is not part of the defect report, but rather part of the code change or patch that is delivered to fix the defect. The other items are needed to specify in a defect report, as they provide essential information for identifying, tracking and resolving defects.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 3, page 32-33.
Question #40
You need to test the login page of a web site. The page contains fields for user name and password.
Which test design techniques are most appropriate for this case?
- A . Decision table testing, state transition testing.
- B . Equivalence partitioning, Boundary value analysis.
- C . Exploratory testing, statement coverage.
- D . Decision coverage, fault attack.
Correct Answer: B
B
Explanation:
Equivalence partitioning and boundary value analysis are test design techniques that are most appropriate for testing the login page of a web site. The page contains fields for user name and password, which are input values that can be divided into partitions of equivalent data. Equivalence partitioning is a technique that divides the input data and output results of a software component into partitions of equivalent data. Each partition should contain data that is treated in the same way by the component. Equivalence partitioning can be used to reduce the number of test cases by selecting one representative value from each partition. Boundary value analysis is a technique that tests boundary values between partitions of equivalent data. Boundary values are values at the edge of an equivalence partition or at the smallest incremental distance on either side of an edge. Boundary value analysis can be used to detect defects caused by incorrect handling of boundary conditions. For example, for testing the user name field, we can identify two equivalence partitions: valid user name (existing and correct) and invalid user name (non-existing or incorrect). The boundary values for these partitions are the minimum and maximum length of user name allowed by the system.
Decision table testing and state transition testing are not suitable for testing the login page of a web site, as they are more applicable for testing components that have multiple inputs and outputs that depend on logical combinations of conditions or events. Decision table testing is a technique that shows combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects). State transition testing is a technique that models how a system transitions from one state to another depending on events or conditions.
Exploratory testing and statement coverage are not suitable for testing the login page of a web site, as they are more applicable for testing components that require learning, creativity and intuition or structural analysis. 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. Statement coverage is a type of structural testing that measures how many statements in a program have been executed by a test
suite. Statement coverage can be used to assess the adequacy or completeness of a test suite. Decision coverage and fault attack are not suitable for testing the login page of a web site, as they are more applicable for testing components that have complex logic or potential errors. Decision coverage is a type of structural testing that measures how many decision outcomes in a program have been executed by a test suite. Decision coverage can be used to assess the adequacy or completeness of a test suite. Fault attack is a type of functional testing that deliberately introduces faults into a system in order to provoke failures or errors.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 4, page 34-46; Chapter 5, page 47-48.
B
Explanation:
Equivalence partitioning and boundary value analysis are test design techniques that are most appropriate for testing the login page of a web site. The page contains fields for user name and password, which are input values that can be divided into partitions of equivalent data. Equivalence partitioning is a technique that divides the input data and output results of a software component into partitions of equivalent data. Each partition should contain data that is treated in the same way by the component. Equivalence partitioning can be used to reduce the number of test cases by selecting one representative value from each partition. Boundary value analysis is a technique that tests boundary values between partitions of equivalent data. Boundary values are values at the edge of an equivalence partition or at the smallest incremental distance on either side of an edge. Boundary value analysis can be used to detect defects caused by incorrect handling of boundary conditions. For example, for testing the user name field, we can identify two equivalence partitions: valid user name (existing and correct) and invalid user name (non-existing or incorrect). The boundary values for these partitions are the minimum and maximum length of user name allowed by the system.
Decision table testing and state transition testing are not suitable for testing the login page of a web site, as they are more applicable for testing components that have multiple inputs and outputs that depend on logical combinations of conditions or events. Decision table testing is a technique that shows combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects). State transition testing is a technique that models how a system transitions from one state to another depending on events or conditions.
Exploratory testing and statement coverage are not suitable for testing the login page of a web site, as they are more applicable for testing components that require learning, creativity and intuition or structural analysis. 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. Statement coverage is a type of structural testing that measures how many statements in a program have been executed by a test
suite. Statement coverage can be used to assess the adequacy or completeness of a test suite. Decision coverage and fault attack are not suitable for testing the login page of a web site, as they are more applicable for testing components that have complex logic or potential errors. Decision coverage is a type of structural testing that measures how many decision outcomes in a program have been executed by a test suite. Decision coverage can be used to assess the adequacy or completeness of a test suite. Fault attack is a type of functional testing that deliberately introduces faults into a system in order to provoke failures or errors.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 4, page 34-46; Chapter 5, page 47-48.
Question #41
For withdrawing money tram an Automated Teller Machine (ATM), the following conditions are required:
– The bank card is valid
– The PIN code is correct
– Money is available in the user’s account
The following are some possible interactions between the user and the ATM:
– The entered card is invalid The card is rejected
– The PIN code is wrong The ATM asks for another PIN code
– The requested amount is more than available in the user’s account: The ATM asks for another amount
– The requested amount is available in the user’s account The ATM dispenses the money
Which test design technique should be used to cover all possible combinations of the in put conditions?
- A . Use case based testing
- B . Decision table
- C . Boundary value analysis
- D . Equivalence class partitioning
Correct Answer: B
B
Explanation:
A decision table is a technique that should be used to cover all possible combinations of input conditions for withdrawing money from an Automated Teller Machine (ATM). A decision table shows combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects). A decision table consists of four quadrants: conditions (inputs), actions (outputs), condition entries (values) and action entries (results). A decision table can be used to test components that have multiple inputs and outputs that depend on logical combinations of conditions. For example, for testing the ATM, we can identify three input conditions: the bank card is valid, the PIN code is correct, and money is available in the user’s account. We can also identify four output actions: the card is rejected, the ATM asks for another PIN code, the ATM asks for another amount, and the ATM dispenses the money. A decision table can show all possible combinations of these conditions and actions in a systematic way.
Use case based testing is not a technique that can cover all possible combinations of input conditions for withdrawing money from an ATM. Use case based testing is a technique that verifies that a software product or system meets its specified requirements or user stories by executing realistic scenarios or workflows. Use case based testing can be used to test components that have complex or dynamic interactions with users or other systems. For example, for testing the ATM, we can identify several use cases, such as withdraw money, check balance, transfer money, etc. Each use case can have one or more scenarios that describe the steps and outcomes of the interaction. However, use case based testing may not cover all possible combinations of input conditions, as some scenarios may be omitted or overlooked.
Boundary value analysis is not a technique that can cover all possible combinations of input conditions for withdrawing money from an ATM. Boundary value analysis is a technique that tests boundary values between partitions of equivalent data. Boundary values are values at the edge of an equivalence partition or at the smallest incremental distance on either side of an edge. Boundary value analysis can be used to test components that have input values that can be divided into partitions of equivalent data. For example, for testing the ATM, we can identify boundary values for the input amount, such as the minimum and maximum amount allowed by the system or the user’s account. However, boundary value analysis may not cover all possible combinations of input conditions, as some conditions may not have boundary values or may not be related to input values. Equivalence class partitioning is not a technique that can cover all possible combinations of input conditions for withdrawing money from an ATM. Equivalence class partitioning is a technique that divides the input data and output results of a software component into partitions of equivalent data. Each partition should contain data that is treated in the same way by the component. Equivalence class partitioning can be used to test components that have input values that can be divided into partitions of equivalent data. For example, for testing the ATM, we can identify equivalence partitions for the input amount, such as valid amount (within the range allowed by the system and the user’s account) and invalid amount (outside the range allowed by the system or the user’s account). However, equivalence class partitioning may not cover all possible combinations of input conditions, as some conditions may not be related to input values or may have more than two partitions.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 4, page 34-46.
B
Explanation:
A decision table is a technique that should be used to cover all possible combinations of input conditions for withdrawing money from an Automated Teller Machine (ATM). A decision table shows combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects). A decision table consists of four quadrants: conditions (inputs), actions (outputs), condition entries (values) and action entries (results). A decision table can be used to test components that have multiple inputs and outputs that depend on logical combinations of conditions. For example, for testing the ATM, we can identify three input conditions: the bank card is valid, the PIN code is correct, and money is available in the user’s account. We can also identify four output actions: the card is rejected, the ATM asks for another PIN code, the ATM asks for another amount, and the ATM dispenses the money. A decision table can show all possible combinations of these conditions and actions in a systematic way.
Use case based testing is not a technique that can cover all possible combinations of input conditions for withdrawing money from an ATM. Use case based testing is a technique that verifies that a software product or system meets its specified requirements or user stories by executing realistic scenarios or workflows. Use case based testing can be used to test components that have complex or dynamic interactions with users or other systems. For example, for testing the ATM, we can identify several use cases, such as withdraw money, check balance, transfer money, etc. Each use case can have one or more scenarios that describe the steps and outcomes of the interaction. However, use case based testing may not cover all possible combinations of input conditions, as some scenarios may be omitted or overlooked.
Boundary value analysis is not a technique that can cover all possible combinations of input conditions for withdrawing money from an ATM. Boundary value analysis is a technique that tests boundary values between partitions of equivalent data. Boundary values are values at the edge of an equivalence partition or at the smallest incremental distance on either side of an edge. Boundary value analysis can be used to test components that have input values that can be divided into partitions of equivalent data. For example, for testing the ATM, we can identify boundary values for the input amount, such as the minimum and maximum amount allowed by the system or the user’s account. However, boundary value analysis may not cover all possible combinations of input conditions, as some conditions may not have boundary values or may not be related to input values. Equivalence class partitioning is not a technique that can cover all possible combinations of input conditions for withdrawing money from an ATM. Equivalence class partitioning is a technique that divides the input data and output results of a software component into partitions of equivalent data. Each partition should contain data that is treated in the same way by the component. Equivalence class partitioning can be used to test components that have input values that can be divided into partitions of equivalent data. For example, for testing the ATM, we can identify equivalence partitions for the input amount, such as valid amount (within the range allowed by the system and the user’s account) and invalid amount (outside the range allowed by the system or the user’s account). However, equivalence class partitioning may not cover all possible combinations of input conditions, as some conditions may not be related to input values or may have more than two partitions.
Verified Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 4, page 34-46.
Question #42
Which of the following statements about reviews are TRUE?
I, In walkthroughs the review meeting is typically led by the author.
II, Inspection is characterized by an open-ended review meeting
III, Preparation before the review meeting is part of informal reviews
IV, Management rarely participates in technical review meetings
- A . II, Ill
- B . I, II
- C . I, IV
- D . III, IV
Correct Answer: C
C
Explanation:
The following statements about reviews are true:
I) In walkthroughs the review meeting is typically led by the author. A walkthrough is a type of review that has a predefined objective and agenda but no formal process or roles. A walkthrough is typically led by the author of the work product under review, who guides the participants through a scenario and solicits feedback.
IV) Management rarely participates in technical review meetings. A technical review is a type of review that has a predefined objective and agenda but no formal process or roles. A technical review is typically performed by peers with technical expertise in order to evaluate technical aspects of a work product. Management rarely participates in technical review meetings, as they may not have sufficient technical knowledge or skills to contribute effectively. The following statements about reviews are false:
II) Inspection is characterized by an open-ended review meeting. An inspection is a type of review that follows a defined process with formal entry and exit criteria and roles and responsibilities for participants. An inspection is characterized by a structured review meeting with a fixed duration and agenda.
III) Preparation before the review meeting is part of informal reviews. Preparation before the review meeting is part of formal reviews, such as inspections or technical reviews. Preparation involves checking
C
Explanation:
The following statements about reviews are true:
I) In walkthroughs the review meeting is typically led by the author. A walkthrough is a type of review that has a predefined objective and agenda but no formal process or roles. A walkthrough is typically led by the author of the work product under review, who guides the participants through a scenario and solicits feedback.
IV) Management rarely participates in technical review meetings. A technical review is a type of review that has a predefined objective and agenda but no formal process or roles. A technical review is typically performed by peers with technical expertise in order to evaluate technical aspects of a work product. Management rarely participates in technical review meetings, as they may not have sufficient technical knowledge or skills to contribute effectively. The following statements about reviews are false:
II) Inspection is characterized by an open-ended review meeting. An inspection is a type of review that follows a defined process with formal entry and exit criteria and roles and responsibilities for participants. An inspection is characterized by a structured review meeting with a fixed duration and agenda.
III) Preparation before the review meeting is part of informal reviews. Preparation before the review meeting is part of formal reviews, such as inspections or technical reviews. Preparation involves checking
Question #43
The following part of a business process flow is specified; REPEAT (book a bill) UNTIL (User presses Cancel).
How many test cases are necessary in order to achieve 100% branch coverage of the process flow?
- A . 4
- B . 1
- C . 2
- D . Infinite
Correct Answer: C
C
Explanation:
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
Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 4, page 40-41.
C
Explanation:
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
Reference: [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer], Chapter 4, page 40-41.
Question #44
Why it is essential that defects found in a review be reported objectively?
- A . In order to facilitate easy entry of detected defects in a OTS (Defect Tracking System)
- B . In order to allow the author of reviewed work product(S) to take the feedback positively as an effort at improving the product (S) and not as a personal assault
- C . In order to allow the review moderator to easily understand them, and assign them to the right developer for fixing
- D . In order to allow augmentation of existing checklists used for reviewing the work product (S)
Correct Answer: B
B
Explanation:
The purpose of a review is to find defects and improve the quality of the work product, not to criticize or blame the author. Reporting defects objectively means describing them factually and constructively, without using negative or emotional language that could offend the author or damage their motivation. This way, the author can take the feedback positively as an effort at improving the product and not as a personal assault.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 138.
B
Explanation:
The purpose of a review is to find defects and improve the quality of the work product, not to criticize or blame the author. Reporting defects objectively means describing them factually and constructively, without using negative or emotional language that could offend the author or damage their motivation. This way, the author can take the feedback positively as an effort at improving the product and not as a personal assault.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 138.
Question #45
The testers in company A were part of the development team. Due to an organizational change they moved to be part of the support team.
What are the advantages and the disadvantages of this change?
- A . Advantage: More independence in deciding what and how to test, Disadvantage: Isolation from me development team knowledge
- B . Advantage: being closer to customer perspective, Disadvantage less independence in perspectives
- C . Advantage: pulled to support tasks and having less time for testing, Disadvantage less chances to move a tester to development
- D . Advantage: increased chances to move a tester to development; Disadvantage: pulled to support tasks and having less time for testing
Correct Answer: B
B
Explanation:
Being part of the support team means that the testers are closer to the customer perspective, which is an advantage for testing, as they can better understand the user needs and expectations, and identify more realistic scenarios and risks. However, being part of the support team also means that they have less independence in deciding what and how to test, as they may be influenced by the customer’s preferences or requests, which could compromise the objectivity and effectiveness of testing.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 6.
B
Explanation:
Being part of the support team means that the testers are closer to the customer perspective, which is an advantage for testing, as they can better understand the user needs and expectations, and identify more realistic scenarios and risks. However, being part of the support team also means that they have less independence in deciding what and how to test, as they may be influenced by the customer’s preferences or requests, which could compromise the objectivity and effectiveness of testing.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 6.
Question #46
The following sentences refer to the ‘Standard for Software Test Documentation’ specification (IEEE 829).
Which sentence is correct?
- A . Any deviation from this standard should be approved by management, marketing & development
- B . Most test documentation regimes follow this spec to some degree, with changes done to fit a specific situation or organization
- C . The key to high quality test documentation regimes is strict adherence to this standard
- D . This test plan outline is relevant for military projects. For consumer market projects there is a different specification with fewer items.
Correct Answer: B
B
Explanation:
The IEEE 829 standard is a widely used specification for test documentation, but it is not mandatory or universal. Most test documentation regimes follow this spec to some degree, with changes done to fit a specific situation or organization. The standard does not require any approval from management, marketing or development for any deviation, nor does it depend on the type of project (military or consumer market). The standard also does not guarantee high quality test documentation regimes, as it only provides a general outline and format, not the actual content or quality criteria.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 16.
B
Explanation:
The IEEE 829 standard is a widely used specification for test documentation, but it is not mandatory or universal. Most test documentation regimes follow this spec to some degree, with changes done to fit a specific situation or organization. The standard does not require any approval from management, marketing or development for any deviation, nor does it depend on the type of project (military or consumer market). The standard also does not guarantee high quality test documentation regimes, as it only provides a general outline and format, not the actual content or quality criteria.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 16.
Question #47
4 equivalence classes are given for integer values:
0 < x <100
100<= x <= 200
200 < x < 500
x >= 500
Which of the following options represent correct set of data for valid equivalence class partitions?
- A . 50; 100; 200. 1000
- B . 0. 1.99, 100.200,201.499, 500;
- C . 0.50; 100; 150.200.350.500;
- D . 50; 100; 250; 1000
Correct Answer: C
C
Explanation:
The correct set of data for valid equivalence class partitions should include one value from each equivalence class, and no value from outside the range. Option C satisfies this condition, as it has one value from each of the four equivalence classes (50, 100, 250, 500). Option A has two values from the same equivalence class (100 and 200), option B has values outside the range (0 and 0.99), and option D has two values from the same equivalence class (1000 and 500).
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 35.
C
Explanation:
The correct set of data for valid equivalence class partitions should include one value from each equivalence class, and no value from outside the range. Option C satisfies this condition, as it has one value from each of the four equivalence classes (50, 100, 250, 500). Option A has two values from the same equivalence class (100 and 200), option B has values outside the range (0 and 0.99), and option D has two values from the same equivalence class (1000 and 500).
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 35.
Question #48
Which of the following are valid testing principles?
I) Exhaustive testing is in general impossible.
II) Exhaustive testing should be executed for code intended to be reused.
III) Testing may guarantee that a program is correct.
IV) Testing cannot guarantee that a program is correct.
V) Defects cluster together in certain areas of the product.
- A . I, IV, V
- B . II, Iv
- C . I, V
- D . I, Ill
Correct Answer: A
A
Explanation:
Statements I, IV and V are valid testing principles according to the ISTQB syllabus. Statement I states that exhaustive testing is in general impossible, because it would require testing all possible inputs, outputs and combinations of states, which is usually impractical or impossible. Statement IV states that testing cannot guarantee that a program is correct, because testing can only show the presence of defects, not their absence. Statement V states that defects cluster together in certain areas of the product, which means that some modules or functions are more likely to contain defects than others. Statements II and III are invalid testing principles. Statement II states that exhaustive testing should be executed for code intended to be reused, which contradicts statement I, Statement III states that testing may guarantee that a program is correct, which contradicts statement IV, Verified
Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, pages 4-5.
A
Explanation:
Statements I, IV and V are valid testing principles according to the ISTQB syllabus. Statement I states that exhaustive testing is in general impossible, because it would require testing all possible inputs, outputs and combinations of states, which is usually impractical or impossible. Statement IV states that testing cannot guarantee that a program is correct, because testing can only show the presence of defects, not their absence. Statement V states that defects cluster together in certain areas of the product, which means that some modules or functions are more likely to contain defects than others. Statements II and III are invalid testing principles. Statement II states that exhaustive testing should be executed for code intended to be reused, which contradicts statement I, Statement III states that testing may guarantee that a program is correct, which contradicts statement IV, Verified
Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, pages 4-5.
Question #49
Which of the following statements contradicts the general principles of testing?
- A . Most defects are found in a small subset of a system’s modules.
- B . If new defects are to be found we should run the same test set more often.
- C . Testing is better if it starts at the beginning of a project.
- D . How testing is done, is based on the situation in a particular project.
Correct Answer: B
B
Explanation:
Statement B contradicts the general principles of testing, because running the same test set more often will not increase the chances of finding new defects, unless there are some changes in the system or environment that affect the test results. Running different test sets with different inputs, outputs or conditions would be more effective in finding new defects. Statements A, C and D are consistent with the general principles of testing. Statement A states that most defects are found in a small subset of a system’s modules, which is true according to the defect clustering principle. Statement C states that testing is better if it starts at the beginning of a project, which is true according to the early testing principle. Statement D states that how testing is done, is based on the situation in a particular project, which is true according to the context-dependent testing principle.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, pages 4-6.
B
Explanation:
Statement B contradicts the general principles of testing, because running the same test set more often will not increase the chances of finding new defects, unless there are some changes in the system or environment that affect the test results. Running different test sets with different inputs, outputs or conditions would be more effective in finding new defects. Statements A, C and D are consistent with the general principles of testing. Statement A states that most defects are found in a small subset of a system’s modules, which is true according to the defect clustering principle. Statement C states that testing is better if it starts at the beginning of a project, which is true according to the early testing principle. Statement D states that how testing is done, is based on the situation in a particular project, which is true according to the context-dependent testing principle.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, pages 4-6.
Question #50
Which of the following is true about Oracles?
- A . Sometimes old version of a product can be used as an Oracle
- B . Oracles help in reproducing the irreproducible bugs
- C . Oracles are derived from the design
- D . Oracles can be generated automatically using data generators
Correct Answer: A
A
Explanation:
An oracle is a mechanism or source that can provide the expected result for a given test input or situation. Sometimes old version of a product can be used as an oracle, if it is assumed that the old version behaves correctly for the test cases that are executed on the new version. This is also known as back-to-back testing. Oracles do not help in reproducing the irreproducible bugs, as they only provide the expected results, not the actual results. Oracles are not derived from the design, but from the requirements or specifications. Oracles cannot be generated automatically using data generators, as data generators only provide test inputs, not test outputs.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 9.
A
Explanation:
An oracle is a mechanism or source that can provide the expected result for a given test input or situation. Sometimes old version of a product can be used as an oracle, if it is assumed that the old version behaves correctly for the test cases that are executed on the new version. This is also known as back-to-back testing. Oracles do not help in reproducing the irreproducible bugs, as they only provide the expected results, not the actual results. Oracles are not derived from the design, but from the requirements or specifications. Oracles cannot be generated automatically using data generators, as data generators only provide test inputs, not test outputs.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 9.
Question #51
Which type of software development product can undergo static testing?
- A . Any software development product can undergo static testing, including requirements specifications, design specifications and code.
- B . Static tests should be performed on the installation and user guide documents as these documents are used by the end user.
- C . Static testing is done only on the code as part of the "code review" sessions Other documents are reviewed, but not by static testing.
- D . Static testing is done only on the requirements You need to execute the software in order to find defects in the code.
Correct Answer: A
A
Explanation:
Static testing is a form of testing that does not involve executing the software, but rather analyzing it for defects, errors, or violations of standards. Static testing can be applied to any software development product, including requirements specifications, design specifications, code, test cases, test plans, user manuals, etc. Static testing can be done by using various techniques such as reviews, inspections, walkthroughs, checklists, static analysis tools, etc.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 7.
A
Explanation:
Static testing is a form of testing that does not involve executing the software, but rather analyzing it for defects, errors, or violations of standards. Static testing can be applied to any software development product, including requirements specifications, design specifications, code, test cases, test plans, user manuals, etc. Static testing can be done by using various techniques such as reviews, inspections, walkthroughs, checklists, static analysis tools, etc.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 7.
Question #52
The following incident report that was generated during test of a web application.
What would you suggest as the most important report improvement?
Defect detected date: 15 8.2010
Defect detected by: Joe Smith
Test level System test
Test case: Area 5/TC 98
Build version: 2011-16.2
Defect description After having filled out all required fields in screen 1, t click ENTER to continue to screen 2 Nothing happens, no system response at all.
- A . Add information about which web browser was used
- B . Add information about which developer should fix the bug
- C . Add the time stamp when the incident happened
- D . Add an impact analysis
Correct Answer: A
A
Explanation:
The most important report improvement for the given incident report would be to add information about which web browser was used when the defect was detected. This information is relevant for reproducing and debugging the defect, as different web browsers may have different behaviors or compatibility issues with the web application. The other options are less important or irrelevant for the incident report. The developer who should fix the bug can be assigned by the project manager or the defect tracking system, not by the tester who reports the defect. The time stamp when the incident happened is not very useful, as it does not indicate the cause or the frequency of the defect. The impact analysis is not part of the incident report, but rather of the risk assessment or prioritization process.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 140.
A
Explanation:
The most important report improvement for the given incident report would be to add information about which web browser was used when the defect was detected. This information is relevant for reproducing and debugging the defect, as different web browsers may have different behaviors or compatibility issues with the web application. The other options are less important or irrelevant for the incident report. The developer who should fix the bug can be assigned by the project manager or the defect tracking system, not by the tester who reports the defect. The time stamp when the incident happened is not very useful, as it does not indicate the cause or the frequency of the defect. The impact analysis is not part of the incident report, but rather of the risk assessment or prioritization process.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 140.
Question #53
Which of the following statements is LEAST likely to be describing component testing?
- A . It identifies defects in modules and classes.
- B . Simulators and stubs may be required.
- C . It mainly tests interfaces and interaction between components.
- D . It may be applied using a test-first approach.
Correct Answer: C
C
Explanation:
Component testing (also known as unit testing or module testing) is a level of testing that focuses on verifying the functionality and quality of individual software components (such as modules, classes, functions, methods, etc.). Component testing mainly tests interfaces and interaction between components, as well as internal logic and data structures of the components. Component testing may be applied using a test-first approach (such as test-driven development or behavior-driven development), where tests are written before the code is implemented. Component testing does not identify defects in modules and classes, as this is a result of component testing, not an objective. Simulators and stubs may be required for component testing, as they can simulate or replace missing or incomplete components or external systems that are needed for testing.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 19.
C
Explanation:
Component testing (also known as unit testing or module testing) is a level of testing that focuses on verifying the functionality and quality of individual software components (such as modules, classes, functions, methods, etc.). Component testing mainly tests interfaces and interaction between components, as well as internal logic and data structures of the components. Component testing may be applied using a test-first approach (such as test-driven development or behavior-driven development), where tests are written before the code is implemented. Component testing does not identify defects in modules and classes, as this is a result of component testing, not an objective. Simulators and stubs may be required for component testing, as they can simulate or replace missing or incomplete components or external systems that are needed for testing.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 19.