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.
Question #54
Which of the following is NOT a common objective of testing?
- A . Finding defects in the software
- B . Preventing defects
- C . Debugging the software to find the reason for defects
- D . Providing information on the status of the system
Correct Answer: C
C
Explanation:
Debugging the software to find the reason for defects is not a common objective of testing, but rather a task of development or maintenance. Debugging is a process of locating and fixing errors in the software code, while testing is a process of finding and reporting defects in the software behavior or quality. Testing does not aim to fix defects, but rather to provide information on their existence and impact. The other options are common objectives of testing. Finding defects in the software is one of the main objectives of testing, as it helps to improve the quality and reliability of the software. Preventing defects is another objective of testing, as it helps to avoid rework and reduce costs and risks. Providing information on the status of the system is another objective of testing, as it helps to support decision making and risk management.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 3.
C
Explanation:
Debugging the software to find the reason for defects is not a common objective of testing, but rather a task of development or maintenance. Debugging is a process of locating and fixing errors in the software code, while testing is a process of finding and reporting defects in the software behavior or quality. Testing does not aim to fix defects, but rather to provide information on their existence and impact. The other options are common objectives of testing. Finding defects in the software is one of the main objectives of testing, as it helps to improve the quality and reliability of the software. Preventing defects is another objective of testing, as it helps to avoid rework and reduce costs and risks. Providing information on the status of the system is another objective of testing, as it helps to support decision making and risk management.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 3.
Question #55
A Static analysis tool analyzes a given program’s CONTROL FLOW among other things.
Which of the following options represents the most likely outcome of the control flow analysis:
- A . Identification of unreachable code
- B . Report on adherence to the coding standards
- C . Number of comment lines
- D . Number of source code lines
Correct Answer: A
A
Explanation:
A static analysis tool is a tool that analyzes a given program’s source code or executable code without executing it. A static analysis tool can perform various types of analysis on a program’s code, such as syntax checking, data flow analysis, control flow analysis, complexity measurement, coding standards compliance checking, etc. Control flow analysis is a type of analysis that examines how a program’s statements are executed in different paths or branches. One of the most likely outcomes of control flow analysis is identification of unreachable code, which is code that can never be executed due to logical errors or design flaws. Unreachable code can reduce readability and maintainability of the code, as well as increase complexity and size. The other options are not outcomes of control flow analysis, but rather outcomes of other types of analysis. Report on adherence to coding standards is an outcome of coding standards compliance checking. Number of comment lines and number of source code lines are outcomes of complexity measurement.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 8.
A
Explanation:
A static analysis tool is a tool that analyzes a given program’s source code or executable code without executing it. A static analysis tool can perform various types of analysis on a program’s code, such as syntax checking, data flow analysis, control flow analysis, complexity measurement, coding standards compliance checking, etc. Control flow analysis is a type of analysis that examines how a program’s statements are executed in different paths or branches. One of the most likely outcomes of control flow analysis is identification of unreachable code, which is code that can never be executed due to logical errors or design flaws. Unreachable code can reduce readability and maintainability of the code, as well as increase complexity and size. The other options are not outcomes of control flow analysis, but rather outcomes of other types of analysis. Report on adherence to coding standards is an outcome of coding standards compliance checking. Number of comment lines and number of source code lines are outcomes of complexity measurement.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 8.
Question #56
Which of the following tools is most likely to detect defects in functions or methods in source code?
- A . configuration management tool
- B . unit test framework tool
- C . test design tool
- D . monitoring tool
Correct Answer: B
B
Explanation:
A unit test framework tool is a tool that supports the creation, execution, and reporting of unit tests, which are tests that verify the functionality and quality of individual software components (such as functions or methods) in source code. A unit test framework tool can help to detect defects in functions or methods in source code by providing features such as test case generation, test case execution, test result comparison, test coverage measurement, etc. Some examples of unit test framework tools are JUnit, NUnit, TestNG, etc. The other options are not tools that are likely to detect defects in functions or methods in source code. A configuration management tool is a tool that supports the management and control of different versions and variants of software products or components. A test design tool is a tool that supports the design and generation of test cases based on some criteria or rules. A monitoring tool is a tool that monitors the behavior or performance of a system or component under test.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 10.
B
Explanation:
A unit test framework tool is a tool that supports the creation, execution, and reporting of unit tests, which are tests that verify the functionality and quality of individual software components (such as functions or methods) in source code. A unit test framework tool can help to detect defects in functions or methods in source code by providing features such as test case generation, test case execution, test result comparison, test coverage measurement, etc. Some examples of unit test framework tools are JUnit, NUnit, TestNG, etc. The other options are not tools that are likely to detect defects in functions or methods in source code. A configuration management tool is a tool that supports the management and control of different versions and variants of software products or components. A test design tool is a tool that supports the design and generation of test cases based on some criteria or rules. A monitoring tool is a tool that monitors the behavior or performance of a system or component under test.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 10.
Question #57
A system has valid input numbers ranging between 1000 and 99999 (both inclusive).
Which of the following inputs are a result of designing tests for all valid equivalence classes and their boundaries?
- A . 999.1000.23232.99999.100000
- B . 999.1000.50000.100000.100001
- C . 999.100000
- D . 1000,50000,99999
Correct Answer: B
B
Explanation:
A correct list of boundary values for the P input should include the minimum and maximum values of the valid range (15 and 350), as well as the values just below and above the boundaries (14 and 351). Boundary value analysis is a test design technique that involves testing the values at or near the boundaries of an input domain or output range, as these values are more likely to cause errors than values in the middle. Option B satisfies this condition, as it has all four boundary values (14, 15, 350, 351). Option A has two values from the same equivalence class (1000 and 99999), option C has two values outside the range (999 and 100000), and option D has no boundary values at all.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 34.
B
Explanation:
A correct list of boundary values for the P input should include the minimum and maximum values of the valid range (15 and 350), as well as the values just below and above the boundaries (14 and 351). Boundary value analysis is a test design technique that involves testing the values at or near the boundaries of an input domain or output range, as these values are more likely to cause errors than values in the middle. Option B satisfies this condition, as it has all four boundary values (14, 15, 350, 351). Option A has two values from the same equivalence class (1000 and 99999), option C has two values outside the range (999 and 100000), and option D has no boundary values at all.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 34.
Question #58
Which of the following is the most important task of a typical test leader?
- A . To automate tests.
- B . To prepare and acquire test data.
- C . To set up the test environment.
- D . To coordinate the test strategy with project managers.
Correct Answer: D
D
Explanation:
The most important task of a typical test leader is to coordinate the test strategy with project managers. The test strategy is a high-level document that defines the general approach and objectives of testing for a project or an organization. The test leader is responsible for defining, documenting, communicating, and implementing the test strategy in alignment with the project goals and constraints. The test leader also needs to coordinate with project managers and other stakeholders to ensure that the test strategy is feasible, effective, and efficient. The other options are not the most important tasks of a typical test leader. To automate tests is a task of a test automation engineer or a test automation specialist. To prepare and acquire test data is a task of a test analyst or a test engineer. To set up the test environment is a task of a test environment manager or a test environment specialist.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 13.
D
Explanation:
The most important task of a typical test leader is to coordinate the test strategy with project managers. The test strategy is a high-level document that defines the general approach and objectives of testing for a project or an organization. The test leader is responsible for defining, documenting, communicating, and implementing the test strategy in alignment with the project goals and constraints. The test leader also needs to coordinate with project managers and other stakeholders to ensure that the test strategy is feasible, effective, and efficient. The other options are not the most important tasks of a typical test leader. To automate tests is a task of a test automation engineer or a test automation specialist. To prepare and acquire test data is a task of a test analyst or a test engineer. To set up the test environment is a task of a test environment manager or a test environment specialist.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 13.
Question #59
Which of the following is NOT an experience-based technique?
- A . Boundary value analysis.
- B . Error guessing
- C . Exploratory testing
- D . Fault attack
Correct Answer: A
A
Explanation:
Boundary value analysis is not an experience-based technique, but rather a specification-based technique (also known as black-box technique). Experience-based techniques are techniques that rely on the tester’s knowledge and intuition to derive and select test cases based on their experience with similar systems, technologies, domains, risks, etc. Some examples of experience-based techniques are error guessing, exploratory testing, fault attack, checklist-based testing, etc. Specification-based techniques are techniques that rely on the tester’s analysis and interpretation of the requirements or specifications of the system under test to derive and select test cases based on some criteria or rules. Some examples of specification-based techniques are equivalence partitioning, boundary value analysis, decision table testing, state transition testing, etc.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 31.
A
Explanation:
Boundary value analysis is not an experience-based technique, but rather a specification-based technique (also known as black-box technique). Experience-based techniques are techniques that rely on the tester’s knowledge and intuition to derive and select test cases based on their experience with similar systems, technologies, domains, risks, etc. Some examples of experience-based techniques are error guessing, exploratory testing, fault attack, checklist-based testing, etc. Specification-based techniques are techniques that rely on the tester’s analysis and interpretation of the requirements or specifications of the system under test to derive and select test cases based on some criteria or rules. Some examples of specification-based techniques are equivalence partitioning, boundary value analysis, decision table testing, state transition testing, etc.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 31.
Question #60
Which of the following statements about test reports are TRUE?
I. Test reports shall be approved by the test team.
II. Test reports shall give stakeholders information as basis for decisions.
Ill. Test reports shall summarize what happened through a period of testing.
IV. Test reports shall be approved by the development team, the test team and the customer
V. Test reports shall include information about remaining risks.
- A . II, III, V
- B . I, II, IV
- C . I, III, v
- D . II, III, IV
Correct Answer: A
A
Explanation:
Statements II, III and V are true about test reports. Test reports are documents that provide information on the results and status of testing activities for a given period or phase. Test reports should give stakeholders information as basis for decisions, such as whether to release the software product, whether to continue testing, whether to change the scope or priorities of testing, etc. Test reports should summarize what happened through a period of testing, such as what test cases were executed, what defects were found, what risks were identified, what issues were encountered, what achievements were made, etc. Test reports should include information about remaining risks, such as what defects are still open, what test cases are still pending, what functionalities are still untested, what uncertainties are still unresolved, etc. Statements I and IV are not true about test reports. Test reports do not need to be approved by the test team, the development team, or the customer, unless it is specified by the test policy or the test plan. Test reports only need to be reviewed and verified by the test leader or the test manager before being distributed to the intended recipients.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 141.
A
Explanation:
Statements II, III and V are true about test reports. Test reports are documents that provide information on the results and status of testing activities for a given period or phase. Test reports should give stakeholders information as basis for decisions, such as whether to release the software product, whether to continue testing, whether to change the scope or priorities of testing, etc. Test reports should summarize what happened through a period of testing, such as what test cases were executed, what defects were found, what risks were identified, what issues were encountered, what achievements were made, etc. Test reports should include information about remaining risks, such as what defects are still open, what test cases are still pending, what functionalities are still untested, what uncertainties are still unresolved, etc. Statements I and IV are not true about test reports. Test reports do not need to be approved by the test team, the development team, or the customer, unless it is specified by the test policy or the test plan. Test reports only need to be reviewed and verified by the test leader or the test manager before being distributed to the intended recipients.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 141.
Question #61
Which of the following is a correct reason to apply test automation?
- A . When a new test automation tool is launched
- B . When there are a lot of repetitive testing tasks
- C . When it is easy to automate
- D . When it is cheap to buy test automation tools
Correct Answer: B
B
Explanation:
A correct reason to apply test automation is when there are a lot of repetitive testing tasks. Test automation is the use of software tools or scripts to perform or support testing activities, such as test case execution, test result comparison, test data generation, etc. Test automation can be beneficial when there are a lot of repetitive testing tasks that need to be performed frequently or consistently, such as regression testing, performance testing, load testing, etc. Test automation can help to save time and effort, increase reliability and accuracy, and improve coverage and efficiency of testing. The other options are not correct reasons to apply test automation. When a new test automation tool is launched is not a reason to apply test automation, but rather a factor for choosing a test automation tool. When it is easy to automate is not a reason to apply test automation, but rather a factor for evaluating the feasibility of test automation. When it is cheap to buy test automation tools is not a reason to apply test automation, but rather a factor for estimating the cost and benefit of test automation.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 10.
B
Explanation:
A correct reason to apply test automation is when there are a lot of repetitive testing tasks. Test automation is the use of software tools or scripts to perform or support testing activities, such as test case execution, test result comparison, test data generation, etc. Test automation can be beneficial when there are a lot of repetitive testing tasks that need to be performed frequently or consistently, such as regression testing, performance testing, load testing, etc. Test automation can help to save time and effort, increase reliability and accuracy, and improve coverage and efficiency of testing. The other options are not correct reasons to apply test automation. When a new test automation tool is launched is not a reason to apply test automation, but rather a factor for choosing a test automation tool. When it is easy to automate is not a reason to apply test automation, but rather a factor for evaluating the feasibility of test automation. When it is cheap to buy test automation tools is not a reason to apply test automation, but rather a factor for estimating the cost and benefit of test automation.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 10.
Question #62
Consider the following testing levels:
1) Component Testing
2) Integration Testing
3) System Testing
4) Acceptance Testing
Which of the following statements is true?
- A . Integration and system testing are applicable when V-model is used.
Component and acceptance testing are applicable when iterative development models are used. - B . All the testing levels are applicable to V-model for software development.
Only acceptance testing is applicable for iterative models. - C . Acceptance testing is applicable for all software development models.
Component and system testing are applicable only for the V-model. - D . All testing levels are applicable, independent of which software development life-cycle process (V-model. iterative, incremental) is used.
Correct Answer: D
D
Explanation:
All testing levels are applicable, independent of which software development life-cycle process (V-model, iterative, incremental) is used. Testing levels are defined based on the scope and objectives of testing, not on the software development model. Component testing, integration testing, system testing and acceptance testing are common testing levels that can be applied to any software development model, as long as they are planned and executed properly. The V-model is a software development model that emphasizes the relationship between each development phase and its corresponding testing phase. Iterative and incremental models are software development models that divide the development process into smaller cycles or iterations, where each iteration produces a working version of the software that can be tested and evaluated.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 18.
D
Explanation:
All testing levels are applicable, independent of which software development life-cycle process (V-model, iterative, incremental) is used. Testing levels are defined based on the scope and objectives of testing, not on the software development model. Component testing, integration testing, system testing and acceptance testing are common testing levels that can be applied to any software development model, as long as they are planned and executed properly. The V-model is a software development model that emphasizes the relationship between each development phase and its corresponding testing phase. Iterative and incremental models are software development models that divide the development process into smaller cycles or iterations, where each iteration produces a working version of the software that can be tested and evaluated.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 18.
Question #63
A test manager defined the following test levels in her test plan; Component, System and Acceptance.
Which Software Development lifecycle is the Test Manager most likely following?
- A . V-Model
- B . Agile
- C . Waterfall
- D . Prototyping
Correct Answer: A
A
Explanation:
The test manager is most likely following the V-model for software development. The V-model is a software development model that defines four testing levels that correspond to four development phases: component testing corresponds to component design, integration testing corresponds to architectural design, system testing corresponds to system requirements specification, and acceptance testing corresponds to user requirements specification. The V-model also defines the test planning and test execution activities for each testing level. Agile is a software development model that follows an iterative and incremental approach, where testing is integrated into each iteration and adapts to changing requirements and feedback. Waterfall is a software development model that follows a sequential and linear approach, where testing is performed after the development phase is completed. Prototyping is a software development model that involves creating a simplified version of the software to elicit user feedback and validate requirements before developing the final product.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 18.
A
Explanation:
The test manager is most likely following the V-model for software development. The V-model is a software development model that defines four testing levels that correspond to four development phases: component testing corresponds to component design, integration testing corresponds to architectural design, system testing corresponds to system requirements specification, and acceptance testing corresponds to user requirements specification. The V-model also defines the test planning and test execution activities for each testing level. Agile is a software development model that follows an iterative and incremental approach, where testing is integrated into each iteration and adapts to changing requirements and feedback. Waterfall is a software development model that follows a sequential and linear approach, where testing is performed after the development phase is completed. Prototyping is a software development model that involves creating a simplified version of the software to elicit user feedback and validate requirements before developing the final product.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 18.
Question #64
A software calculates the annual car tax using three inputs:
– E; the emission level of the vehicle
– P: the power of the vehicle
-T the type of the vehicle
The input value for P can be integer positive values between 15 and 350.
Which of the following answers contains a correct list of a boundary values for the P input?
- A . 14,351
- B . 14,15,350,351
- C . 15,350
- D . 5.175.500
Correct Answer: B
B
Explanation:
A correct list of boundary values for the P input should include the minimum and maximum values of the valid range (15 and 350), as well as the values just below and above the boundaries (14 and 351). Boundary value analysis is a test design technique that involves testing the values at or near the boundaries of an input domain or output range, as these values are more likely to cause errors than values in the middle. Option B satisfies this condition, as it has all four boundary values (14, 15, 350, 351). Option A has only two boundary values (14 and 351), option C has only two boundary values (15 and 350), and option D has no boundary values at all.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 34.
B
Explanation:
A correct list of boundary values for the P input should include the minimum and maximum values of the valid range (15 and 350), as well as the values just below and above the boundaries (14 and 351). Boundary value analysis is a test design technique that involves testing the values at or near the boundaries of an input domain or output range, as these values are more likely to cause errors than values in the middle. Option B satisfies this condition, as it has all four boundary values (14, 15, 350, 351). Option A has only two boundary values (14 and 351), option C has only two boundary values (15 and 350), and option D has no boundary values at all.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 34.
Question #65
A test engineer finds a defect while testing. After the developer has fixed the defect, the test engineer decides to re-run a complete section of the tests.
Which of the following is correct?
- A . The lest engineer should not re-run the tests, as they have already been run, and results recorded.
- B . The test engineer should not re-run the tests, they should be part of the developer tests.
- C . The test engineer should re-run the tests, in order to ensure that new defects have not been introduced by the fix.
- D . The test engineer should re-run the tests, because the defect shows that the test cases need to be updated.
Correct Answer: C
C
Explanation:
The test engineer should re-run the tests, in order to ensure that new defects have not been introduced by the fix. This is also known as regression testing, which is a type of testing that verifies that previously tested software still performs correctly after a change. Regression testing helps to detect any side effects or unintended consequences of a fix or a modification. The other options are incorrect reasons for re-running the tests. The test engineer should not re-run the tests, as they have already been run, and results recorded, because this ignores the possibility of new defects caused by the fix. The test engineer should not re-run the tests, they should be part of the developer tests, because this assumes that developer tests are sufficient and reliable, which may not be true. The test engineer should not re-run the tests, because the defect shows that the test cases need to be updated, because this does not address the impact of the fix on other test cases or functionalities.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 41.
C
Explanation:
The test engineer should re-run the tests, in order to ensure that new defects have not been introduced by the fix. This is also known as regression testing, which is a type of testing that verifies that previously tested software still performs correctly after a change. Regression testing helps to detect any side effects or unintended consequences of a fix or a modification. The other options are incorrect reasons for re-running the tests. The test engineer should not re-run the tests, as they have already been run, and results recorded, because this ignores the possibility of new defects caused by the fix. The test engineer should not re-run the tests, they should be part of the developer tests, because this assumes that developer tests are sufficient and reliable, which may not be true. The test engineer should not re-run the tests, because the defect shows that the test cases need to be updated, because this does not address the impact of the fix on other test cases or functionalities.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 41.
Question #66
Which of the following is NOT a product risk?
- A . Poor software usability
- B . Failure-prone software is delivered
- C . Problems in defining the right requirements
- D . Software does not perform the intended functions
Correct Answer: C
C
Explanation:
Problems in defining the right requirements is not a product risk, but rather a project risk. A product risk is a risk that affects the quality or performance of the software product itself, such as poor usability, failure-prone functionality, security vulnerabilities, compatibility issues, etc. A project risk is a risk that affects the management or delivery of the software project itself, such as unrealistic schedule, insufficient resources, unclear scope, changing requirements, etc. The other options are examples of product risks, as they relate to the software product’s characteristics or features.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 12.
C
Explanation:
Problems in defining the right requirements is not a product risk, but rather a project risk. A product risk is a risk that affects the quality or performance of the software product itself, such as poor usability, failure-prone functionality, security vulnerabilities, compatibility issues, etc. A project risk is a risk that affects the management or delivery of the software project itself, such as unrealistic schedule, insufficient resources, unclear scope, changing requirements, etc. The other options are examples of product risks, as they relate to the software product’s characteristics or features.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 12.
Question #67
Why should you choose a test technique?
- A . Because you need to match the way you test to the content of the product under test
- B . Because of the time constraints that usually accompany a test project
- C . Because this way you cover the full scope of the product’s functionality
- D . Because choosing a test technique is a common practice in software testing
Correct Answer: A
A
Explanation:
You should choose a test technique because you need to match the way you test to the content of the product under test. A test technique is a method or process for deriving and selecting test cases based on some criteria or rules. Different test techniques are suitable for different types of software products, depending on their characteristics, functionalities, requirements, specifications, risks, etc. Choosing a test technique helps to ensure that the test cases are relevant, effective, and efficient for the product under test. The other options are not correct reasons to choose a test technique. Time constraints are not a factor for choosing a test technique, but rather for prioritizing or optimizing testing activities. Covering the full scope of the product’s functionality is not a guarantee of choosing a test technique, but rather a goal of testing. Choosing a test technique is not a common practice in software testing, but rather a professional skill and responsibility.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 31.
A
Explanation:
You should choose a test technique because you need to match the way you test to the content of the product under test. A test technique is a method or process for deriving and selecting test cases based on some criteria or rules. Different test techniques are suitable for different types of software products, depending on their characteristics, functionalities, requirements, specifications, risks, etc. Choosing a test technique helps to ensure that the test cases are relevant, effective, and efficient for the product under test. The other options are not correct reasons to choose a test technique. Time constraints are not a factor for choosing a test technique, but rather for prioritizing or optimizing testing activities. Covering the full scope of the product’s functionality is not a guarantee of choosing a test technique, but rather a goal of testing. Choosing a test technique is not a common practice in software testing, but rather a professional skill and responsibility.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 31.
Question #68
Which of the following would be the LEAST likely to be used as the basis for a test exit criteria?
- A . Test schedules
- B . Cost of testing performed so far
- C . Confidence of testers in tested code
- D . Number of unfixed defects
Correct Answer: A
A
Explanation:
Test exit criteria are the conditions or requirements that must be met before testing can be concluded. Test exit criteria are usually defined in the test plan and agreed by the stakeholders. Test exit criteria can be based on various factors, such as test coverage, defect status, quality level, risk level, etc. Test schedules would be the least likely to be used as the basis for test exit criteria, because test schedules are not directly related to the quality or performance of the software product, but rather to the time or resources allocated for testing. Test schedules can be used as the basis for test entry criteria, which are the conditions or requirements that must be met before testing can start. The other options are more likely to be used as the basis for test exit criteria. Cost of testing performed so far can be used as a basis for test exit criteria, because it can indicate the return on investment or the cost-benefit ratio of testing. Confidence of testers in tested code can be used as a basis for test exit criteria, because it can reflect the level of satisfaction or assurance of the testers about the quality or reliability of the software product. Number of unfixed defects can be used as a basis for test exit criteria, because it can indicate the level of risk or impact of the remaining defects on the software product.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 13.
A
Explanation:
Test exit criteria are the conditions or requirements that must be met before testing can be concluded. Test exit criteria are usually defined in the test plan and agreed by the stakeholders. Test exit criteria can be based on various factors, such as test coverage, defect status, quality level, risk level, etc. Test schedules would be the least likely to be used as the basis for test exit criteria, because test schedules are not directly related to the quality or performance of the software product, but rather to the time or resources allocated for testing. Test schedules can be used as the basis for test entry criteria, which are the conditions or requirements that must be met before testing can start. The other options are more likely to be used as the basis for test exit criteria. Cost of testing performed so far can be used as a basis for test exit criteria, because it can indicate the return on investment or the cost-benefit ratio of testing. Confidence of testers in tested code can be used as a basis for test exit criteria, because it can reflect the level of satisfaction or assurance of the testers about the quality or reliability of the software product. Number of unfixed defects can be used as a basis for test exit criteria, because it can indicate the level of risk or impact of the remaining defects on the software product.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 13.
Question #69
How can testing contribute to higher quality?
- A . Testing help to measure the quality of software.
- B . Testing ensures that remaining defects are documented.
- C . Testing removes errors in the software.
- D . Testing eliminates the risk with software.
Correct Answer: A
A
Explanation:
Testing can contribute to higher quality by helping to measure the quality of software. Quality is defined as the degree to which a component or system satisfies specified requirements and customer or user needs and expectations. Testing is a process of evaluating a component or system by applying inputs and observing outputs, and comparing them with expected results. Testing can help to measure the quality of software by providing information on its functionality, performance, usability, security, reliability, etc. Testing can also help to identify and report defects in software, which can lead to improvement actions and quality assurance activities. The other options are not accurate descriptions of how testing can contribute to higher quality. Testing does not ensure that remaining defects are documented, but rather that detected defects are reported. Testing does not remove errors in software, but rather finds defects in software behavior or quality. Testing does not eliminate the risk with software, but rather assesses and manages the risk with software.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 3.
A
Explanation:
Testing can contribute to higher quality by helping to measure the quality of software. Quality is defined as the degree to which a component or system satisfies specified requirements and customer or user needs and expectations. Testing is a process of evaluating a component or system by applying inputs and observing outputs, and comparing them with expected results. Testing can help to measure the quality of software by providing information on its functionality, performance, usability, security, reliability, etc. Testing can also help to identify and report defects in software, which can lead to improvement actions and quality assurance activities. The other options are not accurate descriptions of how testing can contribute to higher quality. Testing does not ensure that remaining defects are documented, but rather that detected defects are reported. Testing does not remove errors in software, but rather finds defects in software behavior or quality. Testing does not eliminate the risk with software, but rather assesses and manages the risk with software.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 3.
Question #70
A program got 100% decision coverage in a test.
Which of the following statements is then guaranteed to be true?
- A . Every executable statement Is covered.
- B . Every output equivalence class has been tested.
- C . Every input equivalence class has been tested.
- D . The "dead" code has not been covered.
Correct Answer: A
A
Explanation:
If a program got 100% decision coverage in a test, then it is guaranteed that every executable statement is covered. Decision coverage (also known as branch coverage) is a type of structural coverage (also known as white-box coverage) that measures how many decision outcomes have been exercised by a test suite. A decision outcome is a possible result of a decision point (such as an if-then-else statement) in a program’s code. Decision coverage requires that each decision point has both true and false outcomes executed at least once by a test suite. Decision coverage implies statement coverage, which is another type of structural coverage that measures how many executable statements have been executed by a test suite. Statement coverage requires that each executable statement is executed at least once by a test suite. Therefore, if a program got 100% decision coverage in a test, then it also got 100% statement coverage in a test, which means that every executable statement is covered. The other options are not guaranteed to be true if a program got 100% decision coverage in a test. Every output equivalence class has been tested and every input equivalence class has been tested are not guaranteed to be true if a program got 100% decision coverage in a test, because equivalence classes are based on functional requirements or specifications, not on code structure or logic. Equivalence classes are used in specification-based testing (also known as black-box testing), which is a type of testing that does not consider the internal structure or implementation of the system under test. Decision coverage is used in structure-based testing (also known as white-box testing), which is a type of testing that considers the internal structure or implementation of the system under test. Therefore, achieving 100% decision coverage does not imply achieving 100% equivalence class coverage. The “dead” code has not been covered is not guaranteed to be true if a program got 100% decision coverage in a test, because dead code (also known as unreachable code) is code that can never be executed due to logical errors or design flaws. Dead code can reduce readability and maintainability of the code, as well as increase complexity and size. Decision coverage does not account for dead code, as it only considers the decision outcomes that are possible to execute. Therefore, achieving 100% decision coverage does not imply that the dead code has not been covered.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 36.
A
Explanation:
If a program got 100% decision coverage in a test, then it is guaranteed that every executable statement is covered. Decision coverage (also known as branch coverage) is a type of structural coverage (also known as white-box coverage) that measures how many decision outcomes have been exercised by a test suite. A decision outcome is a possible result of a decision point (such as an if-then-else statement) in a program’s code. Decision coverage requires that each decision point has both true and false outcomes executed at least once by a test suite. Decision coverage implies statement coverage, which is another type of structural coverage that measures how many executable statements have been executed by a test suite. Statement coverage requires that each executable statement is executed at least once by a test suite. Therefore, if a program got 100% decision coverage in a test, then it also got 100% statement coverage in a test, which means that every executable statement is covered. The other options are not guaranteed to be true if a program got 100% decision coverage in a test. Every output equivalence class has been tested and every input equivalence class has been tested are not guaranteed to be true if a program got 100% decision coverage in a test, because equivalence classes are based on functional requirements or specifications, not on code structure or logic. Equivalence classes are used in specification-based testing (also known as black-box testing), which is a type of testing that does not consider the internal structure or implementation of the system under test. Decision coverage is used in structure-based testing (also known as white-box testing), which is a type of testing that considers the internal structure or implementation of the system under test. Therefore, achieving 100% decision coverage does not imply achieving 100% equivalence class coverage. The “dead” code has not been covered is not guaranteed to be true if a program got 100% decision coverage in a test, because dead code (also known as unreachable code) is code that can never be executed due to logical errors or design flaws. Dead code can reduce readability and maintainability of the code, as well as increase complexity and size. Decision coverage does not account for dead code, as it only considers the decision outcomes that are possible to execute. Therefore, achieving 100% decision coverage does not imply that the dead code has not been covered.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 36.
Question #71
Which of the following should be included in a test status report?
I. Estimation details
II. Total number of open and closed defects
III. Actual effort spent
IV. Defect reports
V. Number of executed, failed, blocked tests
- A . III, V
- B . II, III
- C . I, II, IV
- D . II, III, V
Correct Answer: D
D
Explanation:
The following should be included in a test status report: total number of open and closed defects, actual effort spent, and number of executed, failed, and blocked tests. A test status report is a document that provides information on the results and status of testing activities for a given period or phase. A test status report should include information that is relevant, accurate, and timely for the intended audience and purpose. Some of the information that should be included in a test status report are: total number of open and closed defects, which can indicate the defect trend and defect density of the software product; actual effort spent, which can indicate the productivity and efficiency of the testing process; number of executed, failed, and blocked tests, which can indicate the test progress and test coverage of the software product. The following should not be included in a test status report: estimation details, defect reports, and impact analysis. Estimation details are not part of a test status report, but rather part of a test plan or a test estimation document. Estimation details provide information on the expected time, resources, and costs for testing activities, not on the actual results or status of testing activities. Defect reports are not part of a test status report, but rather separate documents that provide detailed information on individual defects found during testing. Defect reports include information such as defect description, defect severity, defect priority, defect status, defect resolution, etc. Defect reports can be referenced or summarized in a test status report, but not included in full. Impact analysis is not part of a test status report, but rather part of a risk assessment or prioritization process. Impact analysis provides information on the potential effects or consequences of a change or a defect on the software product or project. Impact analysis can be used to evaluate the amount or scope of testing to be performed, but not to report the results or status of testing activities.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 141.
D
Explanation:
The following should be included in a test status report: total number of open and closed defects, actual effort spent, and number of executed, failed, and blocked tests. A test status report is a document that provides information on the results and status of testing activities for a given period or phase. A test status report should include information that is relevant, accurate, and timely for the intended audience and purpose. Some of the information that should be included in a test status report are: total number of open and closed defects, which can indicate the defect trend and defect density of the software product; actual effort spent, which can indicate the productivity and efficiency of the testing process; number of executed, failed, and blocked tests, which can indicate the test progress and test coverage of the software product. The following should not be included in a test status report: estimation details, defect reports, and impact analysis. Estimation details are not part of a test status report, but rather part of a test plan or a test estimation document. Estimation details provide information on the expected time, resources, and costs for testing activities, not on the actual results or status of testing activities. Defect reports are not part of a test status report, but rather separate documents that provide detailed information on individual defects found during testing. Defect reports include information such as defect description, defect severity, defect priority, defect status, defect resolution, etc. Defect reports can be referenced or summarized in a test status report, but not included in full. Impact analysis is not part of a test status report, but rather part of a risk assessment or prioritization process. Impact analysis provides information on the potential effects or consequences of a change or a defect on the software product or project. Impact analysis can be used to evaluate the amount or scope of testing to be performed, but not to report the results or status of testing activities.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 141.
Question #72
In maintenance testing, what is the relationship between impact analysis and regression testing?
- A . Impact analysis requires a regression testing for only the tests that have detected faults in previous SW release
- B . There is no relationship between impact analysis and regression testing.
- C . Impact analysis requires a regression testing for all program elements which were newly integrated (new functionalities).
- D . The impact analysis is used to evaluate the amount of regression testing to be performed.
Correct Answer: D
D
Explanation:
In maintenance testing, the relationship between impact analysis and regression testing is that the impact analysis is used to evaluate the amount of regression testing to be performed. Maintenance testing is a type of testing that is performed on an existing software product after it has been delivered or deployed, in order to ensure that it still meets its requirements and functions correctly after a change or a modification. Maintenance testing can be triggered by various reasons, such as corrective maintenance (fixing defects), adaptive maintenance (adapting to new environments), perfective maintenance (improving performance), preventive maintenance (avoiding future problems), etc. Impact analysis is a technique that is used to assess the extent and nature of changes introduced by maintenance activities on the software product or project. Impact analysis helps to identify which parts of the software product are affected by the changes, which parts need to be modified or updated accordingly, which parts need to be retested or verified for correctness or compatibility, etc. Regression testing is a type of testing that verifies that previously tested software still performs correctly after a change or a modification. Regression testing helps to detect any side effects or unintended consequences of maintenance activities on the software product’s functionality or quality. Regression testing can be performed at various levels and scopes depending on the impact analysis results. Therefore, in maintenance testing, impact analysis is used to evaluate the amount of regression testing to be performed.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 20.
D
Explanation:
In maintenance testing, the relationship between impact analysis and regression testing is that the impact analysis is used to evaluate the amount of regression testing to be performed. Maintenance testing is a type of testing that is performed on an existing software product after it has been delivered or deployed, in order to ensure that it still meets its requirements and functions correctly after a change or a modification. Maintenance testing can be triggered by various reasons, such as corrective maintenance (fixing defects), adaptive maintenance (adapting to new environments), perfective maintenance (improving performance), preventive maintenance (avoiding future problems), etc. Impact analysis is a technique that is used to assess the extent and nature of changes introduced by maintenance activities on the software product or project. Impact analysis helps to identify which parts of the software product are affected by the changes, which parts need to be modified or updated accordingly, which parts need to be retested or verified for correctness or compatibility, etc. Regression testing is a type of testing that verifies that previously tested software still performs correctly after a change or a modification. Regression testing helps to detect any side effects or unintended consequences of maintenance activities on the software product’s functionality or quality. Regression testing can be performed at various levels and scopes depending on the impact analysis results. Therefore, in maintenance testing, impact analysis is used to evaluate the amount of regression testing to be performed.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 20.
Question #73
A software system checks age in order to determine which welcome screen to display. Age groups are:
Group I: 0-12
Group II; 13-18
Group III: over 18
Which of the below represent boundary values?
- A . (-1.0.12.13.18,19)
- B . (-1.0,11.12.13,14,18.19)
- C . (0.12.13.18.19)
- D . (4.5.15.20)
Correct Answer: A
A
Explanation:
A correct list of boundary values for the age input should include the minimum and maximum values of each age group (0, 12, 13, 18), as well as the values just below and above each boundary (-1, 19). Boundary value analysis is a test design technique that involves testing the values at or near the boundaries of an input domain or output range, as these values are more likely to cause errors than values in the middle. Option A satisfies this condition, as it has all six boundary values (-1, 0, 12, 13, 18, 19). Option B has two values from the same equivalence class (12 and 13), option C has only four boundary values (0, 12, 18, 19), and option D has no boundary values at all.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 34.
A
Explanation:
A correct list of boundary values for the age input should include the minimum and maximum values of each age group (0, 12, 13, 18), as well as the values just below and above each boundary (-1, 19). Boundary value analysis is a test design technique that involves testing the values at or near the boundaries of an input domain or output range, as these values are more likely to cause errors than values in the middle. Option A satisfies this condition, as it has all six boundary values (-1, 0, 12, 13, 18, 19). Option B has two values from the same equivalence class (12 and 13), option C has only four boundary values (0, 12, 18, 19), and option D has no boundary values at all.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 34.
Question #74
Which of the following is an example of black-box dynamic testing?
- A . Functional Testing
- B . Code inspection
- C . Checking memory leaks for a program by executing it
- D . Coverage analysis
Correct Answer: A
A
Explanation:
Functional testing is an example of black-box dynamic testing. Black-box testing (also known as specification-based testing) is a type of testing that does not consider the internal structure or implementation of the system under test, but rather its external behavior or functionality. Dynamic testing is a type of testing that involves executing the system under test with various inputs and observing its outputs. Functional testing is a type of black-box dynamic testing that verifies that the system under test performs its intended functions according to its requirements or specifications. Functional testing can be performed at various levels and scopes depending on the objectives and criteria of testing. The other options are not examples of black-box dynamic testing. Code inspection is an example of white-box static testing. White-box testing (also known as structure-based testing) is a type of testing that considers the internal structure or implementation of the system under test. Static testing is a type of testing that does not involve executing the system under test, but rather analyzing it for defects, errors, or violations of standards. Code inspection is a type of white-box static testing that involves examining the source code of the system under test for quality, readability, maintainability, etc. Checking memory leaks for a program by executing it is an example of white-box dynamic testing. Memory leaks are defects that occur when a program fails to release memory that it has allocated but no longer needs. Checking memory leaks for a program by executing it requires knowledge and access to the internal structure or implementation of the program, such as memory allocation and deallocation mechanisms, pointers, references, etc. Coverage analysis is an example of white-box static testing. Coverage analysis is a technique that measures how much of the code or structure of the system under test has been exercised by a test suite. Coverage analysis requires knowledge and access to the internal structure or implementation of the system under test, such as statements, branches, paths, conditions, etc.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 7.
A
Explanation:
Functional testing is an example of black-box dynamic testing. Black-box testing (also known as specification-based testing) is a type of testing that does not consider the internal structure or implementation of the system under test, but rather its external behavior or functionality. Dynamic testing is a type of testing that involves executing the system under test with various inputs and observing its outputs. Functional testing is a type of black-box dynamic testing that verifies that the system under test performs its intended functions according to its requirements or specifications. Functional testing can be performed at various levels and scopes depending on the objectives and criteria of testing. The other options are not examples of black-box dynamic testing. Code inspection is an example of white-box static testing. White-box testing (also known as structure-based testing) is a type of testing that considers the internal structure or implementation of the system under test. Static testing is a type of testing that does not involve executing the system under test, but rather analyzing it for defects, errors, or violations of standards. Code inspection is a type of white-box static testing that involves examining the source code of the system under test for quality, readability, maintainability, etc. Checking memory leaks for a program by executing it is an example of white-box dynamic testing. Memory leaks are defects that occur when a program fails to release memory that it has allocated but no longer needs. Checking memory leaks for a program by executing it requires knowledge and access to the internal structure or implementation of the program, such as memory allocation and deallocation mechanisms, pointers, references, etc. Coverage analysis is an example of white-box static testing. Coverage analysis is a technique that measures how much of the code or structure of the system under test has been exercised by a test suite. Coverage analysis requires knowledge and access to the internal structure or implementation of the system under test, such as statements, branches, paths, conditions, etc.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 7.
Question #75
What is ‘Component Testing’?
- A . Integration Testing
- B . Functional testing
- C . Experience-based testing
- D . A test level
Correct Answer: D
D
Explanation:
Component testing is a test level. A test level is a group of test activities that are organized and managed together based on some common characteristics or objectives. A test level can be defined based on various factors, such as the scope and target of testing, the phase and model of development, the stakeholders and roles involved in testing, etc. Component testing (also known as unit testing or module testing) is a test level that focuses on verifying the functionality and quality of individual software components (such as modules, classes, functions, methods, etc.). Component testing can be performed by developers or testers using various techniques and tools depending on the type and complexity of the components. The other options are not test levels. Integration testing is another test level that focuses on verifying the functionality and quality of groups of software components that interact with each other or with external systems. Functional testing is a type of black-box dynamic testing that verifies that the system under test performs its intended functions according to its requirements or specifications. Experience-based testing is a category of test design techniques that rely on the tester’s knowledge and intuition to derive and select test cases based on their experience with similar systems, technologies, domains, risks, etc.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 19.
D
Explanation:
Component testing is a test level. A test level is a group of test activities that are organized and managed together based on some common characteristics or objectives. A test level can be defined based on various factors, such as the scope and target of testing, the phase and model of development, the stakeholders and roles involved in testing, etc. Component testing (also known as unit testing or module testing) is a test level that focuses on verifying the functionality and quality of individual software components (such as modules, classes, functions, methods, etc.). Component testing can be performed by developers or testers using various techniques and tools depending on the type and complexity of the components. The other options are not test levels. Integration testing is another test level that focuses on verifying the functionality and quality of groups of software components that interact with each other or with external systems. Functional testing is a type of black-box dynamic testing that verifies that the system under test performs its intended functions according to its requirements or specifications. Experience-based testing is a category of test design techniques that rely on the tester’s knowledge and intuition to derive and select test cases based on their experience with similar systems, technologies, domains, risks, etc.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 19.
Question #76
Which of the following is NOT an objective of testing?
- A . Finding defects
- B . Providing information for decision-making
- C . Gaining confidence about the level of quality of the software
- D . Analyzing and removing the cause of failures
Correct Answer: D
D
Explanation:
Analyzing and removing the cause of failures is not an objective of testing, but rather a task of development or maintenance. A failure is an event or behavior that deviates from the expected or specified result of a system under test. A failure is caused by an error (also known as a mistake or a fault) in the software code, design, or specification. Analyzing and removing the cause of failures is a process of locating and fixing errors in the software code, design, or specification, which is also known as debugging or defect resolution. Analyzing and removing the cause of failures does not aim to find or report defects, but rather to correct or prevent them. The other options are objectives of testing. Finding defects is one of the main objectives of testing, as it helps to improve the quality and reliability of the software product. Providing information for decision-making is another objective of testing, as it helps to support decision making and risk management. Gaining confidence about the level of quality of the software is another objective of testing, as it helps to assure that the software product meets its requirements and customer or user needs and expectations.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 3.
D
Explanation:
Analyzing and removing the cause of failures is not an objective of testing, but rather a task of development or maintenance. A failure is an event or behavior that deviates from the expected or specified result of a system under test. A failure is caused by an error (also known as a mistake or a fault) in the software code, design, or specification. Analyzing and removing the cause of failures is a process of locating and fixing errors in the software code, design, or specification, which is also known as debugging or defect resolution. Analyzing and removing the cause of failures does not aim to find or report defects, but rather to correct or prevent them. The other options are objectives of testing. Finding defects is one of the main objectives of testing, as it helps to improve the quality and reliability of the software product. Providing information for decision-making is another objective of testing, as it helps to support decision making and risk management. Gaining confidence about the level of quality of the software is another objective of testing, as it helps to assure that the software product meets its requirements and customer or user needs and expectations.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 3.
Question #77
An Incident Management tool implements the following defect states;
Open, Assigned, Solved, Closed Consider the following defect report:
Id T000561
Test Object "Warehouse Management’ application
Tester name; John Bishop
Date: 10th. April 2010
Test Case MRT558I
Status OPEN
Severity Serious
Priority
Problem- After inputting the Total Quantity item = 450 in the SV034 screen, the system shows an unexpected Error message=47
Correction:
Developer name:
Closing date:
Which of the following is a valid criticism of this report?
- A . The Priority, the Correction description and the Developer name are missing
- B . The version of the application is missing
- C . There is no link to the applicable requirement (traceability)
- D . The description is not highlighting the source of the problem
Correct Answer: B
B
Explanation:
A valid criticism of this report is that the version of the application is missing. The version of the application is an important piece of information that should be included in a defect report, as it helps to identify which release or build of the software product contains the defect. The version of the application can also help to reproduce and debug the defect, as different versions may have different behaviors or features. The other options are not valid criticisms of this report. The priority, the correction description and the developer name are not missing, but rather not applicable for this report. The priority is a measure of how urgently a defect needs to be fixed, which can be assigned by the project manager or the defect tracking system, not by the tester who reports the defect. The correction description and the developer name are information that are added after the defect has been resolved, not when it has been reported. There is no link to the applicable requirement (traceability) is not a valid criticism of this report, because traceability is not a mandatory attribute of a defect report, but rather an optional one. Traceability is a relationship between two or more entities (such as requirements, test cases, defects, etc.) that shows how they are related or dependent on each other. Traceability can help to verify that the requirements are met by the test cases and defects, but it is not essential for reporting a defect. The description is not highlighting the source of the problem is not a valid criticism of this report, because highlighting the source of the problem is not a responsibility of the tester who reports the defect, but rather of the developer who fixes the defect. The description should provide enough information to describe what happened when the defect occurred, such as input values, expected results, actual results, error messages, screenshots, etc., but it does not need to explain why or how it happened.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 140.
B
Explanation:
A valid criticism of this report is that the version of the application is missing. The version of the application is an important piece of information that should be included in a defect report, as it helps to identify which release or build of the software product contains the defect. The version of the application can also help to reproduce and debug the defect, as different versions may have different behaviors or features. The other options are not valid criticisms of this report. The priority, the correction description and the developer name are not missing, but rather not applicable for this report. The priority is a measure of how urgently a defect needs to be fixed, which can be assigned by the project manager or the defect tracking system, not by the tester who reports the defect. The correction description and the developer name are information that are added after the defect has been resolved, not when it has been reported. There is no link to the applicable requirement (traceability) is not a valid criticism of this report, because traceability is not a mandatory attribute of a defect report, but rather an optional one. Traceability is a relationship between two or more entities (such as requirements, test cases, defects, etc.) that shows how they are related or dependent on each other. Traceability can help to verify that the requirements are met by the test cases and defects, but it is not essential for reporting a defect. The description is not highlighting the source of the problem is not a valid criticism of this report, because highlighting the source of the problem is not a responsibility of the tester who reports the defect, but rather of the developer who fixes the defect. The description should provide enough information to describe what happened when the defect occurred, such as input values, expected results, actual results, error messages, screenshots, etc., but it does not need to explain why or how it happened.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 140.
Question #78
Which of the following is a key characteristic of informal reviews?
- A . Kick-off meeting
- B . Low cost
- C . Individual preparation
- D . Metrics analysis
Correct Answer: B
B
Explanation:
A key characteristic of informal reviews is low cost. Informal reviews are a type of review that does not follow a formal process or have any formal documentation. Informal reviews are usually performed by individuals or small groups of peers or colleagues who have some knowledge or interest in the product under review. Informal reviews can be done at any time and for any purpose, such as checking for errors, clarifying doubts, sharing ideas, etc. Informal reviews have low cost, as they do not require much time, effort, or resources to conduct. The other options are not key characteristics of informal reviews. Kick-off meeting is a characteristic of formal reviews, such as inspections or walkthroughs. Kick-off meeting is a meeting that is held before the review process starts, where the roles and responsibilities of the participants are defined, the objectives and scope of the review are agreed, and the logistics and schedule of the review are planned. Individual preparation is a characteristic of formal reviews, such as inspections or walkthroughs. Individual preparation is an activity that is performed by the reviewers before the review meeting, where they examine the product under review and identify any issues or questions that need to be discussed or resolved during the review meeting. Metrics analysis is a characteristic of formal reviews, such as inspections or walkthroughs. Metrics analysis is an activity that is performed after the review process is completed, where the data and results of the review are collected and analyzed to measure the effectiveness and efficiency of the review, as well as to identify any improvement actions or lessons learned for future reviews.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 9.
B
Explanation:
A key characteristic of informal reviews is low cost. Informal reviews are a type of review that does not follow a formal process or have any formal documentation. Informal reviews are usually performed by individuals or small groups of peers or colleagues who have some knowledge or interest in the product under review. Informal reviews can be done at any time and for any purpose, such as checking for errors, clarifying doubts, sharing ideas, etc. Informal reviews have low cost, as they do not require much time, effort, or resources to conduct. The other options are not key characteristics of informal reviews. Kick-off meeting is a characteristic of formal reviews, such as inspections or walkthroughs. Kick-off meeting is a meeting that is held before the review process starts, where the roles and responsibilities of the participants are defined, the objectives and scope of the review are agreed, and the logistics and schedule of the review are planned. Individual preparation is a characteristic of formal reviews, such as inspections or walkthroughs. Individual preparation is an activity that is performed by the reviewers before the review meeting, where they examine the product under review and identify any issues or questions that need to be discussed or resolved during the review meeting. Metrics analysis is a characteristic of formal reviews, such as inspections or walkthroughs. Metrics analysis is an activity that is performed after the review process is completed, where the data and results of the review are collected and analyzed to measure the effectiveness and efficiency of the review, as well as to identify any improvement actions or lessons learned for future reviews.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 9.
Question #79
Which of the following BEST matches the attributes with a level of testing?
I. Stubs and drivers are often used
II The lest environment should correspond to the production environment
III. Finding defects is not the main focus
IV. Testing can be based on use cases
V. Testing is normally performed by testers
VI. Testing for functional and non-functional characteristics
- A . Component – VI
Integration – IV
System – I
Acceptance – III - B . Component – IV
Integration -I
System – VI
Acceptance – V - C . Component – I
Integration – V
System – II
Acceptance – IV - D . Component – V
Integration – II
System – IV
Acceptance – VI
Correct Answer: D
D
Explanation:
The relationship between impact analysis and regression testing in maintenance testing is that impact analysis is used to evaluate the amount of regression testing to be performed. Maintenance testing is a type of testing that is performed on an existing software product after it has been delivered or deployed, in order to ensure that it still meets its requirements and functions correctly after a change or a modification. Maintenance testing can be triggered by various reasons, such as corrective maintenance (fixing defects), adaptive maintenance (adapting to new environments), perfective maintenance (improving performance), preventive maintenance (avoiding future problems), etc. Impact analysis is a technique that is used to assess the extent and nature of changes introduced by maintenance activities on the software product or project. Impact analysis helps to identify which parts of the software product are affected by the changes, which parts need to be modified or updated accordingly, which parts need to be retested or verified for correctness or compatibility, etc. Regression testing is a type of testing that verifies that previously tested software still performs correctly after a change or a modification. Regression testing helps to detect any side effects or unintended consequences of maintenance activities on the software product’s functionality or quality. Regression testing can be performed at various levels and scopes depending on the impact analysis results. Therefore, in maintenance testing, impact analysis is used to evaluate the amount of regression testing to be performed.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 20.
D
Explanation:
The relationship between impact analysis and regression testing in maintenance testing is that impact analysis is used to evaluate the amount of regression testing to be performed. Maintenance testing is a type of testing that is performed on an existing software product after it has been delivered or deployed, in order to ensure that it still meets its requirements and functions correctly after a change or a modification. Maintenance testing can be triggered by various reasons, such as corrective maintenance (fixing defects), adaptive maintenance (adapting to new environments), perfective maintenance (improving performance), preventive maintenance (avoiding future problems), etc. Impact analysis is a technique that is used to assess the extent and nature of changes introduced by maintenance activities on the software product or project. Impact analysis helps to identify which parts of the software product are affected by the changes, which parts need to be modified or updated accordingly, which parts need to be retested or verified for correctness or compatibility, etc. Regression testing is a type of testing that verifies that previously tested software still performs correctly after a change or a modification. Regression testing helps to detect any side effects or unintended consequences of maintenance activities on the software product’s functionality or quality. Regression testing can be performed at various levels and scopes depending on the impact analysis results. Therefore, in maintenance testing, impact analysis is used to evaluate the amount of regression testing to be performed.
Verified Reference: A Study Guide to the ISTQB® Foundation Level 2018 Syllabus – Springer, page 20.
Question #80
Which of the following statements is not correct?
- A . Looking for defects in a system may require Ignoring system details
- B . Identifying defects may be perceived as criticism against product
- C . Looking for defects in system requires professional pessimism and curiosity
- D . Testing is often seen as a destructive activity instead of constructive activity
Correct Answer: A
A
Explanation:
Looking for defects in a system does not require ignoring system details, but rather paying attention to them and understanding how they affect the system’s quality, functionality, and usability. Ignoring system details could lead to missing important defects or testing irrelevant aspects of the system.
Identifying defects may be perceived as criticism against product, especially by the developers or stakeholders who are invested in the product’s success. However, identifying defects is not meant to be a personal attack, but rather a constructive feedback that helps to improve the product and ensure its alignment with the requirements and expectations of the users and clients.
Looking for defects in system requires professional pessimism and curiosity, as testers need to anticipate and explore the possible ways that the system could fail, malfunction, or behave unexpectedly. Professional pessimism means being skeptical and critical of the system’s quality and reliability, while curiosity means being eager and interested in finding out the root causes and consequences of the defects.
Testing is often seen as a destructive activity instead of constructive activity, as it involves finding and reporting the flaws and weaknesses of the system, rather than creating or enhancing it. However, testing is actually a constructive activity, as it contributes to the system’s improvement, verification, validation, and optimization, and ultimately to the delivery of a high-quality product that meets the needs and expectations of the users and clients.
A
Explanation:
Looking for defects in a system does not require ignoring system details, but rather paying attention to them and understanding how they affect the system’s quality, functionality, and usability. Ignoring system details could lead to missing important defects or testing irrelevant aspects of the system.
Identifying defects may be perceived as criticism against product, especially by the developers or stakeholders who are invested in the product’s success. However, identifying defects is not meant to be a personal attack, but rather a constructive feedback that helps to improve the product and ensure its alignment with the requirements and expectations of the users and clients.
Looking for defects in system requires professional pessimism and curiosity, as testers need to anticipate and explore the possible ways that the system could fail, malfunction, or behave unexpectedly. Professional pessimism means being skeptical and critical of the system’s quality and reliability, while curiosity means being eager and interested in finding out the root causes and consequences of the defects.
Testing is often seen as a destructive activity instead of constructive activity, as it involves finding and reporting the flaws and weaknesses of the system, rather than creating or enhancing it. However, testing is actually a constructive activity, as it contributes to the system’s improvement, verification, validation, and optimization, and ultimately to the delivery of a high-quality product that meets the needs and expectations of the users and clients.
Question #81
Which of the following s the most correct statement about state testing techniques?
- A . Static techniques can be used before all code is ready for execution
- B . Static techniques find more detects then dynamic techniques.
- C . Static techniques can be used by inexperienced users.
- D . Static techniques are always cheaper than dynamic techniques.
Correct Answer: A
A
Explanation:
State testing techniques are a type of dynamic testing techniques that are based on the behavior of the system under test for different input conditions and events. Dynamic testing techniques require the system to be executed with test cases, whereas static testing techniques do not. Static testing techniques can be applied before the code is ready for execution, such as reviews, inspections, walkthroughs, and static analysis. Static testing techniques can help find defects early in the development process, improve the quality of the code, and reduce the cost and effort of dynamic testing.
Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 4, Section 4.2.1, Page 281; ISTQB Glossary of Testing Terms v4.0, Page 292
A
Explanation:
State testing techniques are a type of dynamic testing techniques that are based on the behavior of the system under test for different input conditions and events. Dynamic testing techniques require the system to be executed with test cases, whereas static testing techniques do not. Static testing techniques can be applied before the code is ready for execution, such as reviews, inspections, walkthroughs, and static analysis. Static testing techniques can help find defects early in the development process, improve the quality of the code, and reduce the cost and effort of dynamic testing.
Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 4, Section 4.2.1, Page 281; ISTQB Glossary of Testing Terms v4.0, Page 292
Question #82
A test manager decided to skip static testing since he believes bugs can be found easily by doing dynamic testing. Was this decision right or wrong?
- A . The decision was wrong. Ensuring quality mandates that static testing is performed after performing the dynamic testing.
- B . The decision was right. Static testing is usually redundant if a product is planned to go through a full-cycle of dynamic testing.
- C . The decision was right. Most of the bugs are easier to identify during the dynamic testing.
- D . The decision was wrong. Static testing can find defects early in the development process, reducing the overall cost of testing and development
Correct Answer: D
D
Explanation:
Static testing is a form of testing that does not involve executing the software or system under test. It includes activities such as reviews, inspections, walkthroughs, and analysis of documents, code, and models. Static testing can find defects early in the development process, before they become more expensive and difficult to fix in later stages. Static testing can also improve the quality of the software or system by preventing defects from being introduced in the first place. Static testing can complement dynamic testing, which involves executing the software or system under test and checking the results against expected outcomes. Dynamic testing can find defects that static testing may miss, such as performance, usability, or integration issues. However, dynamic testing alone is not sufficient to ensure quality, as it may not cover all possible scenarios, inputs, or paths. Therefore, a test manager who decides to skip static testing is making a wrong decision, as he or she is ignoring the benefits of static testing and relying solely on dynamic testing, which may not be effective or efficient enough to find and prevent defects.
Reference = ISTQB Certified Tester Foundation Level Syllabus, Version 4.0, 2018, Section 2.1.1, page 14; ISTQB Glossary of Testing Terms, Version 4.0, 2018, page 36; ISTQB CTFL 4.0 – Sample Exam – Answers, Version 1.1, 2023, Question 3, page 9.
D
Explanation:
Static testing is a form of testing that does not involve executing the software or system under test. It includes activities such as reviews, inspections, walkthroughs, and analysis of documents, code, and models. Static testing can find defects early in the development process, before they become more expensive and difficult to fix in later stages. Static testing can also improve the quality of the software or system by preventing defects from being introduced in the first place. Static testing can complement dynamic testing, which involves executing the software or system under test and checking the results against expected outcomes. Dynamic testing can find defects that static testing may miss, such as performance, usability, or integration issues. However, dynamic testing alone is not sufficient to ensure quality, as it may not cover all possible scenarios, inputs, or paths. Therefore, a test manager who decides to skip static testing is making a wrong decision, as he or she is ignoring the benefits of static testing and relying solely on dynamic testing, which may not be effective or efficient enough to find and prevent defects.
Reference = ISTQB Certified Tester Foundation Level Syllabus, Version 4.0, 2018, Section 2.1.1, page 14; ISTQB Glossary of Testing Terms, Version 4.0, 2018, page 36; ISTQB CTFL 4.0 – Sample Exam – Answers, Version 1.1, 2023, Question 3, page 9.
Question #83
In which of the following test documents would you expect to find test exit criteria described9
- A . Test design specification
- B . Project plan
- C . Requirements specification
- D . Test plan
Correct Answer: D
D
Explanation:
Test exit criteria are the conditions that must be fulfilled before concluding a particular testing phase. These criteria act as a checkpoint to assess whether we have achieved the testing objectives and are done with testing1. Test exit criteria are typically defined in the test plan document, which is one of the outputs of the test planning phase. The test plan document describes the scope, approach, resources, and schedule of the testing activities. It also identifies the test items, the features to be tested, the testing tasks, the risks, and the test deliverables2. According to the ISTQB® Certified Tester Foundation Level Syllabus v4.0, the test plan document should include the following information related to the test exit criteria3:
The criteria for evaluating test completion, such as the percentage of test cases executed, the percentage of test coverage achieved, the number and severity of defects found and fixed, the quality and reliability of the software product, and the stakeholder satisfaction.
The criteria for evaluating test process improvement, such as the adherence to the test strategy, the efficiency and effectiveness of the testing activities, the lessons learned and best practices identified, and the recommendations for future improvements.
Therefore, the test plan document is the most appropriate test document to find the test exit criteria described. The other options, such as test design specification, project plan, and requirements specification, are not directly related to the test exit criteria. The test design specification describes the test cases and test procedures for a specific test level or test type3. The project plan describes the overall objectives, scope, assumptions, risks, and deliverables of the software project4. The requirements specification describes the functional and non-functional requirements of the software product5. None of these documents specify the conditions for ending the testing process or evaluating the testing outcomes. Reference = ISTQB® Certified Tester Foundation Level Syllabus
v4.0, Entry and Exit Criteria in Software Testing | Baeldung on Computer Science, Entry And Exit Criteria In Software Testing – Rishabh Software, Entry and Exit Criteria in Software Testing Life Cycle – STLC [2022 Updated] – Testsigma Blog, ISTQB® releases Certified Tester Foundation Level v4.0 (CTFL).
D
Explanation:
Test exit criteria are the conditions that must be fulfilled before concluding a particular testing phase. These criteria act as a checkpoint to assess whether we have achieved the testing objectives and are done with testing1. Test exit criteria are typically defined in the test plan document, which is one of the outputs of the test planning phase. The test plan document describes the scope, approach, resources, and schedule of the testing activities. It also identifies the test items, the features to be tested, the testing tasks, the risks, and the test deliverables2. According to the ISTQB® Certified Tester Foundation Level Syllabus v4.0, the test plan document should include the following information related to the test exit criteria3:
The criteria for evaluating test completion, such as the percentage of test cases executed, the percentage of test coverage achieved, the number and severity of defects found and fixed, the quality and reliability of the software product, and the stakeholder satisfaction.
The criteria for evaluating test process improvement, such as the adherence to the test strategy, the efficiency and effectiveness of the testing activities, the lessons learned and best practices identified, and the recommendations for future improvements.
Therefore, the test plan document is the most appropriate test document to find the test exit criteria described. The other options, such as test design specification, project plan, and requirements specification, are not directly related to the test exit criteria. The test design specification describes the test cases and test procedures for a specific test level or test type3. The project plan describes the overall objectives, scope, assumptions, risks, and deliverables of the software project4. The requirements specification describes the functional and non-functional requirements of the software product5. None of these documents specify the conditions for ending the testing process or evaluating the testing outcomes. Reference = ISTQB® Certified Tester Foundation Level Syllabus
v4.0, Entry and Exit Criteria in Software Testing | Baeldung on Computer Science, Entry And Exit Criteria In Software Testing – Rishabh Software, Entry and Exit Criteria in Software Testing Life Cycle – STLC [2022 Updated] – Testsigma Blog, ISTQB® releases Certified Tester Foundation Level v4.0 (CTFL).
Question #84
The following 4 equivalence classes are given:
Which of the following alternatives includes correct test values for x. based on equivalence partitioning?
- A . -100; 100:1000; 1001
- B . -500; 0; 100; 1000
- C . -99; 99:101; 1001
- D . -1000; -100; 100; 1000
Correct Answer: D
D
Explanation:
The question is about selecting the correct test values for x based on equivalence partitioning.
Equivalence partitioning is a software test design technique that divides the input data of a software unit into partitions of equivalent data from which test cases can be derived.
In this case, the given equivalence classes are:
(x leq -100)
(-100 < x < 100)
(100 leq x < 1000)
(x geq 1000)
Option D provides a value from each of these partitions:
For (x leq -100), it gives -1000.
For (-100 < x < 100), it gives -100 and 100.
For (100 leq x < 1000), it gives 500.
For (x geq 1000), it gives 1500.
So, option D covers all four given equivalence classes with appropriate values.
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 documents available at ISTQB and ASTQB.
1: ISTQB Foundation Level Syllabus 2018, Version 4.0, p. 38
2: ISTQB Foundation Level Syllabus 2018, Version 4.0, p. 39
: ISTQB Foundation Level Syllabus 2018, Version 4.0, p. 40
D
Explanation:
The question is about selecting the correct test values for x based on equivalence partitioning.
Equivalence partitioning is a software test design technique that divides the input data of a software unit into partitions of equivalent data from which test cases can be derived.
In this case, the given equivalence classes are:
(x leq -100)
(-100 < x < 100)
(100 leq x < 1000)
(x geq 1000)
Option D provides a value from each of these partitions:
For (x leq -100), it gives -1000.
For (-100 < x < 100), it gives -100 and 100.
For (100 leq x < 1000), it gives 500.
For (x geq 1000), it gives 1500.
So, option D covers all four given equivalence classes with appropriate values.
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 documents available at ISTQB and ASTQB.
1: ISTQB Foundation Level Syllabus 2018, Version 4.0, p. 38
2: ISTQB Foundation Level Syllabus 2018, Version 4.0, p. 39
: ISTQB Foundation Level Syllabus 2018, Version 4.0, p. 40
Question #85
Which of the following coverage criteria results in the highest coverage for state transition based test cases?
- A . Can’t be determined
- B . Covering all transitions at least once
- C . Covering only start and end states
- D . Covering all states at least once
Correct Answer: B
B
Explanation:
Covering all transitions at least once is the highest coverage criterion for state transition based test cases, because it ensures that every possible change of state is tested at least once. This means that all the events that trigger the transitions, as well as the actions and outputs that result from the transitions, are verified. Covering all transitions at least once also implies covering all states at least once, but not vice versa. Therefore, option D is not the highest coverage criterion. Option C is the lowest coverage criterion, because it only tests the initial and final states of the system or component, without checking the intermediate states or transitions. Option A is incorrect, because the coverage criteria for state transition based test cases can be determined and compared based on the number of transitions and states covered.
Reference = CTFL 4.0 Syllabus, Section 4.2.3, page 49-50.
B
Explanation:
Covering all transitions at least once is the highest coverage criterion for state transition based test cases, because it ensures that every possible change of state is tested at least once. This means that all the events that trigger the transitions, as well as the actions and outputs that result from the transitions, are verified. Covering all transitions at least once also implies covering all states at least once, but not vice versa. Therefore, option D is not the highest coverage criterion. Option C is the lowest coverage criterion, because it only tests the initial and final states of the system or component, without checking the intermediate states or transitions. Option A is incorrect, because the coverage criteria for state transition based test cases can be determined and compared based on the number of transitions and states covered.
Reference = CTFL 4.0 Syllabus, Section 4.2.3, page 49-50.
Question #86
Which of the following lists factors That contribute to PROJECT risks?
- A . skill and staff shortages; problems in defining the right requirements, contractual issues.
- B . skill and staff shortages; software does not perform its intended functions; problems in defining the right requirements.
- C . problems in defining the right requirements; contractual issues; poor software quality characteristics.
- D . poor software quality characteristics; software does not perform its intended functions.
Correct Answer: A
A
Explanation:
Project risks are the uncertainties or threats that may affect the project objectives, such as scope, schedule, cost, and quality. According to the ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus, some of the factors that contribute to project risks are:
Skill and staff shortages: This factor refers to the lack of adequate or qualified human resources to perform the project tasks. This may result in delays, errors, rework, or low productivity. Problems in defining the right requirements: This factor refers to the difficulties or ambiguities in eliciting, analyzing, specifying, validating, or managing the requirements of the project. This may result in misalignment, inconsistencies, gaps, or changes in the requirements, affecting the project scope and quality.
Contractual issues: This factor refers to the challenges or disputes that may arise from the contractual agreements between the project parties, such as clients, suppliers, vendors, or subcontractors. This may result in legal, financial, or ethical risks, affecting the project delivery and satisfaction.
The other options are not correct because they list factors that contribute to PRODUCT risks, not project risks. Product risks are the uncertainties or threats that may affect the quality or functionality of the software product or system.
Some of the factors that contribute to product risks are:
Poor software quality characteristics: This factor refers to the lack of adherence or compliance to the quality attributes or criteria of the software product or system, such as reliability, usability, security, performance, or maintainability. This may result in defects, failures, or dissatisfaction of the users or stakeholders.
Software does not perform its intended functions: This factor refers to the deviation or discrepancy between the expected and actual behavior or output of the software product or system. This may result in errors, faults, or malfunctions of the software product or system.
Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus, Chapter 1: Fundamentals of
Testing, Section 1.5: Risks and Testing, Pages 14-16.
A
Explanation:
Project risks are the uncertainties or threats that may affect the project objectives, such as scope, schedule, cost, and quality. According to the ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus, some of the factors that contribute to project risks are:
Skill and staff shortages: This factor refers to the lack of adequate or qualified human resources to perform the project tasks. This may result in delays, errors, rework, or low productivity. Problems in defining the right requirements: This factor refers to the difficulties or ambiguities in eliciting, analyzing, specifying, validating, or managing the requirements of the project. This may result in misalignment, inconsistencies, gaps, or changes in the requirements, affecting the project scope and quality.
Contractual issues: This factor refers to the challenges or disputes that may arise from the contractual agreements between the project parties, such as clients, suppliers, vendors, or subcontractors. This may result in legal, financial, or ethical risks, affecting the project delivery and satisfaction.
The other options are not correct because they list factors that contribute to PRODUCT risks, not project risks. Product risks are the uncertainties or threats that may affect the quality or functionality of the software product or system.
Some of the factors that contribute to product risks are:
Poor software quality characteristics: This factor refers to the lack of adherence or compliance to the quality attributes or criteria of the software product or system, such as reliability, usability, security, performance, or maintainability. This may result in defects, failures, or dissatisfaction of the users or stakeholders.
Software does not perform its intended functions: This factor refers to the deviation or discrepancy between the expected and actual behavior or output of the software product or system. This may result in errors, faults, or malfunctions of the software product or system.
Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus, Chapter 1: Fundamentals of
Testing, Section 1.5: Risks and Testing, Pages 14-16.
Question #87
Which sequence of stated in the answer choices is correct in accordance with the following figure depicting the life-cycle of a defect?
- A . S0->S1->S2->S3->S5->S1
- B . S0->S1->S2->S3->S5->S1->S2->S3
- C . S0->S1->S2~>S3->S4
- D . S0->S1 ->S2->S3->S5->S3->S4
Correct Answer: D
D
Explanation:
According to the ISTQB Certified Tester Foundation Level (CTFL) v4.0, the life cycle of a defect typically follows a sequence from its discovery to its closure. In the provided figure, it starts with S0 (New), moves to S1 (Assigned), then to S2 (Resolved), followed by S3 (Verified). If the defect is not fixed, it can be Re-opened (S5) and goes back for verification (S3). Once verified, it is Closed (S4).
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Section 1.4.3, Page 17.
D
Explanation:
According to the ISTQB Certified Tester Foundation Level (CTFL) v4.0, the life cycle of a defect typically follows a sequence from its discovery to its closure. In the provided figure, it starts with S0 (New), moves to S1 (Assigned), then to S2 (Resolved), followed by S3 (Verified). If the defect is not fixed, it can be Re-opened (S5) and goes back for verification (S3). Once verified, it is Closed (S4).
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Section 1.4.3, Page 17.
Question #88
A Test Manager conducts risk assessment for a project. One of the identified risks is: The sub-contractor may fail to meet his commitment". If this risk materializes. it will lead to delay in completion of testing required for the current cycle.
Which of the following sentences correctly describes the risk?
- A . It is a product risk since any risk associated with development timeline is a product risk.
- B . It is no longer a risk for the Test Manager since an independent party (the sub-contractor) is now managing it
- C . It is a object risk since successful completion of the object depends on successful and timely completion of the tests
- D . It is a product risk since default on part of the sub-contractor may lead to delay in release of the product
Correct Answer: D
D
Explanation:
A product risk is a risk that affects the quality or timeliness of the software product being developed or tested1. Product risks are related to the requirements, design, implementation, verification, and maintenance of the software product2.
The risk of the sub-contractor failing to meet his commitment is a product risk, as it could cause a delay in the completion of the testing required for the current cycle, which in turn could affect the release date of the product. The release date is an important aspect of the product quality, as it reflects the customer satisfaction and the market competitiveness of the product3.
The other options are not correct because:
D
Explanation:
A product risk is a risk that affects the quality or timeliness of the software product being developed or tested1. Product risks are related to the requirements, design, implementation, verification, and maintenance of the software product2.
The risk of the sub-contractor failing to meet his commitment is a product risk, as it could cause a delay in the completion of the testing required for the current cycle, which in turn could affect the release date of the product. The release date is an important aspect of the product quality, as it reflects the customer satisfaction and the market competitiveness of the product3.
The other options are not correct because:
Question #89
Who of the following has the best knowledge to decide what tests in a test project should be automated?
- A . The developer
- B . The customer
- C . The development manager
- D . The test leader
Correct Answer: D
D
Explanation:
The test leader is the person who is responsible for planning, monitoring, and controlling the test activities and resources in a test project. The test leader should have the best knowledge of the test objectives, scope, risks, resources, schedule, and quality criteria. The test leader should also be aware of the test automation criteria, such as the execution frequency, the test support, the team education, the roles and responsibilities, and the devs and testers collaboration1. Based on these factors, the test leader can decide which tests are suitable for automation and which are not, and prioritize them accordingly. The test leader can also coordinate with the test automation engineers, the developers, and the stakeholders to ensure the alignment of the test automation strategy with the test project goals and expectations. Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 2, Section 2.3.1, Page 152; ISTQB Glossary of Testing Terms v4.0, Page 403; ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 6, Section 6.1.1, Page 514; Top 8 Test Automation Criteria You Need To Fulfill – QAMIND1
D
Explanation:
The test leader is the person who is responsible for planning, monitoring, and controlling the test activities and resources in a test project. The test leader should have the best knowledge of the test objectives, scope, risks, resources, schedule, and quality criteria. The test leader should also be aware of the test automation criteria, such as the execution frequency, the test support, the team education, the roles and responsibilities, and the devs and testers collaboration1. Based on these factors, the test leader can decide which tests are suitable for automation and which are not, and prioritize them accordingly. The test leader can also coordinate with the test automation engineers, the developers, and the stakeholders to ensure the alignment of the test automation strategy with the test project goals and expectations. Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 2, Section 2.3.1, Page 152; ISTQB Glossary of Testing Terms v4.0, Page 403; ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 6, Section 6.1.1, Page 514; Top 8 Test Automation Criteria You Need To Fulfill – QAMIND1
Question #90
Which of the following are the phases of the ISTQB fundamental test process?
- A . Test planning and control, Test analysis and design, Test implementation and execution, Evaluating ex t criteria and reporting. Test closure activities
- B . Test planning, Test analysis and design. Test implementation and control. Checking test coverage and reporting, Test closure activities
- C . Test planning and control, Test specification and design. Test implementation and execution, Evaluating test coverage and reporting, Retesting and regression testing, Test closure activities
- D . Test planning. Test specification and design. Test implementation and execution. Evaluating exit criteria and reporting. Retesting and test closure activities
Correct Answer: A
A
Explanation:
The ISTQB fundamental test process consists of five main phases, as described in the ISTQB Foundation Level Syllabus, Version 4.0, 2018, Section 2.2, page 15:
Test planning and control: This phase involves defining the test objectives, scope, strategy, resources, schedule, risks, and metrics, as well as monitoring and controlling the test activities and results throughout the test process.
Test analysis and design: This phase involves analyzing the test basis (such as requirements, specifications, or user stories) to identify test conditions (such as features, functions, or scenarios) that need to be tested, and designing test cases and test procedures (such as inputs, expected outcomes, and execution steps) to cover the test conditions. This phase also involves evaluating the testability of the test basis and the test items (such as software or system components), and selecting and implementing test techniques (such as equivalence partitioning, boundary value analysis, or state transition testing) to achieve the test objectives and optimize the test coverage and efficiency.
Test implementation and execution: This phase involves preparing the test environment (such as hardware, software, data, or tools) and testware (such as test cases, test procedures, test data, or test scripts) for test execution, and executing the test procedures or scripts according to the test plan and schedule. This phase also involves logging the outcome of test execution, comparing the actual results with the expected results, and reporting any discrepancies as incidents (such as defects, errors, or failures).
Evaluating exit criteria and reporting: This phase involves checking if the planned test activities have been completed and the exit criteria (such as quality, coverage, or risk levels) have been met, and reporting the test results and outcomes to the stakeholders. This phase also involves making recommendations for the release or acceptance decision based on the test results and outcomes, and identifying any residual risks (such as known defects or untested areas) that need to be addressed or mitigated.
Test closure activities: This phase involves finalizing and archiving the testware and test environment for future reuse, and evaluating the test process and the test project against the test objectives and the test plan. This phase also involves identifying any lessons learned and best practices, and communicating the findings and suggestions for improvement to the relevant parties.
Reference = ISTQB Certified Tester Foundation Level Syllabus, Version 4.0, 2018, Section 2.2, page 15; ISTQB Glossary of Testing Terms, Version 4.0, 2018, pages 37-38; ISTQB CTFL 4.0 – Sample Exam –
Answers, Version 1.1, 2023, Question 88, page 32.
A
Explanation:
The ISTQB fundamental test process consists of five main phases, as described in the ISTQB Foundation Level Syllabus, Version 4.0, 2018, Section 2.2, page 15:
Test planning and control: This phase involves defining the test objectives, scope, strategy, resources, schedule, risks, and metrics, as well as monitoring and controlling the test activities and results throughout the test process.
Test analysis and design: This phase involves analyzing the test basis (such as requirements, specifications, or user stories) to identify test conditions (such as features, functions, or scenarios) that need to be tested, and designing test cases and test procedures (such as inputs, expected outcomes, and execution steps) to cover the test conditions. This phase also involves evaluating the testability of the test basis and the test items (such as software or system components), and selecting and implementing test techniques (such as equivalence partitioning, boundary value analysis, or state transition testing) to achieve the test objectives and optimize the test coverage and efficiency.
Test implementation and execution: This phase involves preparing the test environment (such as hardware, software, data, or tools) and testware (such as test cases, test procedures, test data, or test scripts) for test execution, and executing the test procedures or scripts according to the test plan and schedule. This phase also involves logging the outcome of test execution, comparing the actual results with the expected results, and reporting any discrepancies as incidents (such as defects, errors, or failures).
Evaluating exit criteria and reporting: This phase involves checking if the planned test activities have been completed and the exit criteria (such as quality, coverage, or risk levels) have been met, and reporting the test results and outcomes to the stakeholders. This phase also involves making recommendations for the release or acceptance decision based on the test results and outcomes, and identifying any residual risks (such as known defects or untested areas) that need to be addressed or mitigated.
Test closure activities: This phase involves finalizing and archiving the testware and test environment for future reuse, and evaluating the test process and the test project against the test objectives and the test plan. This phase also involves identifying any lessons learned and best practices, and communicating the findings and suggestions for improvement to the relevant parties.
Reference = ISTQB Certified Tester Foundation Level Syllabus, Version 4.0, 2018, Section 2.2, page 15; ISTQB Glossary of Testing Terms, Version 4.0, 2018, pages 37-38; ISTQB CTFL 4.0 – Sample Exam –
Answers, Version 1.1, 2023, Question 88, page 32.
Question #91
Which of the following issues cannot be identified by static analysis tools?
- A . Very low MTBF (Mean Time Between failure)
- B . Potentially endless loops
- C . Referencing a variable with an undefined value
- D . Security vulnerabilities
Correct Answer: A
A
Explanation:
Static analysis tools are software tools that examine the source code of a program without executing it. They can detect various types of issues, such as syntax errors, coding standards violations, security vulnerabilities, and potential bugs12. However, static analysis tools cannot identify issues that depend on the runtime behavior or performance of the program, such as very low MTBF (Mean Time Between failure)3. MTBF is a measure of the reliability of a system or component. It is calculated by dividing the total operating time by the number of failures. MTBF reflects how often a system or component fails during its expected lifetime. Static analysis tools cannot measure MTBF because they do not run the program or observe its failures. MTBF can only be estimated by dynamic testing, which involves executing the program under various conditions and collecting data on its failures4. Therefore, very low MTBF is an issue that cannot be identified by static analysis tools. The other options, such as potentially endless loops, referencing a variable with an undefined value, and security vulnerabilities, are issues that can be identified by static analysis tools. Static analysis tools can detect potentially endless loops by analyzing the control flow and data flow of the program and checking for conditions that may never become false5. Static analysis tools can detect referencing a variable with an undefined value by checking the scope and initialization of variables and reporting any use of uninitialized variables6. Static analysis tools can detect security vulnerabilities by checking for common patterns of insecure code, such as buffer overflows, SQL injections, cross-site scripting, and weak encryption.
Reference = What Is Static Analysis? Static Code Analysis Tools – Perforce Software, How Static Code Analysis Works | Perforce, Static Code Analysis: Techniques, Top 5 Benefits & 3 Challenges, What is MTBF? Mean Time Between Failures Explained | Perforce, Static analysis tools – Software Testing MCQs – CareerRide, ISTQB_Chapter3 | Quizizz, [Static Code Analysis for Security Vulnerabilities | Perforce].
A
Explanation:
Static analysis tools are software tools that examine the source code of a program without executing it. They can detect various types of issues, such as syntax errors, coding standards violations, security vulnerabilities, and potential bugs12. However, static analysis tools cannot identify issues that depend on the runtime behavior or performance of the program, such as very low MTBF (Mean Time Between failure)3. MTBF is a measure of the reliability of a system or component. It is calculated by dividing the total operating time by the number of failures. MTBF reflects how often a system or component fails during its expected lifetime. Static analysis tools cannot measure MTBF because they do not run the program or observe its failures. MTBF can only be estimated by dynamic testing, which involves executing the program under various conditions and collecting data on its failures4. Therefore, very low MTBF is an issue that cannot be identified by static analysis tools. The other options, such as potentially endless loops, referencing a variable with an undefined value, and security vulnerabilities, are issues that can be identified by static analysis tools. Static analysis tools can detect potentially endless loops by analyzing the control flow and data flow of the program and checking for conditions that may never become false5. Static analysis tools can detect referencing a variable with an undefined value by checking the scope and initialization of variables and reporting any use of uninitialized variables6. Static analysis tools can detect security vulnerabilities by checking for common patterns of insecure code, such as buffer overflows, SQL injections, cross-site scripting, and weak encryption.
Reference = What Is Static Analysis? Static Code Analysis Tools – Perforce Software, How Static Code Analysis Works | Perforce, Static Code Analysis: Techniques, Top 5 Benefits & 3 Challenges, What is MTBF? Mean Time Between Failures Explained | Perforce, Static analysis tools – Software Testing MCQs – CareerRide, ISTQB_Chapter3 | Quizizz, [Static Code Analysis for Security Vulnerabilities | Perforce].
Question #92
A company runs a pilot project for evaluation of a test automation tool.
Which of the following is NOT a valid object of this pilot project?
- A . Get familiar with the functionality and options of the tool
- B . Check haw the tool fits to the existing test processes
- C . Train all testers on using the tool
- D . Decide upon standards for tool implementation
Correct Answer: C
C
Explanation:
A pilot project is a small-scale experiment or trial that is conducted to evaluate the feasibility, effectiveness, and suitability of a test automation tool before implementing it on a larger scale1.
The objectives of a pilot project may vary depending on the context and scope of the test automation initiative, but some common ones are2:
To get familiar with the functionality and options of the tool
To check how the tool fits to the existing test processes and environment
To assess the benefits and challenges of using the tool
To decide upon standards and guidelines for tool implementation and usage
To estimate the costs and resources required for tool deployment and maintenance
Therefore, option C is not a valid objective of a pilot project, as it is not necessary to train all testers
on using the tool at this stage. Training all testers on using the tool would be more appropriate after
the tool has been selected and approved for full-scale implementation, and after the standards and
guidelines have been established. Training all testers on using the tool during the pilot project would
be inefficient, costly, and premature, as the tool may not be suitable or effective for the intended purpose, or may be replaced by another tool later.
Reference:
1: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 82
2: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 83
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 84
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 85
C
Explanation:
A pilot project is a small-scale experiment or trial that is conducted to evaluate the feasibility, effectiveness, and suitability of a test automation tool before implementing it on a larger scale1.
The objectives of a pilot project may vary depending on the context and scope of the test automation initiative, but some common ones are2:
To get familiar with the functionality and options of the tool
To check how the tool fits to the existing test processes and environment
To assess the benefits and challenges of using the tool
To decide upon standards and guidelines for tool implementation and usage
To estimate the costs and resources required for tool deployment and maintenance
Therefore, option C is not a valid objective of a pilot project, as it is not necessary to train all testers
on using the tool at this stage. Training all testers on using the tool would be more appropriate after
the tool has been selected and approved for full-scale implementation, and after the standards and
guidelines have been established. Training all testers on using the tool during the pilot project would
be inefficient, costly, and premature, as the tool may not be suitable or effective for the intended purpose, or may be replaced by another tool later.
Reference:
1: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 82
2: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 83
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 84
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 85
Question #93
Which of the following applications will be the MOST suitable for testing by Use Cases
- A . Accuracy and usability of a new Navigation system compared with previous system
- B . A billing system used to calculate monthly charge based or large number of subscribers parameters
- C . The ability of an Anti virus package to detect and quarantine a new threat
- D . Suitability and performance of a Multi media (audio video based) system to a new operating system
Correct Answer: A
A
Explanation:
A new navigation system compared with a previous system is the most suitable application for testing by use cases, because it involves a high level of interaction between the user and the system, and the expected behavior and outcomes of the system are based on the user’s needs and goals. Use cases can help to specify the functional requirements of the new navigation system, such as the ability to enter a destination, select a route, follow the directions, receive alerts, etc. Use cases can also help to compare the accuracy and usability of the new system with the previous system, by defining the success and failure scenarios, the preconditions and postconditions, and the alternative flows of each use case. Use cases can also help to design and execute test cases that cover the main and exceptional paths of each use case, and to verify the satisfaction of the user’s expectations.
The other options are not the most suitable applications for testing by use cases, because they do not involve a high level of interaction between the user and the system, or the expected behavior and outcomes of the system are not based on the user’s needs and goals. A billing system used to calculate monthly charge based on a large number of subscriber parameters is more suitable for testing by data-driven testing, which is a technique for testing the functionality and performance of a system or component by using a large set of input and output data. The ability of an antivirus package to detect and quarantine a new threat is more suitable for testing by exploratory testing, which is a technique for testing the functionality and security of a system or component by using an informal and flexible approach, based on the tester’s experience and intuition. The suitability and performance of a multimedia (audio video based) system to a new operating system is more suitable for testing by compatibility testing, which is a technique for testing the functionality and performance of a system or component by using different hardware, software, or network environments.
Reference = CTFL 4.0 Syllabus, Section 3.1.1, page 28-29; Section 4.1.1, page 44-45; Section 4.2.1, page 47-48.
A
Explanation:
A new navigation system compared with a previous system is the most suitable application for testing by use cases, because it involves a high level of interaction between the user and the system, and the expected behavior and outcomes of the system are based on the user’s needs and goals. Use cases can help to specify the functional requirements of the new navigation system, such as the ability to enter a destination, select a route, follow the directions, receive alerts, etc. Use cases can also help to compare the accuracy and usability of the new system with the previous system, by defining the success and failure scenarios, the preconditions and postconditions, and the alternative flows of each use case. Use cases can also help to design and execute test cases that cover the main and exceptional paths of each use case, and to verify the satisfaction of the user’s expectations.
The other options are not the most suitable applications for testing by use cases, because they do not involve a high level of interaction between the user and the system, or the expected behavior and outcomes of the system are not based on the user’s needs and goals. A billing system used to calculate monthly charge based on a large number of subscriber parameters is more suitable for testing by data-driven testing, which is a technique for testing the functionality and performance of a system or component by using a large set of input and output data. The ability of an antivirus package to detect and quarantine a new threat is more suitable for testing by exploratory testing, which is a technique for testing the functionality and security of a system or component by using an informal and flexible approach, based on the tester’s experience and intuition. The suitability and performance of a multimedia (audio video based) system to a new operating system is more suitable for testing by compatibility testing, which is a technique for testing the functionality and performance of a system or component by using different hardware, software, or network environments.
Reference = CTFL 4.0 Syllabus, Section 3.1.1, page 28-29; Section 4.1.1, page 44-45; Section 4.2.1, page 47-48.
Question #94
A program is used to control a manufacturing line (turn machines on and off. start and stop conveyer belts, add raw materials to the flow. etc.). Not all actions are possible at all times. For example, there are certain manufacturing stages that cannot be stopped – unless there is an emergency. A tester attempts to evaluate if all such cases (where a specific action is not allowed) are covered by the tests.
Which coverage metric will provide the needed information for this analysis?
- A . Code coverage
- B . Data flow coverage
- C . Statement coverage
- D . Branch Coverage
Correct Answer: D
D
Explanation:
Branch coverage is a type of structural coverage metric that measures the percentage of branches or decision outcomes that are executed by the test cases. A branch is a point in the code where the control flow can take two or more alternative paths based on a condition. For example, an if-else statement is a branch that can execute either the if-block or the else-block depending on the evaluation of the condition. Branch coverage ensures that each branch is taken at least once by the test cases, and thus reveals the behavior of the software under different scenarios. Branch coverage is also known as decision coverage or all-edges coverage.
Branch coverage is suitable for testing the cases where a specific action is not allowed, because it can verify that the test cases cover all the possible outcomes of the conditions that determine the action. For example, if the program has a condition that checks if the manufacturing stage can be stopped, then branch coverage can ensure that the test cases cover both the cases where the stage can be stopped and where it cannot be stopped. This way, branch coverage can help identify any missing or incorrect branches that may lead to undesired or unsafe actions.
The other options are not correct because they are not suitable for testing the cases where a specific action is not allowed. Code coverage is a general term that encompasses various types of coverage metrics, such as statement coverage, branch coverage, data flow coverage, etc. Code coverage does not specify which type of coverage metric is used for the analysis. Data flow coverage is a type of structural coverage metric that measures the percentage of data flow paths that are executed by the test cases. A data flow path is a sequence of statements that define, use, or kill a variable. Data flow coverage is useful for testing the correctness and completeness of the data manipulation in the software, but not for testing the conditions that determine the actions. Statement coverage is a type of structural coverage metric that measures the percentage of statements or lines of code that are executed by the test cases. Statement coverage ensures that each statement is executed at least once by the test cases, but it does not reveal the behavior of the software under different scenarios. Statement coverage is a weaker criterion than branch coverage, because it does not account for the branches or decision outcomes in the code. Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus, Chapter 4: Test Techniques, Section 4.3: Structural Testing Techniques, Pages 51-54.
D
Explanation:
Branch coverage is a type of structural coverage metric that measures the percentage of branches or decision outcomes that are executed by the test cases. A branch is a point in the code where the control flow can take two or more alternative paths based on a condition. For example, an if-else statement is a branch that can execute either the if-block or the else-block depending on the evaluation of the condition. Branch coverage ensures that each branch is taken at least once by the test cases, and thus reveals the behavior of the software under different scenarios. Branch coverage is also known as decision coverage or all-edges coverage.
Branch coverage is suitable for testing the cases where a specific action is not allowed, because it can verify that the test cases cover all the possible outcomes of the conditions that determine the action. For example, if the program has a condition that checks if the manufacturing stage can be stopped, then branch coverage can ensure that the test cases cover both the cases where the stage can be stopped and where it cannot be stopped. This way, branch coverage can help identify any missing or incorrect branches that may lead to undesired or unsafe actions.
The other options are not correct because they are not suitable for testing the cases where a specific action is not allowed. Code coverage is a general term that encompasses various types of coverage metrics, such as statement coverage, branch coverage, data flow coverage, etc. Code coverage does not specify which type of coverage metric is used for the analysis. Data flow coverage is a type of structural coverage metric that measures the percentage of data flow paths that are executed by the test cases. A data flow path is a sequence of statements that define, use, or kill a variable. Data flow coverage is useful for testing the correctness and completeness of the data manipulation in the software, but not for testing the conditions that determine the actions. Statement coverage is a type of structural coverage metric that measures the percentage of statements or lines of code that are executed by the test cases. Statement coverage ensures that each statement is executed at least once by the test cases, but it does not reveal the behavior of the software under different scenarios. Statement coverage is a weaker criterion than branch coverage, because it does not account for the branches or decision outcomes in the code. Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus, Chapter 4: Test Techniques, Section 4.3: Structural Testing Techniques, Pages 51-54.
Question #95
What is test oracle?
- A . The source of lest objectives
- B . The source for the actual results
- C . The source of expected results
- D . The source of input conditions
Correct Answer: C
C
Explanation:
A test oracle is a mechanism or principle that can be used to determine whether the observed behavior or output of a system under test is correct or not1. A test oracle can be based on various sources of expected results, such as specifications, user expectations, previous versions, comparable systems, etc2.
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Section 1.2.1, Page 91; ISTQB Glossary of Testing Terms, Version 4.0, Page 332.
C
Explanation:
A test oracle is a mechanism or principle that can be used to determine whether the observed behavior or output of a system under test is correct or not1. A test oracle can be based on various sources of expected results, such as specifications, user expectations, previous versions, comparable systems, etc2.
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Section 1.2.1, Page 91; ISTQB Glossary of Testing Terms, Version 4.0, Page 332.
Question #96
Which ONE of the following statements does NOT describe how testing contributes to higher quality?
- A . Properly designed tests that pass reduce the level of risk in a system.
- B . The testing of software demonstrates the absence of defects.
- C . Software testing identifies defects, which can be used to improve development activities.
- D . Performing a review of the requirement specifications before implementing the system can enhance quality.
Correct Answer: B
B
Explanation:
The testing of software does not demonstrate the absence of defects, but rather the presence of defects or the conformance of the software to the specified requirements1. Testing can never prove that the software is defect-free, as it is impossible to test all possible scenarios, inputs, outputs, and behaviors of the software2. Testing can only provide a level of confidence in the quality of the software, based on the coverage, effectiveness, and efficiency of the testing activities3.
The other options are correct because:
B
Explanation:
The testing of software does not demonstrate the absence of defects, but rather the presence of defects or the conformance of the software to the specified requirements1. Testing can never prove that the software is defect-free, as it is impossible to test all possible scenarios, inputs, outputs, and behaviors of the software2. Testing can only provide a level of confidence in the quality of the software, based on the coverage, effectiveness, and efficiency of the testing activities3.
The other options are correct because:
Question #97
Which of the following statements describes regression testing?
I. Retesting of a fixed defect
II. Testing of an already tested program
III. Testing of new functionality in a program
IV. Regression testing applies only to functional testing
V. Tests that do not nave to be repeatable, because They are only used once
- A . II, IV, V
- B . I, III, IV
- C . II
- D . I, IV
Correct Answer: C
C
Explanation:
Regression testing is the re-running of functional and non-functional tests to ensure that previously developed and tested software still performs as expected after a change1 It does not involve retesting of a fixed defect, testing of new functionality, or applying only to functional testing. Tests that are used for regression testing should be repeatable, because they are used to verify the stability of the software after each change2
Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 4, Section 4.2.2, Page 291; ISTQB Glossary of Testing Terms v4.0, Page 292
C
Explanation:
Regression testing is the re-running of functional and non-functional tests to ensure that previously developed and tested software still performs as expected after a change1 It does not involve retesting of a fixed defect, testing of new functionality, or applying only to functional testing. Tests that are used for regression testing should be repeatable, because they are used to verify the stability of the software after each change2
Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Chapter 4, Section 4.2.2, Page 291; ISTQB Glossary of Testing Terms v4.0, Page 292
Question #98
A calculator software is used to calculate the result for 5+6.
The user noticed that the result given is 6.
This is an example of;
- A . Mistake
- B . Fault
- C . Error
- D . Failure
Correct Answer: D
D
Explanation:
According to the ISTQB Glossary of Testing Terms, Version 4.0, 2018, page 18, a failure is “an event in which a component or system does not perform a required function within specified limits”. In this case, the calculator software does not perform the required function of calculating the correct result for 5+6 within the specified limits of accuracy and precision. Therefore, this is an example of a failure.
The other options are incorrect because:
A mistake is “a human action that produces an incorrect result” (page 25). A mistake is not an event, but an action, and it may or may not lead to a failure. For example, a mistake could be a typo in the code, a wrong assumption in the design, or a misunderstanding of the requirement.
A fault is “a defect in a component or system that can cause the component or system to fail to perform its required function” (page 16). A fault is not an event, but a defect, and it may or may not cause a failure. For example, a fault could be a logical error in the code, a missing specification in the design, or a contradiction in the requirement.
An error is “the difference between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition” (page 15). An error is not an event, but a difference, and it may or may not result in a failure. For example, an error could be a rounding error in the calculation, a measurement error in the observation, or a deviation error in the condition.
Reference = ISTQB Glossary of Testing Terms, Version 4.0, 2018, pages 15-18, 25; ISTQB CTFL 4.0 – Sample Exam – Answers, Version 1.1, 2023, Question 96, page 34.
D
Explanation:
According to the ISTQB Glossary of Testing Terms, Version 4.0, 2018, page 18, a failure is “an event in which a component or system does not perform a required function within specified limits”. In this case, the calculator software does not perform the required function of calculating the correct result for 5+6 within the specified limits of accuracy and precision. Therefore, this is an example of a failure.
The other options are incorrect because:
A mistake is “a human action that produces an incorrect result” (page 25). A mistake is not an event, but an action, and it may or may not lead to a failure. For example, a mistake could be a typo in the code, a wrong assumption in the design, or a misunderstanding of the requirement.
A fault is “a defect in a component or system that can cause the component or system to fail to perform its required function” (page 16). A fault is not an event, but a defect, and it may or may not cause a failure. For example, a fault could be a logical error in the code, a missing specification in the design, or a contradiction in the requirement.
An error is “the difference between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition” (page 15). An error is not an event, but a difference, and it may or may not result in a failure. For example, an error could be a rounding error in the calculation, a measurement error in the observation, or a deviation error in the condition.
Reference = ISTQB Glossary of Testing Terms, Version 4.0, 2018, pages 15-18, 25; ISTQB CTFL 4.0 – Sample Exam – Answers, Version 1.1, 2023, Question 96, page 34.
Question #99
A system has a self-diagnostics module that starts executing after the system is reset. The diagnostics are running 12 different tests on the systems memory hardware.
The following is one of the requirements set for the diagnostics module:
‘The time taking the diagnostics tests to execute shall be less than 2 seconds’
Which of the following is a failure related to the specified requirement?
- A . The diagnostic tests fail to start after a system reset
- B . The diagnostic tests take too much time to execute
- C . The diagnostic tests that measure the speed of the memory, fail
- D . The diagnostic tests fail due to incorrect implementation of the test code
Correct Answer: B
B
Explanation:
A failure is an event in which a component or system does not perform a required function within specified limits1. A requirement is a condition or capability needed by a user to solve a problem or achieve an objective2. In this case, the requirement is that the diagnostics tests should execute in less than 2 seconds. Therefore, any event that violates this requirement is a failure. The only option that clearly violates this requirement is B. The diagnostic tests take too much time to execute. If the diagnostic tests take more than 2 seconds to complete, then they do not meet the specified limit and thus fail. The other options are not necessarily failures related to the specified requirement.
Option A. The diagnostic tests fail to start after a system reset is a failure, but not related to the time limit. It is related to the functionality of the self-diagnostics module.
Option C. The diagnostic tests that measure the speed of the memory, fail is also a failure, but not related to the time limit. It is related to the accuracy of the memory tests.
Option D. The diagnostic tests fail due to incorrect implementation of the test code is also a failure, but not related to the time limit. It is related to the quality of the test code.
Reference = ISTQB® Certified Tester Foundation Level Syllabus v4.0, Requirements Engineering Fundamentals.
B
Explanation:
A failure is an event in which a component or system does not perform a required function within specified limits1. A requirement is a condition or capability needed by a user to solve a problem or achieve an objective2. In this case, the requirement is that the diagnostics tests should execute in less than 2 seconds. Therefore, any event that violates this requirement is a failure. The only option that clearly violates this requirement is B. The diagnostic tests take too much time to execute. If the diagnostic tests take more than 2 seconds to complete, then they do not meet the specified limit and thus fail. The other options are not necessarily failures related to the specified requirement.
Option A. The diagnostic tests fail to start after a system reset is a failure, but not related to the time limit. It is related to the functionality of the self-diagnostics module.
Option C. The diagnostic tests that measure the speed of the memory, fail is also a failure, but not related to the time limit. It is related to the accuracy of the memory tests.
Option D. The diagnostic tests fail due to incorrect implementation of the test code is also a failure, but not related to the time limit. It is related to the quality of the test code.
Reference = ISTQB® Certified Tester Foundation Level Syllabus v4.0, Requirements Engineering Fundamentals.
Question #100
Which of the following statements is an example of testing contributing to higher quality?
- A . A test leader writes a test summary report
- B . A project manager asks to a test leader to estimate the test effort
- C . A tester installs a test ten in the lest environment
- D . A tester finds a bug which is resolved prior to release
Correct Answer: D
D
Explanation:
The question is about identifying an example of testing contributing to higher quality. Quality is the degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations1. Testing is the process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects2.
Therefore, testing contributes to higher quality by verifying and validating that the software products and related work products meet the specified requirements, are fit for purpose and have no defects, or at least have a reduced number of defects. Testing also provides information about the quality of the software products and related work products to the stakeholders, who can make informed decisions based on the test results3.
Out of the four given statements, only option D is an example of testing contributing to higher quality, as it shows that testing has detected a defect (a flaw in a component or system that can cause the component or system to fail to perform its required function4) and that the defect has been resolved (fixed and confirmed) prior to release (delivery of the software product to the customer or end user). This means that testing has prevented a potential failure (an event in which a component or system does not perform a required function within specified limits) from occurring in the operational environment, and thus has improved the quality of the software product.
Option A is not an example of testing contributing to higher quality, as it is a reporting activity that summarizes the test results and evaluates the test objectives, but does not directly affect the quality of the software product or related work products. A test summary report is a document that records and communicates the outcomes of testing activities, including test completion criteria, test results, incident reports, test summary and evaluation, and lessons learned.
Option B is not an example of testing contributing to higher quality, as it is a planning activity that estimates the resources and time needed for testing activities, but does not directly affect the quality of the software product or related work products. A test effort estimate is an approximation of the amount of work and/or the duration of time required to perform testing activities.
Option C is not an example of testing contributing to higher quality, as it is a preparation activity that sets up the test environment (an environment containing hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test), but does not directly affect the quality of the software product or related work products. A test environment installation is a process of installing and configuring the test environment according to the test environment specification.
Reference:
1: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 10
2: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 11
3: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 12
4: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 13
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 13
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 77
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 78
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 79
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 80
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 81
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 82
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 83
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 84
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 85
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 86
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 87
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 88
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 89
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 90
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 91
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 92
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 93
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 94
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 95
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 96
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 97
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 98
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 99
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 100
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 101
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 102
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 103
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 104
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 105
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 106
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 107
D
Explanation:
The question is about identifying an example of testing contributing to higher quality. Quality is the degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations1. Testing is the process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects2.
Therefore, testing contributes to higher quality by verifying and validating that the software products and related work products meet the specified requirements, are fit for purpose and have no defects, or at least have a reduced number of defects. Testing also provides information about the quality of the software products and related work products to the stakeholders, who can make informed decisions based on the test results3.
Out of the four given statements, only option D is an example of testing contributing to higher quality, as it shows that testing has detected a defect (a flaw in a component or system that can cause the component or system to fail to perform its required function4) and that the defect has been resolved (fixed and confirmed) prior to release (delivery of the software product to the customer or end user). This means that testing has prevented a potential failure (an event in which a component or system does not perform a required function within specified limits) from occurring in the operational environment, and thus has improved the quality of the software product.
Option A is not an example of testing contributing to higher quality, as it is a reporting activity that summarizes the test results and evaluates the test objectives, but does not directly affect the quality of the software product or related work products. A test summary report is a document that records and communicates the outcomes of testing activities, including test completion criteria, test results, incident reports, test summary and evaluation, and lessons learned.
Option B is not an example of testing contributing to higher quality, as it is a planning activity that estimates the resources and time needed for testing activities, but does not directly affect the quality of the software product or related work products. A test effort estimate is an approximation of the amount of work and/or the duration of time required to perform testing activities.
Option C is not an example of testing contributing to higher quality, as it is a preparation activity that sets up the test environment (an environment containing hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test), but does not directly affect the quality of the software product or related work products. A test environment installation is a process of installing and configuring the test environment according to the test environment specification.
Reference:
1: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 10
2: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 11
3: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 12
4: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 13
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 13
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 77
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 78
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 79
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 80
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 81
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 82
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 83
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 84
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 85
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 86
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 87
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 88
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 89
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 90
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 91
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 92
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 93
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 94
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 95
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 96
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 97
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 98
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 99
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 100
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 101
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 102
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 103
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 104
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 105
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 106
: ISTQB Certified Tester Foundation Level Syllabus 2018, Version 4.0, p. 107
Question #101
A software company decides to invest in reviews of various types. The thought process they have is that each artifact needs to be reviewed using only one of the review methods depending on the criticality of the artifact.
- A . The thought process is incorrect. The whole company should adopt same standard for review of all artifacts.
- B . The thought process is correct. The whole company should decide or the review method based on their CMM level.
- C . The thought process is incorrect. Same artifact can be reviewed using different review methods
- D . The thought process is correct. It wastes time to review same artifact using efferent review methods
Correct Answer: C
C
Explanation:
The thought process of the software company is incorrect, because it assumes that each artifact can be reviewed using only one review method, and that the review method depends solely on the criticality of the artifact. This is a simplistic and rigid approach that does not consider the benefits and limitations of different review methods, the context and purpose of the review, and the feedback and improvement opportunities that can be gained from multiple reviews. According to the CTFL 4.0 Syllabus, the selection of review methods should be based on several factors, such as the type and level of detail of the artifact, the availability and competence of the reviewers, the time and budget constraints, the expected defects and risks, and the desired outcomes and quality criteria. Moreover, the same artifact can be reviewed using different review methods at different stages of the development lifecycle, to ensure that the artifact meets the changing requirements, standards, and expectations of the stakeholders. For example, a requirement specification can be reviewed using an informal review method, such as a walkthrough, to get an initial feedback from the users and developers, and then using a formal review method, such as an inspection, to verify the completeness, correctness, and consistency of the specification. Therefore, the software company should adopt a more flexible and context-sensitive approach to selecting and applying review methods for different artifacts, rather than following a fixed and arbitrary rule.
Reference = CTFL 4.0 Syllabus, Section 3.2.1, page 31-32; Section 3.2.2, page 33-34; Section 3.2.3, page 35-36.
C
Explanation:
The thought process of the software company is incorrect, because it assumes that each artifact can be reviewed using only one review method, and that the review method depends solely on the criticality of the artifact. This is a simplistic and rigid approach that does not consider the benefits and limitations of different review methods, the context and purpose of the review, and the feedback and improvement opportunities that can be gained from multiple reviews. According to the CTFL 4.0 Syllabus, the selection of review methods should be based on several factors, such as the type and level of detail of the artifact, the availability and competence of the reviewers, the time and budget constraints, the expected defects and risks, and the desired outcomes and quality criteria. Moreover, the same artifact can be reviewed using different review methods at different stages of the development lifecycle, to ensure that the artifact meets the changing requirements, standards, and expectations of the stakeholders. For example, a requirement specification can be reviewed using an informal review method, such as a walkthrough, to get an initial feedback from the users and developers, and then using a formal review method, such as an inspection, to verify the completeness, correctness, and consistency of the specification. Therefore, the software company should adopt a more flexible and context-sensitive approach to selecting and applying review methods for different artifacts, rather than following a fixed and arbitrary rule.
Reference = CTFL 4.0 Syllabus, Section 3.2.1, page 31-32; Section 3.2.2, page 33-34; Section 3.2.3, page 35-36.
Question #102
What type of testing measures its effectiveness by tracking which lines of code were executed by the tests?
- A . Acceptance testing
- B . Structural testing
- C . Integration testing
- D . Exploratory testing
Correct Answer: B
B
Explanation:
Structural testing is a type of testing that measures its effectiveness by tracking which lines of code were executed by the tests. Structural testing, also known as white-box testing or glass-box testing, is based on the internal structure, design, or implementation of the software. Structural testing aims to verify that the software meets the specified quality attributes, such as performance, security, reliability, or maintainability, by exercising the code paths, branches, statements, conditions, or data flows. Structural testing uses various coverage metrics, such as function coverage, line coverage, branch coverage, or statement coverage, to determine how much of the code has been tested and to identify any untested or unreachable parts of the code. Structural testing can be applied at any level of testing, such as unit testing, integration testing, system testing, or acceptance testing, but it is more commonly used at lower levels, where the testers have access to the source code.
The other options are not correct because they are not types of testing that measure their effectiveness by tracking which lines of code were executed by the tests. Acceptance testing is a type of testing that verifies that the software meets the acceptance criteria and the user requirements. Acceptance testing is usually performed by the end-users or customers, who may not have access to the source code or the technical details of the software. Acceptance testing is more concerned with the functionality, usability, or suitability of the software, rather than its internal structure or implementation. Integration testing is a type of testing that verifies that the software components or subsystems work together as expected. Integration testing is usually performed by the developers or testers, who may use both structural and functional testing techniques to check the interfaces, interactions, or dependencies between the components or subsystems. Integration testing is more concerned with the integration logic, data flow, or communication of the software, rather than its individual lines of code. Exploratory testing is a type of testing that involves simultaneous learning, test design, and test execution. Exploratory testing is usually performed by the testers, who use their creativity, intuition, or experience to explore the software and discover any defects, risks, or opportunities for improvement. Exploratory testing is more concerned with the behavior, quality, or value of the software, rather than its internal structure or implementation. Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus, Chapter 4: Test Techniques, Section 4.3: Structural Testing Techniques, Pages 51-54; Chapter 1: Fundamentals of Testing, Section 1.4: Testing Throughout the Software Development Lifecycle, Pages 11-13; Chapter 3: Static Testing, Section 3.4: Exploratory Testing, Pages 40-41.
B
Explanation:
Structural testing is a type of testing that measures its effectiveness by tracking which lines of code were executed by the tests. Structural testing, also known as white-box testing or glass-box testing, is based on the internal structure, design, or implementation of the software. Structural testing aims to verify that the software meets the specified quality attributes, such as performance, security, reliability, or maintainability, by exercising the code paths, branches, statements, conditions, or data flows. Structural testing uses various coverage metrics, such as function coverage, line coverage, branch coverage, or statement coverage, to determine how much of the code has been tested and to identify any untested or unreachable parts of the code. Structural testing can be applied at any level of testing, such as unit testing, integration testing, system testing, or acceptance testing, but it is more commonly used at lower levels, where the testers have access to the source code.
The other options are not correct because they are not types of testing that measure their effectiveness by tracking which lines of code were executed by the tests. Acceptance testing is a type of testing that verifies that the software meets the acceptance criteria and the user requirements. Acceptance testing is usually performed by the end-users or customers, who may not have access to the source code or the technical details of the software. Acceptance testing is more concerned with the functionality, usability, or suitability of the software, rather than its internal structure or implementation. Integration testing is a type of testing that verifies that the software components or subsystems work together as expected. Integration testing is usually performed by the developers or testers, who may use both structural and functional testing techniques to check the interfaces, interactions, or dependencies between the components or subsystems. Integration testing is more concerned with the integration logic, data flow, or communication of the software, rather than its individual lines of code. Exploratory testing is a type of testing that involves simultaneous learning, test design, and test execution. Exploratory testing is usually performed by the testers, who use their creativity, intuition, or experience to explore the software and discover any defects, risks, or opportunities for improvement. Exploratory testing is more concerned with the behavior, quality, or value of the software, rather than its internal structure or implementation. Reference = ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus, Chapter 4: Test Techniques, Section 4.3: Structural Testing Techniques, Pages 51-54; Chapter 1: Fundamentals of Testing, Section 1.4: Testing Throughout the Software Development Lifecycle, Pages 11-13; Chapter 3: Static Testing, Section 3.4: Exploratory Testing, Pages 40-41.
Question #103
The following chart represents metrics related to testing of a project that was competed. Indicate what is represented by tie lines A, B and the axes X.Y
A)
B)
C)
D)
- A . Option A
- B . Option B
- C . Option C
- D . Option D
Correct Answer: D
D
Explanation:
Option D correctly explains what is represented by the lines A, B and the axes X, Y in a testing metrics chart.
According to option D:
X-axis represents Time
Y-axis represents Count
Line A represents Number of open bugs
Line B represents Total number of executed tests
This information is essential in understanding and analyzing the testing metrics of a completed project.
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Section 2.5.1, Page 35.
D
Explanation:
Option D correctly explains what is represented by the lines A, B and the axes X, Y in a testing metrics chart.
According to option D:
X-axis represents Time
Y-axis represents Count
Line A represents Number of open bugs
Line B represents Total number of executed tests
This information is essential in understanding and analyzing the testing metrics of a completed project.
Reference: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Section 2.5.1, Page 35.