Question #1
Which of the following errors CANNOT be found with structure-based testing techniques?
- A . Memory is leaking
- B . Features are only partially implemented
- C . Data structures that are used before initialization
- D . Division by zero
Correct Answer: A
A
Explanation:
Memory leaks are errors that occur when a program does not release memory that it has allocated, causing the system to run out of memory and slow down or crash. Memory leaks cannot be detected by structure-based testing techniques, which are based on the code structure and logic. Structure-based testing techniques can only find errors that are related to the control flow, data flow, or logic of the program. For example, they can find errors such as features that are only partially implemented, data structures that are used before initialization, or division by zero. To detect memory leaks, you need dynamic analysis tools that monitor the memory usage of the program during execution. You can find more information about structure-based testing techniques and dynamic analysis tools in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 4, Sections 4.2 and 4.31.
A
Explanation:
Memory leaks are errors that occur when a program does not release memory that it has allocated, causing the system to run out of memory and slow down or crash. Memory leaks cannot be detected by structure-based testing techniques, which are based on the code structure and logic. Structure-based testing techniques can only find errors that are related to the control flow, data flow, or logic of the program. For example, they can find errors such as features that are only partially implemented, data structures that are used before initialization, or division by zero. To detect memory leaks, you need dynamic analysis tools that monitor the memory usage of the program during execution. You can find more information about structure-based testing techniques and dynamic analysis tools in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 4, Sections 4.2 and 4.31.
Question #2
Which of the following is correct?
- A . Intrusive test tools are tools that do not exhibit the probe-effect
- B . Testing tools can be used by both developers and testers
- C . Use of testing tools is effective only when done as part of a test automation system
- D . Testing tools allow developers do testing Use of such tools changes the role of the test team
Correct Answer: B
B
Explanation:
Testing tools can be used by both developers and testers for different purposes and at different stages of the software development life cycle. For example, developers can use tools such as unit testing frameworks, code coverage tools, debugging tools, static analysis tools, etc., to improve the quality of their code and find defects early. Testers can use tools such as test management tools, test design tools, test execution tools, test data preparation tools, performance testing tools, etc., to support their testing activities and increase their efficiency and effectiveness. The use of testing tools does not necessarily imply test automation, which is the use of software to perform or support test activities that would otherwise require manual intervention. Test automation is a complex and costly process that requires careful planning, design, implementation, maintenance, and evaluation. The use of testing tools also does not change the role of the test team, which is still responsible for defining the test strategy, designing the test cases, analyzing the test results, reporting the defects, etc. You can find more information about testing tools and test automation in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 61.
B
Explanation:
Testing tools can be used by both developers and testers for different purposes and at different stages of the software development life cycle. For example, developers can use tools such as unit testing frameworks, code coverage tools, debugging tools, static analysis tools, etc., to improve the quality of their code and find defects early. Testers can use tools such as test management tools, test design tools, test execution tools, test data preparation tools, performance testing tools, etc., to support their testing activities and increase their efficiency and effectiveness. The use of testing tools does not necessarily imply test automation, which is the use of software to perform or support test activities that would otherwise require manual intervention. Test automation is a complex and costly process that requires careful planning, design, implementation, maintenance, and evaluation. The use of testing tools also does not change the role of the test team, which is still responsible for defining the test strategy, designing the test cases, analyzing the test results, reporting the defects, etc. You can find more information about testing tools and test automation in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 61.
Question #3
The following sentences refer to the Standard for Software Test Documentation’ specification (IEEE 829).
Which sentence is correct?
- A . The key to high quality test documentation regimes is strict adherence to this standard
- B . Any deviation from this standard should be approved by management, marketing & development
- C . This test plan outline is relevant for military projects For consumer market projects there is a different specification with fewer items
- D . Most test documentation regimes follow this spec to some degree, with changes done to fit a specific situation or organization
Correct Answer: D
D
Explanation:
The ‘Standard for Software Test Documentation’ specification (IEEE 829) is a standard that defines a set of documents that can be used to document the test process and its outcomes. The standard provides an outline for each document, specifying its purpose, content, and format. However, the standard does not prescribe how to apply it in different contexts or projects. It is up to each organization or project to decide how to adapt the standard to their specific needs and situation. Therefore, the standard is not a rigid or mandatory requirement that must be followed strictly by all testers. Rather, it is a flexible and adaptable guideline that can be used as a reference or a starting point for creating test documentation regimes. You can find more information about IEEE 829 and test documentation in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 51.
D
Explanation:
The ‘Standard for Software Test Documentation’ specification (IEEE 829) is a standard that defines a set of documents that can be used to document the test process and its outcomes. The standard provides an outline for each document, specifying its purpose, content, and format. However, the standard does not prescribe how to apply it in different contexts or projects. It is up to each organization or project to decide how to adapt the standard to their specific needs and situation. Therefore, the standard is not a rigid or mandatory requirement that must be followed strictly by all testers. Rather, it is a flexible and adaptable guideline that can be used as a reference or a starting point for creating test documentation regimes. You can find more information about IEEE 829 and test documentation in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 51.
Question #4
A software company adopts the V-model as their development life cycle.
Which of the following contains roles of a tester in this company?
- A . Decide what should be automated, to what degree, and how.
- B . Review test plans and set up test environments.
- C . Coordinate the test strategy with the project managers
- D . Introduce suitable metrics to measure the testing progress
Correct Answer: C
C
Explanation:
The V-model is a development life cycle model that shows the relationship between each phase of development and its corresponding phase of testing. In this model, each level of testing (unit testing, integration testing, system testing, acceptance testing) has a corresponding level of development (component design, component integration, system design, requirements analysis). The model also shows that testing activities should start as early as possible in the development process and that each level of testing should be planned and designed in parallel with its corresponding level of development. Therefore, one of the roles of a tester in a software company that adopts the V-model is to coordinate the test strategy with the project managers who are responsible for planning and managing each phase of development. This role involves defining the scope, objectives, approach, resources, schedule, risks, and deliverables of each level of testing in alignment with the development plan and the project requirements. You can find more information about the V-model and test planning in Software Testing Foundations: A Study Guide for the Certified Tester Exam, Chapter 22.
C
Explanation:
The V-model is a development life cycle model that shows the relationship between each phase of development and its corresponding phase of testing. In this model, each level of testing (unit testing, integration testing, system testing, acceptance testing) has a corresponding level of development (component design, component integration, system design, requirements analysis). The model also shows that testing activities should start as early as possible in the development process and that each level of testing should be planned and designed in parallel with its corresponding level of development. Therefore, one of the roles of a tester in a software company that adopts the V-model is to coordinate the test strategy with the project managers who are responsible for planning and managing each phase of development. This role involves defining the scope, objectives, approach, resources, schedule, risks, and deliverables of each level of testing in alignment with the development plan and the project requirements. You can find more information about the V-model and test planning in Software Testing Foundations: A Study Guide for the Certified Tester Exam, Chapter 22.
Question #5
Which of the following is an appropriate reason for maintenance testing?
- A . Bugs found in the field after upgrading the operation system
- B . Bugs found during system testing
- C . Bugs found during unit testing
- D . Bugs found during integration testing
Correct Answer: A
A
Explanation:
Maintenance testing is a type of testing that is performed after a software product has been delivered and deployed to ensure that it still meets its requirements and functions correctly after changes have been made to it or to its environment. Changes can include corrective changes (fixing defects), adaptive changes (adapting to new platforms or environments), perfective changes (improving performance or usability), or preventive changes (avoiding potential problems). One of the appropriate reasons for maintenance testing is to verify that the software product works as expected after upgrading the operating system, which is an example of an adaptive change. Other reasons for maintenance testing can include verifying that the software product works as expected after fixing defects, adding new features, improving performance, or preventing future issues. You can find more information about maintenance testing in Software Testing Foundations: A Study Guide for the Certified Tester Exam, Chapter 12.
A
Explanation:
Maintenance testing is a type of testing that is performed after a software product has been delivered and deployed to ensure that it still meets its requirements and functions correctly after changes have been made to it or to its environment. Changes can include corrective changes (fixing defects), adaptive changes (adapting to new platforms or environments), perfective changes (improving performance or usability), or preventive changes (avoiding potential problems). One of the appropriate reasons for maintenance testing is to verify that the software product works as expected after upgrading the operating system, which is an example of an adaptive change. Other reasons for maintenance testing can include verifying that the software product works as expected after fixing defects, adding new features, improving performance, or preventing future issues. You can find more information about maintenance testing in Software Testing Foundations: A Study Guide for the Certified Tester Exam, Chapter 12.
Question #6
Once a bug is fixed, it should be retested.
What is the term used to define this type of testing?
- A . Reliability Testing
- B . Confirmation Testing
- C . Maintainability Testing
- D . Regression Testing
Correct Answer: B
B
Explanation:
Confirmation testing, also known as re-testing, is the process of testing a defect that has been fixed to verify that it has been resolved and does not affect other parts of the system. Confirmation testing is usually done by the same tester who reported the defect and using the same test case that revealed the defect. You can find more information about confirmation testing in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 3, Section 3.21.
B
Explanation:
Confirmation testing, also known as re-testing, is the process of testing a defect that has been fixed to verify that it has been resolved and does not affect other parts of the system. Confirmation testing is usually done by the same tester who reported the defect and using the same test case that revealed the defect. You can find more information about confirmation testing in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 3, Section 3.21.
Question #7
What is the difference between system integration testing and acceptance testing?
- A . System integration testing is testing non-functional requirements Acceptance testing concentrates on the functionality of the system
- B . System integration testing is executed by the developers. Acceptance testing is done by the customer
- C . System integration testing verifies that a system interfaces correctly with other systems.
Acceptance testing verifies compliance to requirements - D . System integration testing verifies compliance to requirements Acceptance testing verifies correct interaction with other systems existing in the user’s environment
Correct Answer: C
C
Explanation:
System integration testing and acceptance testing are two different levels of testing that have different objectives and stakeholders. System integration testing is the process of testing the interactions and interfaces between different components or systems that form a larger system. System integration testing verifies that the system meets its functional and non-functional requirements and works as expected in its intended environment. System integration testing is usually done by testers or developers who have access to the system architecture and design specifications. Acceptance testing is the process of testing the system by the end users or customers to determine if it satisfies their needs and expectations and is ready for deployment or delivery. Acceptance testing verifies that the system complies with the user requirements and business processes and provides value to the stakeholders. Acceptance testing is usually done by users or customers who have access to the user requirements and business scenarios. You can find more information about system integration testing and acceptance testing in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 2, Sections 2.2 and 2.31.
C
Explanation:
System integration testing and acceptance testing are two different levels of testing that have different objectives and stakeholders. System integration testing is the process of testing the interactions and interfaces between different components or systems that form a larger system. System integration testing verifies that the system meets its functional and non-functional requirements and works as expected in its intended environment. System integration testing is usually done by testers or developers who have access to the system architecture and design specifications. Acceptance testing is the process of testing the system by the end users or customers to determine if it satisfies their needs and expectations and is ready for deployment or delivery. Acceptance testing verifies that the system complies with the user requirements and business processes and provides value to the stakeholders. Acceptance testing is usually done by users or customers who have access to the user requirements and business scenarios. You can find more information about system integration testing and acceptance testing in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 2, Sections 2.2 and 2.31.
Question #8
Which of the following is NOT an example of a common test metric?
- A . Percentage of work done in test environment creation
- B . Average number of expected defects per requirement
- C . Number of test cases run
- D . Deviation from test milestone dates
Correct Answer: B
B
Explanation:
Test metrics are quantitative measures that are used to monitor, control, and improve the test process and its outcomes. Test metrics can be collected at different levels of testing (test case, test suite, test project, etc.) and can be used for different purposes (planning, estimation, execution, evaluation, etc.).
Some examples of common test metrics are:
Percentage of work done in test environment creation: This metric indicates how much effort has been spent on setting up and maintaining the test environment, which includes hardware, software, network, data, tools, etc., that are required for conducting the test activities.
Number of test cases run: This metric indicates how many test cases have been executed during a given period or phase of testing.
Deviation from test milestone dates: This metric indicates how much delay or ahead of schedule the test activities are compared to the planned dates.
Defect density: This metric indicates how many defects have been found per unit of size or functionality of the system under test.
Average number of expected defects per requirement is not a common test metric because it is not easy to estimate or measure how many defects are likely to be found for each requirement. Moreover, this metric does not provide useful information for improving the test process or evaluating the test results. You can find more information about test metrics in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 5, Section 5.41.
B
Explanation:
Test metrics are quantitative measures that are used to monitor, control, and improve the test process and its outcomes. Test metrics can be collected at different levels of testing (test case, test suite, test project, etc.) and can be used for different purposes (planning, estimation, execution, evaluation, etc.).
Some examples of common test metrics are:
Percentage of work done in test environment creation: This metric indicates how much effort has been spent on setting up and maintaining the test environment, which includes hardware, software, network, data, tools, etc., that are required for conducting the test activities.
Number of test cases run: This metric indicates how many test cases have been executed during a given period or phase of testing.
Deviation from test milestone dates: This metric indicates how much delay or ahead of schedule the test activities are compared to the planned dates.
Defect density: This metric indicates how many defects have been found per unit of size or functionality of the system under test.
Average number of expected defects per requirement is not a common test metric because it is not easy to estimate or measure how many defects are likely to be found for each requirement. Moreover, this metric does not provide useful information for improving the test process or evaluating the test results. You can find more information about test metrics in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 5, Section 5.41.
Question #9
Which of the following is NOT a deciding factor in determining the extent of testing required?
- A . Budget to do testing
- B . A particular tester involved in testing
- C . Level of risk of the product or features
- D . Time available to do testing
Correct Answer: B
B
Explanation:
The extent of testing required for a software product or feature depends on several factors that influence the level of quality and risk involved in delivering or deploying it. Some of these factors are: Budget to do testing: This factor indicates how much money is available or allocated for conducting the test activities, which affects the scope, depth, duration, and resources of testing.
Time available to do testing: This factor indicates how much time is available or allocated for conducting the test activities, which affects the schedule, frequency, speed, and coverage of testing. Level of risk of the product or feature: This factor indicates how much impact or harm a failure or defect in the product or feature can cause to the users, customers, stakeholders, or environment, which affects the priority, intensity, complexity, and rigor of testing.
Complexity of the product or feature: This factor indicates how difficult or challenging it is to understand, design, implement, or maintain the product or feature, which affects the effort, skill, technique, and tool required for testing.
A particular tester involved in testing is not a deciding factor in determining the extent of testing required because it does not affect the quality or risk level of the product or feature being tested. Rather, it is an outcome or consequence of deciding how much testing is needed based on other factors such as budget, time, risk, and complexity. You can find more information about determining the extent of testing in Software Testing Foundations: A Study Guide for the Certified Tester Exam, Chapter 2, Section 2.12.
B
Explanation:
The extent of testing required for a software product or feature depends on several factors that influence the level of quality and risk involved in delivering or deploying it. Some of these factors are: Budget to do testing: This factor indicates how much money is available or allocated for conducting the test activities, which affects the scope, depth, duration, and resources of testing.
Time available to do testing: This factor indicates how much time is available or allocated for conducting the test activities, which affects the schedule, frequency, speed, and coverage of testing. Level of risk of the product or feature: This factor indicates how much impact or harm a failure or defect in the product or feature can cause to the users, customers, stakeholders, or environment, which affects the priority, intensity, complexity, and rigor of testing.
Complexity of the product or feature: This factor indicates how difficult or challenging it is to understand, design, implement, or maintain the product or feature, which affects the effort, skill, technique, and tool required for testing.
A particular tester involved in testing is not a deciding factor in determining the extent of testing required because it does not affect the quality or risk level of the product or feature being tested. Rather, it is an outcome or consequence of deciding how much testing is needed based on other factors such as budget, time, risk, and complexity. You can find more information about determining the extent of testing in Software Testing Foundations: A Study Guide for the Certified Tester Exam, Chapter 2, Section 2.12.
Question #10
What does the term Pesticide paradox’ refer to?
- A . The phenomena where a piece of code that has a lot of bugs is likely to have more hidden, yet unfound
- B . The decreasing efficiency of debugging when done in code that has many bugs
- C . Reduced effectiveness of test cases that are repeated and focused on the same scenarios
- D . The redundancy of testing the same objects in both black and white box techniques
Correct Answer: C
C
Explanation:
The term ‘Pesticide paradox’ refers to the phenomenon where the effectiveness of test cases that are repeated and focused on the same scenarios decreases over time because they tend to find the same defects or no defects at all. This is because the system under test becomes more resistant or immune to the existing test cases, just like pests become more resistant or immune to pesticides over time. To overcome the pesticide paradox, test cases should be regularly reviewed and updated to cover new or changed requirements, scenarios, risks, or defects. Test cases should also be designed to cover different aspects and perspectives of the system under test, such as functionality, usability, performance, security, etc. You can find more information about the pesticide paradox in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 4, Section 4.11.
C
Explanation:
The term ‘Pesticide paradox’ refers to the phenomenon where the effectiveness of test cases that are repeated and focused on the same scenarios decreases over time because they tend to find the same defects or no defects at all. This is because the system under test becomes more resistant or immune to the existing test cases, just like pests become more resistant or immune to pesticides over time. To overcome the pesticide paradox, test cases should be regularly reviewed and updated to cover new or changed requirements, scenarios, risks, or defects. Test cases should also be designed to cover different aspects and perspectives of the system under test, such as functionality, usability, performance, security, etc. You can find more information about the pesticide paradox in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 4, Section 4.11.
Question #11
Which of the following test techniques is structure-based?
- A . Control flow testing
- B . Use case testing
- C . State transition testing
- D . Decision table testing
Correct Answer: A
A
Explanation:
Test techniques are methods or procedures that can be used to design, execute, or evaluate test cases. Test techniques can be classified into two categories: specification-based and structure-based. Specification-based test techniques, also known as black-box test techniques, are based on the requirements, specifications, or expectations of the system under test. They do not require any knowledge of the internal structure or implementation of the system. Some examples of specification-based test techniques are use case testing, state transition testing, decision table testing, etc. Structure-based test techniques, also known as white-box test techniques, are based on the code, architecture, or design of the system under test. They require some knowledge of the internal structure or implementation of the system. Some examples of structure-based test techniques are control flow testing, data flow testing, branch testing, statement testing, etc. You can find more information about test techniques in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 41.
A
Explanation:
Test techniques are methods or procedures that can be used to design, execute, or evaluate test cases. Test techniques can be classified into two categories: specification-based and structure-based. Specification-based test techniques, also known as black-box test techniques, are based on the requirements, specifications, or expectations of the system under test. They do not require any knowledge of the internal structure or implementation of the system. Some examples of specification-based test techniques are use case testing, state transition testing, decision table testing, etc. Structure-based test techniques, also known as white-box test techniques, are based on the code, architecture, or design of the system under test. They require some knowledge of the internal structure or implementation of the system. Some examples of structure-based test techniques are control flow testing, data flow testing, branch testing, statement testing, etc. You can find more information about test techniques in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 41.
Question #12
Which of the following test types is a part of the V-Model?
- A . Black-box testing
- B . White-box testing
- C . Experience-based testing
- D . Component testing
Correct Answer: D
D
Explanation:
Component testing is a part of the V-Model, which is a development life cycle model that shows the relationship between each phase of development and its corresponding phase of testing. In this model, each level of testing (unit testing, integration testing, system testing, acceptance testing) has a corresponding level of development (component design, component integration, system design, requirements analysis). Component testing is the process of testing individual components or units of software in isolation from other components or systems. Component testing verifies that the components meet their functional and non-functional requirements and work as expected in their intended environment. Component testing is usually done by developers who have access to the component design and code specifications. You can find more information about component testing and the V-Model in Software Testing Foundations: A Study Guide for the Certified Tester Exam, Chapter 22.
D
Explanation:
Component testing is a part of the V-Model, which is a development life cycle model that shows the relationship between each phase of development and its corresponding phase of testing. In this model, each level of testing (unit testing, integration testing, system testing, acceptance testing) has a corresponding level of development (component design, component integration, system design, requirements analysis). Component testing is the process of testing individual components or units of software in isolation from other components or systems. Component testing verifies that the components meet their functional and non-functional requirements and work as expected in their intended environment. Component testing is usually done by developers who have access to the component design and code specifications. You can find more information about component testing and the V-Model in Software Testing Foundations: A Study Guide for the Certified Tester Exam, Chapter 22.
Question #13
Which of the following statements is correct?
- A . Pair programming is done with developer and tester pairing together
- B . Pair programming is an alternative term for code inspection.
- C . Pair programming is used usually in waterfall model
- D . Pair programming is, among other things, an informal review method.
Correct Answer: D
D
Explanation:
Pair programming is a software development technique where two programmers work together on the same code at the same workstation. One programmer, called the driver, writes the code while the other programmer, called the navigator, reviews the code and provides feedback and suggestions. Pair programming is not only a coding technique but also an informal review method because it involves constant communication and collaboration between the programmers who check each other’s work and share their knowledge and skills. Pair programming can improve the quality and productivity of software development by reducing defects, increasing code readability, enhancing learning opportunities, and fostering creativity and innovation. Pair programming is usually used in agile methods such as Extreme Programming (XP), Scrum, or Kanban. It is not an alternative term for code inspection, which is a formal review method where a group of reviewers examine a piece of code in a structured and systematic way following predefined rules and roles. It is also not done with developer and tester pairing together because pair programming requires both programmers to have similar levels of expertise and familiarity with the code they are working on. You can find more information about pair programming in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 31.
D
Explanation:
Pair programming is a software development technique where two programmers work together on the same code at the same workstation. One programmer, called the driver, writes the code while the other programmer, called the navigator, reviews the code and provides feedback and suggestions. Pair programming is not only a coding technique but also an informal review method because it involves constant communication and collaboration between the programmers who check each other’s work and share their knowledge and skills. Pair programming can improve the quality and productivity of software development by reducing defects, increasing code readability, enhancing learning opportunities, and fostering creativity and innovation. Pair programming is usually used in agile methods such as Extreme Programming (XP), Scrum, or Kanban. It is not an alternative term for code inspection, which is a formal review method where a group of reviewers examine a piece of code in a structured and systematic way following predefined rules and roles. It is also not done with developer and tester pairing together because pair programming requires both programmers to have similar levels of expertise and familiarity with the code they are working on. You can find more information about pair programming in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 31.
Question #14
In foundation level syllabus you will find the main basic principles of testing, which of the following sentences describes one of these basic principles?
- A . Complete testing of software is attainable if you have enough resources and test tools
- B . For a software system, it is not possible under normal conditions, to test all input and output combinations.
- C . A goal of testing is to show that the software is defect free
- D . With automated testing you can make statements with more confidence about the quality of a product than with manual testing.
Correct Answer: B
B
Explanation:
One of the basic principles of testing is that for a software system, it is not possible under normal conditions to test all input and output combinations because they are too many and too complex to cover within a reasonable time and budget. Therefore, testers have to select a subset of inputs and outputs that are representative and relevant for testing based on criteria such as requirements, risks, priorities, etc. This principle implies that testing cannot prove that a software system is defect-free or has a certain level of quality because there might be some untested inputs or outputs that could reveal defects or failures. Testing can only provide information about the quality and risk level of a software system based on the observed behavior and results under certain conditions and assumptions. You can find more information about the basic principles of testing in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 11.
B
Explanation:
One of the basic principles of testing is that for a software system, it is not possible under normal conditions to test all input and output combinations because they are too many and too complex to cover within a reasonable time and budget. Therefore, testers have to select a subset of inputs and outputs that are representative and relevant for testing based on criteria such as requirements, risks, priorities, etc. This principle implies that testing cannot prove that a software system is defect-free or has a certain level of quality because there might be some untested inputs or outputs that could reveal defects or failures. Testing can only provide information about the quality and risk level of a software system based on the observed behavior and results under certain conditions and assumptions. You can find more information about the basic principles of testing in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 11.
Question #15
Which of the following is an example of black-box dynamic testing?
- A . Code inspection
- B . Checking memory leaks for a program by executing it
- C . Functional Testing
- D . Coverage analysis
Correct Answer: C
C
Explanation:
Functional testing is an example of black-box dynamic testing. Functional testing is the process of testing the functionality or behavior of a software system based on its requirements or specifications. Functional testing does not require any knowledge of the internal structure or implementation of the system under test; it only focuses on what the system does rather than how it does it. Functional testing is also an example of dynamic testing because it involves executing the software system with selected inputs and observing its outputs and effects on the environment. Dynamic testing is different from static testing, which involves examining the software system without executing it, such as code inspection, static analysis, etc. You can find more information about functional testing and dynamic testing in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 21.
C
Explanation:
Functional testing is an example of black-box dynamic testing. Functional testing is the process of testing the functionality or behavior of a software system based on its requirements or specifications. Functional testing does not require any knowledge of the internal structure or implementation of the system under test; it only focuses on what the system does rather than how it does it. Functional testing is also an example of dynamic testing because it involves executing the software system with selected inputs and observing its outputs and effects on the environment. Dynamic testing is different from static testing, which involves examining the software system without executing it, such as code inspection, static analysis, etc. You can find more information about functional testing and dynamic testing in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 21.
Question #16
Where and by whom is Beta testing normally performed?
- A . By customers or potential customers at their own locations
- B . By an independent test team at the developing organization’s location
- C . At the developing organization’s site, but not by the developing team
- D . By customers or potential customers at the developing organization’s site
Correct Answer: A
A
Explanation:
Beta testing is a type of acceptance testing that is normally performed by customers or potential customers at their own locations. Beta testing is done after the software product has passed the internal testing and quality assurance processes and is ready for release or deployment. Beta testing allows the customers or users to evaluate the software product in their real environment and provide feedback and suggestions for improvement. Beta testing can also help identify defects, compatibility issues, usability problems, or performance bottlenecks that might not have been detected during the internal testing. You can find more information about beta testing in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 2, Section 2.3.
A
Explanation:
Beta testing is a type of acceptance testing that is normally performed by customers or potential customers at their own locations. Beta testing is done after the software product has passed the internal testing and quality assurance processes and is ready for release or deployment. Beta testing allows the customers or users to evaluate the software product in their real environment and provide feedback and suggestions for improvement. Beta testing can also help identify defects, compatibility issues, usability problems, or performance bottlenecks that might not have been detected during the internal testing. You can find more information about beta testing in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 2, Section 2.3.
Question #17
Which of the following is NOT an objective of testing?
- A . Finding defects
- B . Providing information for decision-making
- C . Analyzing and removing the cause of failures
- D . Gaining confidence about the level of quality of the software
Correct Answer: C
C
Explanation:
Testing has several objectives that aim to provide information and confidence about the quality and risk level of the software product and to support decision-making and improvement processes.
Some of these objectives are:
Finding defects: Testing is the process of finding defects or failures in the software product that do not meet its requirements or expectations.
Providing information for decision-making: Testing is the process of providing information about the quality and risk level of the software product based on the observed behavior and results under certain conditions and assumptions. This information can help stakeholders make informed decisions about releasing, deploying, accepting, or improving the software product.
Gaining confidence about the level of quality of the software: Testing is the process of gaining confidence that the software product meets its requirements and expectations and provides value to the users and customers.
Analyzing and removing the cause of failures: Testing is not only the process of finding defects but also the process of analyzing and removing the cause of failures that lead to defects. This objective is related to debugging, which is a development activity that involves locating, diagnosing, and fixing errors in the code or design of the software product.
You can find more information about the objectives of testing in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 1, Section 1.2.
C
Explanation:
Testing has several objectives that aim to provide information and confidence about the quality and risk level of the software product and to support decision-making and improvement processes.
Some of these objectives are:
Finding defects: Testing is the process of finding defects or failures in the software product that do not meet its requirements or expectations.
Providing information for decision-making: Testing is the process of providing information about the quality and risk level of the software product based on the observed behavior and results under certain conditions and assumptions. This information can help stakeholders make informed decisions about releasing, deploying, accepting, or improving the software product.
Gaining confidence about the level of quality of the software: Testing is the process of gaining confidence that the software product meets its requirements and expectations and provides value to the users and customers.
Analyzing and removing the cause of failures: Testing is not only the process of finding defects but also the process of analyzing and removing the cause of failures that lead to defects. This objective is related to debugging, which is a development activity that involves locating, diagnosing, and fixing errors in the code or design of the software product.
You can find more information about the objectives of testing in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 1, Section 1.2.
Question #18
Which statement about use case testing is true?
- A . The test cases are designed to find defects in the data flow.
- B . The test cases are designed to find defects in the process flow
- C . The test cases are designed to be used by real users, not by professional testers
- D . The test cases are always designed by customers or end users
Correct Answer: B
B
Explanation:
Use case testing is a specification-based test technique that is based on the use cases or scenarios that describe how users interact with the system under test. Use case testing aims to find defects in the process flow or functionality of the system under test by verifying that it behaves as expected according to the use cases or scenarios. Use case testing does not require any knowledge of the data flow or structure of the system under test; it only focuses on what the system does rather than how it does it. Use case testing can be done by professional testers or real users, depending on the level and purpose of testing. Use case testing can also be designed by customers or end users, developers, testers, analysts, or anyone who has access to the use case specifications or user requirements. You can find more information about use case testing in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.
B
Explanation:
Use case testing is a specification-based test technique that is based on the use cases or scenarios that describe how users interact with the system under test. Use case testing aims to find defects in the process flow or functionality of the system under test by verifying that it behaves as expected according to the use cases or scenarios. Use case testing does not require any knowledge of the data flow or structure of the system under test; it only focuses on what the system does rather than how it does it. Use case testing can be done by professional testers or real users, depending on the level and purpose of testing. Use case testing can also be designed by customers or end users, developers, testers, analysts, or anyone who has access to the use case specifications or user requirements. You can find more information about use case testing in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.
Question #19
When testing a mission critical system a high coverage should be achieved.
Which of the following techniques should be implemented as a structural based coverage technique in order to achieve highest coverage?
- A . multiple condition coverage
- B . decision table
- C . use case testing
- D . statement coverage
Correct Answer: A
A
Explanation:
Multiple condition coverage is a structure-based test technique that aims to achieve a high level of coverage by testing all possible combinations of conditions and outcomes in each decision point of the code or design of the system under test. Multiple condition coverage verifies that each condition in a decision point has an effect on the outcome and that there are no hidden defects or logical errors in the code or design. Multiple condition coverage requires some knowledge of the internal structure or implementation of the system under test; it focuses on how the system does what it does rather than what it does. Multiple condition coverage is one of the most rigorous and complex structure-based test techniques because it can generate a large number of test cases for each decision point, especially if there are many conditions involved. You can find more information about multiple condition coverage in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.3.
A
Explanation:
Multiple condition coverage is a structure-based test technique that aims to achieve a high level of coverage by testing all possible combinations of conditions and outcomes in each decision point of the code or design of the system under test. Multiple condition coverage verifies that each condition in a decision point has an effect on the outcome and that there are no hidden defects or logical errors in the code or design. Multiple condition coverage requires some knowledge of the internal structure or implementation of the system under test; it focuses on how the system does what it does rather than what it does. Multiple condition coverage is one of the most rigorous and complex structure-based test techniques because it can generate a large number of test cases for each decision point, especially if there are many conditions involved. You can find more information about multiple condition coverage in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.3.
Question #20
Which of the following is NOT an example of a typical risk-based testing activity?
- A . The evaluation of a risk-management tools to decide which tool to use for future projects
- B . The focus of testing is shifted to an area in the system where tests find with more defects than expected
- C . Brainstorming sessions are held with a wide variety of stakeholders to identify possible failures in the system
- D . Tests are prioritized to ensure that those associated with critical parts of the system are executed earlier
Correct Answer: A
A
Explanation:
Risk-based testing is an approach to testing that prioritizes and focuses on testing activities based on the level of risk associated with each feature or function of the system under test. Risk-based testing aims to optimize the use of time, resources, and techniques for testing by identifying and addressing the most critical and likely sources of failure or harm in the system under test.
Some examples of typical risk-based testing activities are:
Brainstorming sessions are held with a wide variety of stakeholders to identify possible failures in the system: This activity is part of the risk identification process, which involves gathering information and opinions from different perspectives and sources to discover potential risks in the system under test.
Tests are prioritized to ensure that those associated with critical parts of the system are executed earlier: This activity is part of the risk analysis and evaluation process, which involves assessing the probability and impact of each risk and ranking them according to their severity and importance. The focus of testing is shifted to an area in the system where tests find more defects than expected: This activity is part of the risk mitigation and monitoring process, which involves taking actions to reduce or eliminate the risks and tracking their status and progress.
The evaluation of a risk-management tool to decide which tool to use for future projects is not an example of a typical risk-based testing activity because it is not directly related to testing the system under test based on its risks. Rather, it is an example of a tool selection or evaluation activity, which involves comparing and choosing a tool that can support or enhance the testing process based on criteria such as functionality, usability, reliability, compatibility, cost, etc. You can find more information about risk-based testing in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 3, Section 3.4.
A
Explanation:
Risk-based testing is an approach to testing that prioritizes and focuses on testing activities based on the level of risk associated with each feature or function of the system under test. Risk-based testing aims to optimize the use of time, resources, and techniques for testing by identifying and addressing the most critical and likely sources of failure or harm in the system under test.
Some examples of typical risk-based testing activities are:
Brainstorming sessions are held with a wide variety of stakeholders to identify possible failures in the system: This activity is part of the risk identification process, which involves gathering information and opinions from different perspectives and sources to discover potential risks in the system under test.
Tests are prioritized to ensure that those associated with critical parts of the system are executed earlier: This activity is part of the risk analysis and evaluation process, which involves assessing the probability and impact of each risk and ranking them according to their severity and importance. The focus of testing is shifted to an area in the system where tests find more defects than expected: This activity is part of the risk mitigation and monitoring process, which involves taking actions to reduce or eliminate the risks and tracking their status and progress.
The evaluation of a risk-management tool to decide which tool to use for future projects is not an example of a typical risk-based testing activity because it is not directly related to testing the system under test based on its risks. Rather, it is an example of a tool selection or evaluation activity, which involves comparing and choosing a tool that can support or enhance the testing process based on criteria such as functionality, usability, reliability, compatibility, cost, etc. You can find more information about risk-based testing in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 3, Section 3.4.
Question #21
The following program part is given:
IF (condition A)
then DO B
END IF
How many test cases are necessary in order to achieve 100% statement coverage?
- A . 1
- B . 2
- C . 4
- D . a very high number
Correct Answer: B
B
Explanation:
To achieve 100% statement coverage, you need to execute every statement in the code at least once. In this case, you need two test cases: one where condition A is true and one where condition A is false. This way, you can cover both the DO B statement and the END IF statement. You can find more information about statement coverage in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 4, Section 4.31.
B
Explanation:
To achieve 100% statement coverage, you need to execute every statement in the code at least once. In this case, you need two test cases: one where condition A is true and one where condition A is false. This way, you can cover both the DO B statement and the END IF statement. You can find more information about statement coverage in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 4, Section 4.31.
Question #22
Which of the following tool types is the most useful one for a test manager?
- A . Modeling tool
- B . Static analysis tool
- C . Coverage measurement tool
- D . Defect tracking tool
Correct Answer: D
D
Explanation:
A tool type is a category of tools that have similar features and functions and can be used for similar purposes. A test manager is a person who is responsible for planning, monitoring, controlling, and reporting the test activities and results. A test manager needs to use tools that can help them with these tasks and provide them with useful information and insights. Some examples of tool types that are useful for a test manager are:
Defect tracking tool: This tool type allows the test manager to record, track, manage, and report the defects found during testing. It also helps the test manager to communicate with developers, testers, and other stakeholders about the defect status and resolution.
Test management tool: This tool type allows the test manager to organize, manage, and control the test process and its outcomes. It also helps the test manager to define the test strategy, plan the test activities, allocate the test resources, schedule the test execution, monitor the test progress, and evaluate the test results.
Requirements management tool: This tool type allows the test manager to manage and trace the requirements of the system under test. It also helps the test manager to ensure that the test objectives are aligned with the user needs and expectations and that the test coverage is adequate and complete.
The other tool types mentioned in the question are not as useful for a test manager as they are for other roles or purposes. For example:
Modeling tool: This tool type allows the user to create graphical or textual representations of software systems or processes. It can be used for design, analysis, simulation, or documentation purposes.
Static analysis tool: This tool type allows the user to examine the code or design of a software system without executing it. It can be used for finding defects, measuring complexity, checking compliance, or improving quality.
Coverage measurement tool: This tool type allows the user to measure how much of the code or design of a software system has been exercised by a set of test cases. It can be used for evaluating the effectiveness or completeness of testing.
You can find more information about tool types in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 61.
D
Explanation:
A tool type is a category of tools that have similar features and functions and can be used for similar purposes. A test manager is a person who is responsible for planning, monitoring, controlling, and reporting the test activities and results. A test manager needs to use tools that can help them with these tasks and provide them with useful information and insights. Some examples of tool types that are useful for a test manager are:
Defect tracking tool: This tool type allows the test manager to record, track, manage, and report the defects found during testing. It also helps the test manager to communicate with developers, testers, and other stakeholders about the defect status and resolution.
Test management tool: This tool type allows the test manager to organize, manage, and control the test process and its outcomes. It also helps the test manager to define the test strategy, plan the test activities, allocate the test resources, schedule the test execution, monitor the test progress, and evaluate the test results.
Requirements management tool: This tool type allows the test manager to manage and trace the requirements of the system under test. It also helps the test manager to ensure that the test objectives are aligned with the user needs and expectations and that the test coverage is adequate and complete.
The other tool types mentioned in the question are not as useful for a test manager as they are for other roles or purposes. For example:
Modeling tool: This tool type allows the user to create graphical or textual representations of software systems or processes. It can be used for design, analysis, simulation, or documentation purposes.
Static analysis tool: This tool type allows the user to examine the code or design of a software system without executing it. It can be used for finding defects, measuring complexity, checking compliance, or improving quality.
Coverage measurement tool: This tool type allows the user to measure how much of the code or design of a software system has been exercised by a set of test cases. It can be used for evaluating the effectiveness or completeness of testing.
You can find more information about tool types in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 61.
Question #23
The following diagram lists various types of operating systems, databases and application servers supported by the application under test.
For complete coverage of all combinations, how many combinations of the above are to be tested?
- A . 11
- B . 5
- C . 45
- D . 3
Correct Answer: C
C
Explanation:
The diagram lists various types of operating systems (LNX, W2K, WSP), databases (ORA, MSQ, SQL), and application servers (JBS, WSP) supported by the application under test. To test all possible combinations of these types, we need to multiply the number of options in each category.
In this case, we have:
3 options for operating systems
3 options for databases
2 options for application servers
Therefore, we have 3 x 3 x 2 = 18 possible combinations to test.
However, if we look closely at the diagram, we can see that some combinations are not valid or feasible because they are not connected by lines. For example, we cannot test LNX with WSP as an application server because there is no line between them. Similarly, we cannot test W2K with JBS as an application server because there is no line between them. Therefore, we need to exclude these invalid combinations from our calculation.
If we count only the valid combinations that are connected by lines in the diagram, we get:
5 combinations for LNX (LNX-ORA-JBS, LNX-ORA-WSP, LNX-MSQ-JBS, LNX-MSQ-WSP, LNX-SQL-JBS)
5 combinations for W2K (W2K-ORA-WSP, W2K-MSQ-WSP, W2K-SQL-WSP)
5 combinations for WSP (WSP-ORA-JBS, WSP-ORA-WSP, WSP-MSQ-JBS, WSP-MSQ-WSP) Therefore, we have 5 + 5 + 5 = 15 valid combinations to test.
You can find more information about testing combinations in Software Testing Foundations: A Study Guide for the Certified Tester Exam, Chapter 4, Section 4.22.
C
Explanation:
The diagram lists various types of operating systems (LNX, W2K, WSP), databases (ORA, MSQ, SQL), and application servers (JBS, WSP) supported by the application under test. To test all possible combinations of these types, we need to multiply the number of options in each category.
In this case, we have:
3 options for operating systems
3 options for databases
2 options for application servers
Therefore, we have 3 x 3 x 2 = 18 possible combinations to test.
However, if we look closely at the diagram, we can see that some combinations are not valid or feasible because they are not connected by lines. For example, we cannot test LNX with WSP as an application server because there is no line between them. Similarly, we cannot test W2K with JBS as an application server because there is no line between them. Therefore, we need to exclude these invalid combinations from our calculation.
If we count only the valid combinations that are connected by lines in the diagram, we get:
5 combinations for LNX (LNX-ORA-JBS, LNX-ORA-WSP, LNX-MSQ-JBS, LNX-MSQ-WSP, LNX-SQL-JBS)
5 combinations for W2K (W2K-ORA-WSP, W2K-MSQ-WSP, W2K-SQL-WSP)
5 combinations for WSP (WSP-ORA-JBS, WSP-ORA-WSP, WSP-MSQ-JBS, WSP-MSQ-WSP) Therefore, we have 5 + 5 + 5 = 15 valid combinations to test.
You can find more information about testing combinations in Software Testing Foundations: A Study Guide for the Certified Tester Exam, Chapter 4, Section 4.22.
Question #24
Which of the following is NOT a factor on which test estimation is dependent upon?
- A . Defect debugging and resolution
- B . The outcome of testing of previous test cycle
- C . Characteristics of the development process
- D . Characteristics of the product
Correct Answer: B
B
Explanation:
Test estimation is the process of predicting the effort, time, and resources required for testing a software system. Test estimation depends on several factors that influence the scope, complexity, and quality of testing.
Some of these factors are:
Characteristics of the product: This factor indicates how difficult or challenging it is to test the software system based on its size, functionality, reliability, usability, performance, security, etc. Characteristics of the development process: This factor indicates how well or poorly the software system is developed based on the development methodology, standards, tools, techniques, etc. Characteristics of the test process: This factor indicates how effective or efficient the testing process is based on the test strategy, plan, design, execution, evaluation, etc.
Characteristics of the test team: This factor indicates how skilled or experienced the test team is based on their knowledge, competence, motivation, communication, collaboration, etc.
The outcome of testing of previous test cycle is not a factor on which test estimation is dependent upon because it does not affect the effort, time, or resources required for testing the current test cycle. Rather, it is an outcome or consequence of test estimation that can provide feedback and lessons learned for improving future test estimations. You can find more information about test estimation in Software Testing Foundations: A Study Guide for the Certified Tester Exam, Chapter 22.
B
Explanation:
Test estimation is the process of predicting the effort, time, and resources required for testing a software system. Test estimation depends on several factors that influence the scope, complexity, and quality of testing.
Some of these factors are:
Characteristics of the product: This factor indicates how difficult or challenging it is to test the software system based on its size, functionality, reliability, usability, performance, security, etc. Characteristics of the development process: This factor indicates how well or poorly the software system is developed based on the development methodology, standards, tools, techniques, etc. Characteristics of the test process: This factor indicates how effective or efficient the testing process is based on the test strategy, plan, design, execution, evaluation, etc.
Characteristics of the test team: This factor indicates how skilled or experienced the test team is based on their knowledge, competence, motivation, communication, collaboration, etc.
The outcome of testing of previous test cycle is not a factor on which test estimation is dependent upon because it does not affect the effort, time, or resources required for testing the current test cycle. Rather, it is an outcome or consequence of test estimation that can provide feedback and lessons learned for improving future test estimations. You can find more information about test estimation in Software Testing Foundations: A Study Guide for the Certified Tester Exam, Chapter 22.
Question #25
Which of the following is a task of the Test Analysis and Design activity of the test process?
- A . Measuring the percentage of prepared test cases with what was actually prepared
- B . Identifying necessary test data to support the test conditions and test cases
- C . Verifying that the test environment has been set up correctly
- D . Checking test logs against the exit criteria specified in test planning
Correct Answer: B
B
Explanation:
The Test Analysis and Design activity of the test process is the activity where test conditions and test cases are identified and specified based on the test objectives and criteria. The Test Analysis and Design activity also involves identifying and preparing the necessary test data and test environment to support the test execution. Some of the tasks of the Test Analysis and Design activity are: Reviewing the test basis: This task involves reviewing the requirements, specifications, design documents, or other sources of information that form the basis for testing.
Identifying test conditions: This task involves identifying what needs to be tested based on the test basis and objectives.
Designing and prioritizing test cases: This task involves designing specific scenarios or steps to verify each test condition and assigning priorities to them based on their importance or risk level. Identifying necessary test data to support the test conditions and test cases: This task involves identifying what data is needed to execute each test case and how to obtain or generate it. Identifying and preparing the test environment: This task involves identifying what hardware, software, network, data, tools, etc., are needed to execute the test cases and how to set up and maintain them.
Measuring the percentage of prepared test cases with what was actually prepared is not a task of the Test Analysis and Design activity because it does not involve identifying or specifying anything related to testing. Rather, it is a task of the Test Monitoring and Control activity, which involves measuring and reporting the progress and status of testing against the planned activities and criteria. You can find more information about the Test Analysis and Design activity in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 31.
B
Explanation:
The Test Analysis and Design activity of the test process is the activity where test conditions and test cases are identified and specified based on the test objectives and criteria. The Test Analysis and Design activity also involves identifying and preparing the necessary test data and test environment to support the test execution. Some of the tasks of the Test Analysis and Design activity are: Reviewing the test basis: This task involves reviewing the requirements, specifications, design documents, or other sources of information that form the basis for testing.
Identifying test conditions: This task involves identifying what needs to be tested based on the test basis and objectives.
Designing and prioritizing test cases: This task involves designing specific scenarios or steps to verify each test condition and assigning priorities to them based on their importance or risk level. Identifying necessary test data to support the test conditions and test cases: This task involves identifying what data is needed to execute each test case and how to obtain or generate it. Identifying and preparing the test environment: This task involves identifying what hardware, software, network, data, tools, etc., are needed to execute the test cases and how to set up and maintain them.
Measuring the percentage of prepared test cases with what was actually prepared is not a task of the Test Analysis and Design activity because it does not involve identifying or specifying anything related to testing. Rather, it is a task of the Test Monitoring and Control activity, which involves measuring and reporting the progress and status of testing against the planned activities and criteria. You can find more information about the Test Analysis and Design activity in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, Chapter 31.
Question #26
Given the following requirement:
Which of the following statements is NOT correct?
- A . 7 and 13 are boundary values for the equivalence partition including age 10.
- B . Thursday is a valid input boundary value
- C . A minimum of 6 valid test cases are derived from boundary value analysis based on input age
- D . $3.01 is a valid output boundary value
Correct Answer: D
D
Explanation:
The requirement given in the image specifies an additional fee of $3 that is charged during the weekend, with some exceptions and discounts based on the age of the visitors. To test this requirement, we can use boundary value analysis, which is a specification-based test technique that involves testing the values at or near the boundaries of an equivalence partition. An equivalence partition is a set of values that are expected to be treated in the same way by the system under test.
For example, based on the requirement, we can identify the following equivalence partitions for the input age:
EP1: Age < 0 (invalid)
EP2: Age = 0 (valid, no charge)
EP3: 0 < Age < 7 (valid, no charge)
EP4: Age = 7 (valid, 20% discount)
EP5: 7 < Age < 13 (valid, 20% discount)
EP6: Age = 13 (valid, 20% discount)
EP7: 13 < Age < 65 (valid, full charge)
EP8: Age = 65 (valid, 50% discount)
EP9: Age > 65 (valid, 50% discount)
The boundary values for each equivalence partition are the values at or near the edges of the partition. For example, the boundary values for EP3 are 1 and 6. The boundary values for EP4 are 6 and 7. The boundary values for EP5 are 7 and 12. And so on.
To test this requirement using boundary value analysis, we need to select one value from each boundary and test it with different combinations of weekend and weekday.
For example, we can select the following values:
BV1: Age = -1 (from EP1)
BV2: Age = 0 (from EP2 and EP3)
BV3: Age = 6 (from EP3 and EP4)
BV4: Age = 7 (from EP4 and EP5)
BV5: Age = 12 (from EP5 and EP6)
BV6: Age = 13 (from EP6 and EP7)
BV7: Age = 64 (from EP7 and EP8)
BV8: Age = 65 (from EP8 and EP9)
BV9: Age = 66 (from EP9)
We can then create test cases using these values and different combinations of weekend and weekday.
For example:
TC1: Age = -1, Weekend = Yes -> Invalid input
TC2: Age = -1, Weekend = No -> Invalid input
TC3: Age = 0, Weekend = Yes -> No charge
TC4: Age = 0, Weekend = No -> No charge
TC5: Age = 6, Weekend = Yes -> No charge
TC6: Age = 6, Weekend = No -> No charge
TC7: Age = 7, Weekend = Yes -> $2.40 ($3 – 20% discount)
TC8: Age = 7, Weekend = No -> No charge
TC9: Age = 12, Weekend = Yes -> $2.40 ($3 – 20% discount)
TC10: Age = 12, Weekend = No -> No charge
TC11: Age = 13, Weekend = Yes -> $2.40 ($3 – 20% discount)
TC12: Age = 13, Weekend = No -> No charge
TC13: Age = 64, Weekend = Yes -> $3
TC14: Age = 64, Weekend = No -> No charge
TC15: Age = 65, Weekend = Yes -> $1.50 ($3 – 50% discount)
TC16: Age = 65, Weekend = No -> No charge
TC17: Age = 66, Weekend = Yes -> $1.50 ($3 – 50% discount)
TC18: Age =
66, Weekend = No -> No charge
Therefore, we need a minimum of 18 valid test cases to achieve 100% boundary value coverage based on input age.
$3.01 is not a valid output boundary value because it is not a possible output value based on the requirement. The output values can only be $0, $1.50, $2.40, or $3 depending on the input age and weekend status.
You can find more information about boundary value analysis in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.
D
Explanation:
The requirement given in the image specifies an additional fee of $3 that is charged during the weekend, with some exceptions and discounts based on the age of the visitors. To test this requirement, we can use boundary value analysis, which is a specification-based test technique that involves testing the values at or near the boundaries of an equivalence partition. An equivalence partition is a set of values that are expected to be treated in the same way by the system under test.
For example, based on the requirement, we can identify the following equivalence partitions for the input age:
EP1: Age < 0 (invalid)
EP2: Age = 0 (valid, no charge)
EP3: 0 < Age < 7 (valid, no charge)
EP4: Age = 7 (valid, 20% discount)
EP5: 7 < Age < 13 (valid, 20% discount)
EP6: Age = 13 (valid, 20% discount)
EP7: 13 < Age < 65 (valid, full charge)
EP8: Age = 65 (valid, 50% discount)
EP9: Age > 65 (valid, 50% discount)
The boundary values for each equivalence partition are the values at or near the edges of the partition. For example, the boundary values for EP3 are 1 and 6. The boundary values for EP4 are 6 and 7. The boundary values for EP5 are 7 and 12. And so on.
To test this requirement using boundary value analysis, we need to select one value from each boundary and test it with different combinations of weekend and weekday.
For example, we can select the following values:
BV1: Age = -1 (from EP1)
BV2: Age = 0 (from EP2 and EP3)
BV3: Age = 6 (from EP3 and EP4)
BV4: Age = 7 (from EP4 and EP5)
BV5: Age = 12 (from EP5 and EP6)
BV6: Age = 13 (from EP6 and EP7)
BV7: Age = 64 (from EP7 and EP8)
BV8: Age = 65 (from EP8 and EP9)
BV9: Age = 66 (from EP9)
We can then create test cases using these values and different combinations of weekend and weekday.
For example:
TC1: Age = -1, Weekend = Yes -> Invalid input
TC2: Age = -1, Weekend = No -> Invalid input
TC3: Age = 0, Weekend = Yes -> No charge
TC4: Age = 0, Weekend = No -> No charge
TC5: Age = 6, Weekend = Yes -> No charge
TC6: Age = 6, Weekend = No -> No charge
TC7: Age = 7, Weekend = Yes -> $2.40 ($3 – 20% discount)
TC8: Age = 7, Weekend = No -> No charge
TC9: Age = 12, Weekend = Yes -> $2.40 ($3 – 20% discount)
TC10: Age = 12, Weekend = No -> No charge
TC11: Age = 13, Weekend = Yes -> $2.40 ($3 – 20% discount)
TC12: Age = 13, Weekend = No -> No charge
TC13: Age = 64, Weekend = Yes -> $3
TC14: Age = 64, Weekend = No -> No charge
TC15: Age = 65, Weekend = Yes -> $1.50 ($3 – 50% discount)
TC16: Age = 65, Weekend = No -> No charge
TC17: Age = 66, Weekend = Yes -> $1.50 ($3 – 50% discount)
TC18: Age =
66, Weekend = No -> No charge
Therefore, we need a minimum of 18 valid test cases to achieve 100% boundary value coverage based on input age.
$3.01 is not a valid output boundary value because it is not a possible output value based on the requirement. The output values can only be $0, $1.50, $2.40, or $3 depending on the input age and weekend status.
You can find more information about boundary value analysis in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.
Question #27
Which of the following defect types are LEAST likely to be discovered when using static analysis tools?
- A . Variables that are never used
- B . Coding standard violations
- C . Memory leaks
- D . Uncalled functions and procedures
Correct Answer: C
C
Explanation:
Static analysis tools are tools that examine the code or design of a software system without executing it. Static analysis tools can be used to find defects, measure complexity, check compliance, or improve quality. Some examples of defect types that can be found by static analysis tools are: Variables that are never used: This defect type occurs when a variable is declared but not referenced or assigned in the code, which indicates a waste of memory or a logic error.
Coding standard violations: This defect type occurs when the code does not follow the predefined rules or conventions for formatting, naming, commenting, etc., which affects the readability and maintainability of the code.
Uncalled functions and procedures: This defect type occurs when a function or procedure is defined but not called or invoked in the code, which indicates a waste of resources or a missing functionality. Memory leaks are defect types that are least likely to be found by static analysis tools because they are related to the dynamic behavior and performance of the software system. Memory leaks occur when a program does not release memory that it has allocated, causing the system to run out of memory and slow down or crash. Memory leaks can only be detected by dynamic analysis tools that monitor the memory usage of the program during execution. You can find more information about static analysis tools in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 6, Section 6.3.
C
Explanation:
Static analysis tools are tools that examine the code or design of a software system without executing it. Static analysis tools can be used to find defects, measure complexity, check compliance, or improve quality. Some examples of defect types that can be found by static analysis tools are: Variables that are never used: This defect type occurs when a variable is declared but not referenced or assigned in the code, which indicates a waste of memory or a logic error.
Coding standard violations: This defect type occurs when the code does not follow the predefined rules or conventions for formatting, naming, commenting, etc., which affects the readability and maintainability of the code.
Uncalled functions and procedures: This defect type occurs when a function or procedure is defined but not called or invoked in the code, which indicates a waste of resources or a missing functionality. Memory leaks are defect types that are least likely to be found by static analysis tools because they are related to the dynamic behavior and performance of the software system. Memory leaks occur when a program does not release memory that it has allocated, causing the system to run out of memory and slow down or crash. Memory leaks can only be detected by dynamic analysis tools that monitor the memory usage of the program during execution. You can find more information about static analysis tools in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 6, Section 6.3.
Question #28
Out of the following, what is not needed to specify in defect report?
- A . How to fix the defect
- B . Severity and priority
- C . Test environment details
- D . How to reproduce the defect
Correct Answer: A
A
Explanation:
How to fix the defect is not needed to specify in a defect report because it is not part of the information that is required to describe, reproduce, and prioritize the defect.
How to fix the defect is part of the solution or resolution that is provided by the developers or maintainers who are responsible for correcting the defect. A defect report is a document that records and communicates the details of a defect found during testing. A defect report typically includes the following information:
Defect ID: A unique identifier for the defect
Summary: A brief description of the defect
Severity and priority: An indication of how serious and urgent the defect is
Test environment details: A description of the hardware, software, network, data, tools, etc., that were used when the defect was found
How to reproduce the defect: A step-by-step procedure to recreate the defect
Expected and actual results: A comparison of what should have happened and what actually happened when the defect occurred
Attachments: Any additional information or evidence that can help understand or resolve the defect, such as screenshots, logs, files, etc.
You can find more information about defect reports in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 5.
A
Explanation:
How to fix the defect is not needed to specify in a defect report because it is not part of the information that is required to describe, reproduce, and prioritize the defect.
How to fix the defect is part of the solution or resolution that is provided by the developers or maintainers who are responsible for correcting the defect. A defect report is a document that records and communicates the details of a defect found during testing. A defect report typically includes the following information:
Defect ID: A unique identifier for the defect
Summary: A brief description of the defect
Severity and priority: An indication of how serious and urgent the defect is
Test environment details: A description of the hardware, software, network, data, tools, etc., that were used when the defect was found
How to reproduce the defect: A step-by-step procedure to recreate the defect
Expected and actual results: A comparison of what should have happened and what actually happened when the defect occurred
Attachments: Any additional information or evidence that can help understand or resolve the defect, such as screenshots, logs, files, etc.
You can find more information about defect reports in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 5.
Question #29
Which ONE of the following statements does NOT describe how testing contributes to higher quality?
- A . Performing a review of the requirement specifications before implementing the system can enhance quality
- B . The testing of software demonstrates the absence of defects
- C . Properly designed tests that pass reduce the level of risk in a system
- D . Software testing identifies defects, which can be used to improve development activities.
Correct Answer: B
B
Explanation:
The statement that does not describe how testing contributes to higher quality is “The testing of software demonstrates the absence of defects”. This statement is false because testing cannot prove that a software system is defect-free or has a certain level of quality because there might be some untested inputs or outputs that could reveal defects or failures. Testing can only provide information about the quality and risk level of a software system based on the observed behavior and results under certain conditions and assumptions. The other statements describe how testing contributes to higher quality by:
Performing a review of the requirement specifications before implementing the system can enhance quality: This statement is true because reviewing the requirement specifications can help identify and prevent defects, ambiguities, inconsistencies, or incompleteness in the requirements before they are implemented in the system, which can save time and effort and improve customer satisfaction.
Properly designed tests that pass reduce the level of risk in a system: This statement is true because passing tests can increase confidence that the system meets its requirements and expectations and provides value to the users and customers. Passing tests can also reduce the probability or impact of failures or defects in the system that could cause harm or loss.
Software testing identifies defects, which can be used to improve development activities: This statement is true because identifying defects can help analyze and remove their causes and prevent them from recurring in future development activities. Identifying defects can also help improve development processes, methods, standards, tools, techniques, etc., by providing feedback and lessons learned.
You can find more information about how testing contributes to higher quality in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 1.
B
Explanation:
The statement that does not describe how testing contributes to higher quality is “The testing of software demonstrates the absence of defects”. This statement is false because testing cannot prove that a software system is defect-free or has a certain level of quality because there might be some untested inputs or outputs that could reveal defects or failures. Testing can only provide information about the quality and risk level of a software system based on the observed behavior and results under certain conditions and assumptions. The other statements describe how testing contributes to higher quality by:
Performing a review of the requirement specifications before implementing the system can enhance quality: This statement is true because reviewing the requirement specifications can help identify and prevent defects, ambiguities, inconsistencies, or incompleteness in the requirements before they are implemented in the system, which can save time and effort and improve customer satisfaction.
Properly designed tests that pass reduce the level of risk in a system: This statement is true because passing tests can increase confidence that the system meets its requirements and expectations and provides value to the users and customers. Passing tests can also reduce the probability or impact of failures or defects in the system that could cause harm or loss.
Software testing identifies defects, which can be used to improve development activities: This statement is true because identifying defects can help analyze and remove their causes and prevent them from recurring in future development activities. Identifying defects can also help improve development processes, methods, standards, tools, techniques, etc., by providing feedback and lessons learned.
You can find more information about how testing contributes to higher quality in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 1.
Question #30
Testing should provide sufficient information to stakeholders to make informed decisions about the release of the software or system being tested.
At which of the following fundamental test process activity the sufficiency of the testing and the resulting information are assessed?
- A . Implementation and execution
- B . Requirements specification
- C . Evaluating exit criteria and reporting.
- D . Analysis and design
Correct Answer: C
C
Explanation:
The fundamental test process activity where the sufficiency of testing and resulting information are assessed is Evaluating exit criteria and reporting. This activity involves checking whether the test objectives have been met and whether there are any unresolved issues or risks that could affect the release or deployment decision. This activity also involves preparing and communicating a test summary report that summarizes the test activities and results and provides recommendations and feedback for improvement. You can find more information about Evaluating exit criteria and reporting in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 3, Section 3.5.
C
Explanation:
The fundamental test process activity where the sufficiency of testing and resulting information are assessed is Evaluating exit criteria and reporting. This activity involves checking whether the test objectives have been met and whether there are any unresolved issues or risks that could affect the release or deployment decision. This activity also involves preparing and communicating a test summary report that summarizes the test activities and results and provides recommendations and feedback for improvement. You can find more information about Evaluating exit criteria and reporting in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 3, Section 3.5.
Question #31
A Software was re-deployed because the backend database was changed from one vendor to another The Test Manager decided to perform some functional tests on the redeployed system.
This is an example of test of which test type?
- A . Regression tests
- B . Non-functional tests
- C . Structural tests
- D . Unit tests
Correct Answer: A
A
Explanation:
Regression testing is a type of testing that is performed after a software system has been changed or modified to verify that the changes have not introduced any new defects or adversely affected the existing functionality of the system.
Regression testing can be performed when the software system undergoes different types of changes, such as:
Corrective changes: Changes that fix defects or errors in the software system
Adaptive changes: Changes that adapt the software system to new platforms or environments
Perfective changes: Changes that improve the performance or usability of the software system
Preventive changes: Changes that avoid potential problems or issues in the software system
In this case, the software system was re-deployed because the backend database was changed from one vendor to another, which is an example of an adaptive change. Therefore, the test manager decided to perform some functional tests on the re-deployed system to ensure that the change did not affect the functionality of the system. This is an example of regression testing.
The other types of testing mentioned in the question are not relevant for this scenario. For example:
Non-functional testing: This type of testing verifies the non-functional aspects of the software system, such as reliability, performance, security, usability, etc.
Structural testing: This type of testing verifies the internal structure or implementation of the software system, such as code, architecture, design, etc.
Unit testing: This type of testing verifies individual components or units of software in isolation from other components or systems.
You can find more information about regression testing in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 2, Section 2.4.
A
Explanation:
Regression testing is a type of testing that is performed after a software system has been changed or modified to verify that the changes have not introduced any new defects or adversely affected the existing functionality of the system.
Regression testing can be performed when the software system undergoes different types of changes, such as:
Corrective changes: Changes that fix defects or errors in the software system
Adaptive changes: Changes that adapt the software system to new platforms or environments
Perfective changes: Changes that improve the performance or usability of the software system
Preventive changes: Changes that avoid potential problems or issues in the software system
In this case, the software system was re-deployed because the backend database was changed from one vendor to another, which is an example of an adaptive change. Therefore, the test manager decided to perform some functional tests on the re-deployed system to ensure that the change did not affect the functionality of the system. This is an example of regression testing.
The other types of testing mentioned in the question are not relevant for this scenario. For example:
Non-functional testing: This type of testing verifies the non-functional aspects of the software system, such as reliability, performance, security, usability, etc.
Structural testing: This type of testing verifies the internal structure or implementation of the software system, such as code, architecture, design, etc.
Unit testing: This type of testing verifies individual components or units of software in isolation from other components or systems.
You can find more information about regression testing in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 2, Section 2.4.
Question #32
Which of the following is a correct set of boundary values to test the "Group Size" parameter, as defined by the following statement;
"In a reservation system for groups visiting a small museum, the graphical user interface presents a field asking the number of group members. Group size can be anywhere from 2 to 20 visitors"
- A . 0,1,8,21,22
- B . 0,1,2,3,10,19,20,21,22
- C . 2,3,19,20
- D . 1,2,20,21
Correct Answer: C
C
Explanation:
The requirement given in the image specifies a field asking for the number of group members, which can be anywhere from 2 to 20 visitors. To test this requirement, we can use boundary value analysis, which is a specification-based test technique that involves testing the values at or near the boundaries of an equivalence partition. An equivalence partition is a set of values that are expected to be treated in the same way by the system under test.
For example, based on the requirement, we can identify two equivalence partitions for the input group size: EP1: Group size < 2 (invalid)
EP2: Group size = 2 (valid)
EP3: 2 < Group size < 20 (valid)
EP4: Group size = 20 (valid)
EP5: Group size > 20 (invalid)
The boundary values for each equivalence partition are the values at or near the edges of the partition. For example, the boundary values for EP1 are -1 and 1. The boundary values for EP2 are 1 and 2. The boundary values for EP3 are 2 and 19. And so on.
To test this requirement using boundary value analysis, we need to select one value from each boundary and test it with different combinations of valid and invalid inputs.
For example, we can select the following values:
BV1: Group size = -1 (from EP1)
BV2: Group size = 1 (from EP1 and EP2)
BV3: Group size = 2 (from EP2 and EP3)
BV4: Group size = 19 (from EP3 and EP4)
BV5: Group size = 20 (from EP4 and EP5)
BV6: Group size = 21 (from EP5)
We can then create test cases using these values and different combinations of valid and invalid inputs. For example:
TC1: Group size = -1 -> Invalid input
TC2: Group size = 1 -> Invalid input
TC3: Group size = 2 -> Valid input
TC4: Group size = 19 -> Valid input
TC5: Group size = 20 -> Valid input
TC6: Group size = 21 -> Invalid input
Therefore, we need a minimum of 6 valid test cases to achieve 100% boundary value coverage based on input group size.
You can find more information about boundary value analysis in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.
C
Explanation:
The requirement given in the image specifies a field asking for the number of group members, which can be anywhere from 2 to 20 visitors. To test this requirement, we can use boundary value analysis, which is a specification-based test technique that involves testing the values at or near the boundaries of an equivalence partition. An equivalence partition is a set of values that are expected to be treated in the same way by the system under test.
For example, based on the requirement, we can identify two equivalence partitions for the input group size: EP1: Group size < 2 (invalid)
EP2: Group size = 2 (valid)
EP3: 2 < Group size < 20 (valid)
EP4: Group size = 20 (valid)
EP5: Group size > 20 (invalid)
The boundary values for each equivalence partition are the values at or near the edges of the partition. For example, the boundary values for EP1 are -1 and 1. The boundary values for EP2 are 1 and 2. The boundary values for EP3 are 2 and 19. And so on.
To test this requirement using boundary value analysis, we need to select one value from each boundary and test it with different combinations of valid and invalid inputs.
For example, we can select the following values:
BV1: Group size = -1 (from EP1)
BV2: Group size = 1 (from EP1 and EP2)
BV3: Group size = 2 (from EP2 and EP3)
BV4: Group size = 19 (from EP3 and EP4)
BV5: Group size = 20 (from EP4 and EP5)
BV6: Group size = 21 (from EP5)
We can then create test cases using these values and different combinations of valid and invalid inputs. For example:
TC1: Group size = -1 -> Invalid input
TC2: Group size = 1 -> Invalid input
TC3: Group size = 2 -> Valid input
TC4: Group size = 19 -> Valid input
TC5: Group size = 20 -> Valid input
TC6: Group size = 21 -> Invalid input
Therefore, we need a minimum of 6 valid test cases to achieve 100% boundary value coverage based on input group size.
You can find more information about boundary value analysis in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.
Question #33
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications.
Which team would be the most suitable for this goal?
- A . A team from an outsourcing company which specializes in testing accounting software
- B . A team with a mix of software testers and experts from the accounting department
- C . A team of users from the accounting department that will need to use the application on dairy basis
- D . A team from the company’s testing team, due to their experience in testing software
Correct Answer: B
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
Question #33
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications.
Which team would be the most suitable for this goal?
- A . A team from an outsourcing company which specializes in testing accounting software
- B . A team with a mix of software testers and experts from the accounting department
- C . A team of users from the accounting department that will need to use the application on dairy basis
- D . A team from the company’s testing team, due to their experience in testing software
Correct Answer: B
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
Question #33
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications.
Which team would be the most suitable for this goal?
- A . A team from an outsourcing company which specializes in testing accounting software
- B . A team with a mix of software testers and experts from the accounting department
- C . A team of users from the accounting department that will need to use the application on dairy basis
- D . A team from the company’s testing team, due to their experience in testing software
Correct Answer: B
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
Question #33
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications.
Which team would be the most suitable for this goal?
- A . A team from an outsourcing company which specializes in testing accounting software
- B . A team with a mix of software testers and experts from the accounting department
- C . A team of users from the accounting department that will need to use the application on dairy basis
- D . A team from the company’s testing team, due to their experience in testing software
Correct Answer: B
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
Question #33
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications.
Which team would be the most suitable for this goal?
- A . A team from an outsourcing company which specializes in testing accounting software
- B . A team with a mix of software testers and experts from the accounting department
- C . A team of users from the accounting department that will need to use the application on dairy basis
- D . A team from the company’s testing team, due to their experience in testing software
Correct Answer: B
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
Question #33
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications.
Which team would be the most suitable for this goal?
- A . A team from an outsourcing company which specializes in testing accounting software
- B . A team with a mix of software testers and experts from the accounting department
- C . A team of users from the accounting department that will need to use the application on dairy basis
- D . A team from the company’s testing team, due to their experience in testing software
Correct Answer: B
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
Question #33
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications.
Which team would be the most suitable for this goal?
- A . A team from an outsourcing company which specializes in testing accounting software
- B . A team with a mix of software testers and experts from the accounting department
- C . A team of users from the accounting department that will need to use the application on dairy basis
- D . A team from the company’s testing team, due to their experience in testing software
Correct Answer: B
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
Question #33
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications.
Which team would be the most suitable for this goal?
- A . A team from an outsourcing company which specializes in testing accounting software
- B . A team with a mix of software testers and experts from the accounting department
- C . A team of users from the accounting department that will need to use the application on dairy basis
- D . A team from the company’s testing team, due to their experience in testing software
Correct Answer: B
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
B
Explanation:
A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department.
This team would have the following advantages:
Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers. The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios.
For example:
A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process. A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.
A team from the company’s testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.
Question #41
Send "reservation ready" message to a borrower
Which of the following test sequences represents a possible use case? (a test sequence always start with test #1)
- A . 1-4-2-7-5-6-3
- B . 1-6-2-5-7-4-3
- C . 1-6-4-7-5-3-2
- D . 1-2-6-7-4-5-3
Correct Answer: D
D
Explanation:
A use case is a description of how a user interacts with a system to achieve a goal or perform a task. A use case typically consists of a sequence of steps or actions that the user and the system perform to complete the goal or task. A use case can be used as a basis for designing test cases that verify the functionality and usability of the system under test. A test sequence that represents a possible use case should follow the logical order and flow of the user-system interaction and cover the main scenario and possible variations or exceptions.
For example, based on the test cases given for a Library Management System, we can identify the following use cases: UC1:
Add a new borrower to the system
UC2: Update a borrower’s data
UC3: Remove a borrower from the system
UC4: Loan a book to a borrower
UC5: Return a book from a borrower
UC6: Reserve a book for a borrower
UC7: Send “reservation ready” message to a borrower
The test sequence that represents a possible use case is D. 1-2-6-7-4-5-3. This test sequence follows the logical order and flow of the user-system interaction and covers the main scenario and possible variations or exceptions.
For example:
TC1: Add a new borrower to the system -> This is the first step of the use case, where the user registers as a new borrower in the system.
TC2: Update a borrower’s data -> This is a possible variation of the use case, where the user updates their personal or contact information in the system.
TC6: Reserve a book for a borrower -> This is the second step of the use case, where the user reserves a book that they want to borrow from the library.
TC7: Send “reservation ready” message to a borrower -> This is the third step of the use case, where the system sends a message to the user informing them that their reserved book is ready for pickup. TC4: Loan a book to a borrower -> This is the fourth step of the use case, where the user picks up their reserved book from the library and loans it from the system.
TC5: Return a book from a borrower -> This is the fifth step of the use case, where the user returns their borrowed book to the library and returns it to the system.
TC3: Remove a borrower from the system -> This is a possible exception of the use case, where the user decides to cancel their membership and remove their account from the system.
The other test sequences do not represent possible use cases because they do not follow the logical order and flow of the user-system interaction or they do not cover the main scenario and possible variations or exceptions.
For example:
A: 1-4-2-7-5-6-3 -> This test sequence does not follow the logical order and flow of the user-system interaction because it performs some steps before or after they are supposed to happen. For example, it performs TC4 (Loan a book to a borrower) before TC6 (Reserve a book for a borrower), which does not make sense because the user cannot loan a book that they have not reserved yet.
B: 1-6-2-5-7-4-3 -> This test sequence does not follow the logical order and flow of the user-system interaction because it performs some steps before or after they are supposed to happen. For example, it performs TC5 (Return a book from a borrower) before TC4 (Loan a book to a borrower), which does not make sense because the user cannot return a book that they have not loaned yet.
C: 1-6-4-7-5-3-2 -> This test sequence does not cover the main scenario and possible variations or exceptions because it omits some steps that are essential for completing or terminating the use case. For example, it omits TC2 (Update a borrower’s data), which is a possible variation of the use case that allows the user to change their personal or contact information in the system.
You can find more information about use cases and test sequences in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.
D
Explanation:
A use case is a description of how a user interacts with a system to achieve a goal or perform a task. A use case typically consists of a sequence of steps or actions that the user and the system perform to complete the goal or task. A use case can be used as a basis for designing test cases that verify the functionality and usability of the system under test. A test sequence that represents a possible use case should follow the logical order and flow of the user-system interaction and cover the main scenario and possible variations or exceptions.
For example, based on the test cases given for a Library Management System, we can identify the following use cases: UC1:
Add a new borrower to the system
UC2: Update a borrower’s data
UC3: Remove a borrower from the system
UC4: Loan a book to a borrower
UC5: Return a book from a borrower
UC6: Reserve a book for a borrower
UC7: Send “reservation ready” message to a borrower
The test sequence that represents a possible use case is D. 1-2-6-7-4-5-3. This test sequence follows the logical order and flow of the user-system interaction and covers the main scenario and possible variations or exceptions.
For example:
TC1: Add a new borrower to the system -> This is the first step of the use case, where the user registers as a new borrower in the system.
TC2: Update a borrower’s data -> This is a possible variation of the use case, where the user updates their personal or contact information in the system.
TC6: Reserve a book for a borrower -> This is the second step of the use case, where the user reserves a book that they want to borrow from the library.
TC7: Send “reservation ready” message to a borrower -> This is the third step of the use case, where the system sends a message to the user informing them that their reserved book is ready for pickup. TC4: Loan a book to a borrower -> This is the fourth step of the use case, where the user picks up their reserved book from the library and loans it from the system.
TC5: Return a book from a borrower -> This is the fifth step of the use case, where the user returns their borrowed book to the library and returns it to the system.
TC3: Remove a borrower from the system -> This is a possible exception of the use case, where the user decides to cancel their membership and remove their account from the system.
The other test sequences do not represent possible use cases because they do not follow the logical order and flow of the user-system interaction or they do not cover the main scenario and possible variations or exceptions.
For example:
A: 1-4-2-7-5-6-3 -> This test sequence does not follow the logical order and flow of the user-system interaction because it performs some steps before or after they are supposed to happen. For example, it performs TC4 (Loan a book to a borrower) before TC6 (Reserve a book for a borrower), which does not make sense because the user cannot loan a book that they have not reserved yet.
B: 1-6-2-5-7-4-3 -> This test sequence does not follow the logical order and flow of the user-system interaction because it performs some steps before or after they are supposed to happen. For example, it performs TC5 (Return a book from a borrower) before TC4 (Loan a book to a borrower), which does not make sense because the user cannot return a book that they have not loaned yet.
C: 1-6-4-7-5-3-2 -> This test sequence does not cover the main scenario and possible variations or exceptions because it omits some steps that are essential for completing or terminating the use case. For example, it omits TC2 (Update a borrower’s data), which is a possible variation of the use case that allows the user to change their personal or contact information in the system.
You can find more information about use cases and test sequences in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.
Question #42
A money order system is designed to calculate the charge for a transfer
– Amounts from 1 to 1999 are charged EUR 10.
– Amounts from 2000 to 5000 are charged EUR 15
– Amounts below EUR 1 or above EUR 5000 are not accepted.
Assume that only integer values can occur.
Which of these sets of amounts covers all equivalence classes?
- A . 0-1999-2000-5000
- B . 1-2000-5001-10000
- C . 0-100-2000-6000
- D . 99-1- 2000- 4999,99
Correct Answer: C
C
Explanation:
The requirement given in the image specifies the charge for a money transfer based on the amount of money transferred.
The amount can be anywhere from 1 to 5000 euros, with different charges applied for different ranges of amounts.
To test this requirement, we can use equivalence partitioning, which is a specification-based test technique that involves dividing the input or output values into groups or partitions that are expected to be treated in the same way by the system under test.
For example, based on the requirement, we can identify the following equivalence partitions for the input amount:
EP1: Amount < 1 (invalid)
EP2: 1 <= Amount <= 1999 (valid, charge = 10 euros)
EP3: 2000 <= Amount <= 5000 (valid, charge = 15 euros)
EP4: Amount > 5000 (invalid)
The set of amounts that covers all equivalence partitions is C. 0-100-2000-6000. This set of amounts includes one value from each equivalence partition and ensures that all possible scenarios are tested.
For example:
TC1: Amount = 0 -> Invalid input
TC2: Amount = 100 -> Valid input, charge = 10 euros
TC3: Amount = 2000 -> Valid input, charge = 15 euros
TC4: Amount = 6000 -> Invalid input
The other sets of amounts do not cover all equivalence partitions because they either include values that belong to the same partition or exclude values that belong to different partitions.
For example:
A: 0-1999-2000-5000 -> This set of amounts does not cover all equivalence partitions because it includes two values that belong to EP2 (1999 and 2000) and excludes any value that belongs to EP3.
B: 1-2000-5001-10000 -> This set of amounts does not cover all equivalence partitions because it includes two values that belong to EP4 (5001 and 10000) and excludes any value that belongs to EP2.
D: 99-1-2000-4999.99 -> This set of amounts does not cover all equivalence partitions because it includes a value that is not an integer (4999.99), which violates the assumption that only integer values can occur.
You can find more information about equivalence partitioning in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.
C
Explanation:
The requirement given in the image specifies the charge for a money transfer based on the amount of money transferred.
The amount can be anywhere from 1 to 5000 euros, with different charges applied for different ranges of amounts.
To test this requirement, we can use equivalence partitioning, which is a specification-based test technique that involves dividing the input or output values into groups or partitions that are expected to be treated in the same way by the system under test.
For example, based on the requirement, we can identify the following equivalence partitions for the input amount:
EP1: Amount < 1 (invalid)
EP2: 1 <= Amount <= 1999 (valid, charge = 10 euros)
EP3: 2000 <= Amount <= 5000 (valid, charge = 15 euros)
EP4: Amount > 5000 (invalid)
The set of amounts that covers all equivalence partitions is C. 0-100-2000-6000. This set of amounts includes one value from each equivalence partition and ensures that all possible scenarios are tested.
For example:
TC1: Amount = 0 -> Invalid input
TC2: Amount = 100 -> Valid input, charge = 10 euros
TC3: Amount = 2000 -> Valid input, charge = 15 euros
TC4: Amount = 6000 -> Invalid input
The other sets of amounts do not cover all equivalence partitions because they either include values that belong to the same partition or exclude values that belong to different partitions.
For example:
A: 0-1999-2000-5000 -> This set of amounts does not cover all equivalence partitions because it includes two values that belong to EP2 (1999 and 2000) and excludes any value that belongs to EP3.
B: 1-2000-5001-10000 -> This set of amounts does not cover all equivalence partitions because it includes two values that belong to EP4 (5001 and 10000) and excludes any value that belongs to EP2.
D: 99-1-2000-4999.99 -> This set of amounts does not cover all equivalence partitions because it includes a value that is not an integer (4999.99), which violates the assumption that only integer values can occur.
You can find more information about equivalence partitioning in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.
Question #43
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,1 click ENTER to continue to screen 2. Nothing happens, no system response at all.
- A . Add an impact analysis
- B . Add information about which developer should fix the bug
- C . Add the time stamp when the incident happened
- D . Add information about which web browser was used
Correct Answer: A
A
Explanation:
The most important report improvement is A. Add an impact analysis. An impact analysis is an assessment of how the defect affects the functionality, usability, performance, reliability, security, or other aspects of the system under test. An impact analysis can help prioritize and classify the defect based on its severity and urgency. An impact analysis can also help determine the root cause and possible solutions for the defect. An impact analysis is an essential part of a defect report because it provides useful information for decision-making and improvement processes.
The other report improvements are not as important as adding an impact analysis because they do not provide as much information or value for decision-making and improvement processes. For example:
B: Add information about which developer should fix the bug: This report improvement is not necessary because it is not part of the information that is required to describe, reproduce, and prioritize the defect. The assignment of developers to fix bugs is part of the defect management process, which involves assigning, tracking, resolving, and verifying defects.
C: Add the time stamp when the incident happened: This report improvement is not very useful because it does not provide much information about the cause or effect of the defect. The time stamp when the incident happened is only relevant if it is related to some external factors or events that could influence the behavior or performance of the system under test.
D: Add information about which web browser was used: This report improvement is not very relevant because it does not affect the functionality or usability of the system under test. The web browser used is only relevant if it is related to some compatibility or interoperability issues that could cause defects or failures in the system under test.
You can find more information about defect reports and impact analysis in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 5.
A
Explanation:
The most important report improvement is A. Add an impact analysis. An impact analysis is an assessment of how the defect affects the functionality, usability, performance, reliability, security, or other aspects of the system under test. An impact analysis can help prioritize and classify the defect based on its severity and urgency. An impact analysis can also help determine the root cause and possible solutions for the defect. An impact analysis is an essential part of a defect report because it provides useful information for decision-making and improvement processes.
The other report improvements are not as important as adding an impact analysis because they do not provide as much information or value for decision-making and improvement processes. For example:
B: Add information about which developer should fix the bug: This report improvement is not necessary because it is not part of the information that is required to describe, reproduce, and prioritize the defect. The assignment of developers to fix bugs is part of the defect management process, which involves assigning, tracking, resolving, and verifying defects.
C: Add the time stamp when the incident happened: This report improvement is not very useful because it does not provide much information about the cause or effect of the defect. The time stamp when the incident happened is only relevant if it is related to some external factors or events that could influence the behavior or performance of the system under test.
D: Add information about which web browser was used: This report improvement is not very relevant because it does not affect the functionality or usability of the system under test. The web browser used is only relevant if it is related to some compatibility or interoperability issues that could cause defects or failures in the system under test.
You can find more information about defect reports and impact analysis in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 5.
Question #44
Which of the following statements is true?
- A . Incident management tools are used by testers only
- B . A configuration management tool has nothing to do with testing
- C . Test management tools are used by managers only
- D . A requirements management tool may be considered as test support tool
Correct Answer: D
D
Explanation:
A requirements management tool may be considered as a test support tool because it can help support or enhance some aspects of testing activities or processes. A requirements management tool is a tool that allows users to manage and trace the requirements of a software system.
A requirements management tool can help support or enhance testing activities or processes by:
Providing a clear and consistent definition of what needs to be tested based on user needs and expectations
Enabling traceability between requirements and test cases to ensure adequate and complete test coverage
Supporting change management and impact analysis by identifying and tracking changes in requirements and their effects on testing activities and results
D
Explanation:
A requirements management tool may be considered as a test support tool because it can help support or enhance some aspects of testing activities or processes. A requirements management tool is a tool that allows users to manage and trace the requirements of a software system.
A requirements management tool can help support or enhance testing activities or processes by:
Providing a clear and consistent definition of what needs to be tested based on user needs and expectations
Enabling traceability between requirements and test cases to ensure adequate and complete test coverage
Supporting change management and impact analysis by identifying and tracking changes in requirements and their effects on testing activities and results
Question #45
An organization is working on updating test cases for a particular module of their software.
Sam updated a set of test cases yesterday and saved the new version on his PC.
Unfortunately, the hard disk of his PC crashed, and his work was lost.
The IT department of the organization restored the contents of his hard disk with the last available back-up – from the previous morning However the changes made by him yesterday were lost forever Which of the following tools, had it been used, would have prevented the loss of Sam’s updates?
- A . Incident Management Tool
- B . Configuration Management Tool
- C . Test Execution tool
- D . Backup tool
Correct Answer: B
B
Explanation:
A configuration management tool is a tool that allows users to manage and control the versions and changes of software artifacts, such as code, documents, test cases, etc.
A configuration management tool can help prevent the loss of Sam’s updates by:
Providing a centralized repository where Sam can store and retrieve his test cases and other artifacts Keeping track of the history and status of each artifact and allowing Sam to compare and revert to previous versions if needed
Supporting collaboration and communication among team members by allowing them to share and access the latest versions of the artifacts
The other tools mentioned in the question are not relevant for this scenario because they do not provide the same functionality or benefits as a configuration management tool.
For example:
A: Incident management tool: This tool type allows users to record, track, manage, and report the defects found during testing. It does not help with managing or controlling the versions or changes of test cases or other artifacts.
C: Test execution tool: This tool type allows users to execute test cases automatically or semi-automatically and compare the actual results with the expected results. It does not help with managing or controlling the versions or changes of test cases or other artifacts.
D: Backup tool: This tool type allows users to create copies of data or files and store them in a different location or device for recovery purposes. It does not help with managing or controlling the versions or changes of test cases or other artifacts.
You can find more information about configuration management tools in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 6, Section 6.4.
B
Explanation:
A configuration management tool is a tool that allows users to manage and control the versions and changes of software artifacts, such as code, documents, test cases, etc.
A configuration management tool can help prevent the loss of Sam’s updates by:
Providing a centralized repository where Sam can store and retrieve his test cases and other artifacts Keeping track of the history and status of each artifact and allowing Sam to compare and revert to previous versions if needed
Supporting collaboration and communication among team members by allowing them to share and access the latest versions of the artifacts
The other tools mentioned in the question are not relevant for this scenario because they do not provide the same functionality or benefits as a configuration management tool.
For example:
A: Incident management tool: This tool type allows users to record, track, manage, and report the defects found during testing. It does not help with managing or controlling the versions or changes of test cases or other artifacts.
C: Test execution tool: This tool type allows users to execute test cases automatically or semi-automatically and compare the actual results with the expected results. It does not help with managing or controlling the versions or changes of test cases or other artifacts.
D: Backup tool: This tool type allows users to create copies of data or files and store them in a different location or device for recovery purposes. It does not help with managing or controlling the versions or changes of test cases or other artifacts.
You can find more information about configuration management tools in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 6, Section 6.4.
Question #46
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 . II, Ill
- C . II, IV
- D . I, IV
Correct Answer: B
B
Explanation:
A decision table is a specification-based test technique that involves creating a table that shows the combinations of inputs and outputs for a system under test based on certain conditions and rules.
A decision table can be used to design test cases that cover all possible scenarios and outcomes for a system under test. Some statements about decision tables are:
I, Generally, decision tables are generated for low risk test items: This statement is false because decision tables can be generated for any level of risk test items depending on the complexity and variability of the system under test. Decision tables are especially useful for testing systems that have many inputs, outputs, conditions, and rules that affect their behavior or performance.
II, Test cases derived from decision tables can be used for component tests: This statement is true because decision tables can be used to design test cases for any level or type of testing, including component tests. Component tests are tests that verify individual components or units of software in isolation from other components or systems.
III, Several test cases can be selected for each column of the decision table: This statement is true because each column of the decision table represents a unique combination of inputs and outputs for the system under test based on certain conditions and rules. Therefore, each column can be used as a basis for selecting one or more test cases that cover that combination.
IV, The conditions in the decision table represent negative tests generally: This statement is false because the conditions in the decision table can represent both positive and negative tests depending on the requirements and expectations of the system under test. Positive tests are tests that verify that the system under test behaves as expected under valid or normal inputs or conditions. Negative tests are tests that verify that the system under test handles errors or exceptions gracefully under invalid or abnormal inputs or conditions.
You can find more information about decision tables in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.
B
Explanation:
A decision table is a specification-based test technique that involves creating a table that shows the combinations of inputs and outputs for a system under test based on certain conditions and rules.
A decision table can be used to design test cases that cover all possible scenarios and outcomes for a system under test. Some statements about decision tables are:
I, Generally, decision tables are generated for low risk test items: This statement is false because decision tables can be generated for any level of risk test items depending on the complexity and variability of the system under test. Decision tables are especially useful for testing systems that have many inputs, outputs, conditions, and rules that affect their behavior or performance.
II, Test cases derived from decision tables can be used for component tests: This statement is true because decision tables can be used to design test cases for any level or type of testing, including component tests. Component tests are tests that verify individual components or units of software in isolation from other components or systems.
III, Several test cases can be selected for each column of the decision table: This statement is true because each column of the decision table represents a unique combination of inputs and outputs for the system under test based on certain conditions and rules. Therefore, each column can be used as a basis for selecting one or more test cases that cover that combination.
IV, The conditions in the decision table represent negative tests generally: This statement is false because the conditions in the decision table can represent both positive and negative tests depending on the requirements and expectations of the system under test. Positive tests are tests that verify that the system under test behaves as expected under valid or normal inputs or conditions. Negative tests are tests that verify that the system under test handles errors or exceptions gracefully under invalid or abnormal inputs or conditions.
You can find more information about decision tables in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.
Question #47
"Statement Testing" is part of;
- A . Experience based testing
- B . Decision Testing
- C . Specification Based testing
- D . Structured based testing
Correct Answer: D
D
Explanation:
Statement testing is part of structure-based testing, which is a type of testing that verifies the internal structure or implementation of a software system, such as code, architecture, design, etc. Statement testing is a structure-based test technique that involves testing every statement in the code at least once to ensure that there are no syntax errors, logical errors, or hidden defects in the code. Statement testing requires some knowledge of the internal structure or implementation of the software system; it focuses on how the system does what it does rather than what it does.
The other types of testing mentioned in the question are not related to statement testing because they do not verify the internal structure or implementation of a software system.
For example:
A: Experience-based testing: This type of testing relies on the skills, knowledge, intuition, and creativity of testers to design and execute test cases based on their experience with similar systems or situations.
B: Decision testing: This type of testing verifies every decision point in the code by testing all possible outcomes or branches of each decision point to ensure that there are no logical errors or hidden defects in the code.
C: Specification-based testing: This type of testing verifies the external behavior or functionality of a software system based on its requirements, specifications, design documents, or other sources of information.
You can find more information about statement testing and structure-based testing in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.3.
D
Explanation:
Statement testing is part of structure-based testing, which is a type of testing that verifies the internal structure or implementation of a software system, such as code, architecture, design, etc. Statement testing is a structure-based test technique that involves testing every statement in the code at least once to ensure that there are no syntax errors, logical errors, or hidden defects in the code. Statement testing requires some knowledge of the internal structure or implementation of the software system; it focuses on how the system does what it does rather than what it does.
The other types of testing mentioned in the question are not related to statement testing because they do not verify the internal structure or implementation of a software system.
For example:
A: Experience-based testing: This type of testing relies on the skills, knowledge, intuition, and creativity of testers to design and execute test cases based on their experience with similar systems or situations.
B: Decision testing: This type of testing verifies every decision point in the code by testing all possible outcomes or branches of each decision point to ensure that there are no logical errors or hidden defects in the code.
C: Specification-based testing: This type of testing verifies the external behavior or functionality of a software system based on its requirements, specifications, design documents, or other sources of information.
You can find more information about statement testing and structure-based testing in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.3.
Question #48
The four test levels defined for a common V-model testing approach are:
- A . Unit, integration, system and maintenance.
- B . Functional, glass box, incremental and maintenance.
- C . Component, integration, system and acceptance.
- D . Unit, component, functional and alpha/beta.
Correct Answer: C
C
Explanation:
These are the four test levels defined for a common V-model testing approach, according to the ISTQB Foundation Level 2018 Syllabus. Unit testing is another term for component testing, and maintenance testing is not a test level, but a type of testing that can be performed at any level.
C
Explanation:
These are the four test levels defined for a common V-model testing approach, according to the ISTQB Foundation Level 2018 Syllabus. Unit testing is another term for component testing, and maintenance testing is not a test level, but a type of testing that can be performed at any level.
Question #49
Typically, exit criteria may consist of:
- A . Defining the amount, level of detail structure, and templates for the test documentation.
- B . Estimates of defect density or reliability measures.
- C . Adequacy of the test approaches taken.
- D . Discussions on disaster recovery.
Correct Answer: B
B
Explanation:
These are examples of exit criteria, which are the conditions that must be met before testing can be completed. Exit criteria may also include test coverage measures, residual risk assessment, or stakeholder approval. The other options are not exit criteria, but rather test planning activities.
B
Explanation:
These are examples of exit criteria, which are the conditions that must be met before testing can be completed. Exit criteria may also include test coverage measures, residual risk assessment, or stakeholder approval. The other options are not exit criteria, but rather test planning activities.
Question #50
A data driven approach to test automation design is best described as:
- A . Using action words to describe the actions to be taken, the test data.
- B . Scaling to support large numbers of users.
- C . Being based on Equivalence Partitioning testing techniques.
- D . Separating out the test data inputs and using a generic script that can read the test data and perform the same test steps with different data.
Correct Answer: D
D
Explanation:
This is the definition of a data driven approach to test automation design, which allows for reusability and maintainability of test scripts.
Option A describes a keyword driven approach, which uses action words to describe the test steps and data.
Option B is not related to test automation design, but rather to performance testing.
Option C is also not related to test automation design, but rather to a testing technique.
D
Explanation:
This is the definition of a data driven approach to test automation design, which allows for reusability and maintainability of test scripts.
Option A describes a keyword driven approach, which uses action words to describe the test steps and data.
Option B is not related to test automation design, but rather to performance testing.
Option C is also not related to test automation design, but rather to a testing technique.
Question #51
Which of the following risks represents the highest level of risk to the project?
- A . Likelihood of failure = 1%, potential cost of impact = $1m.
- B . Likelihood of failure = 10%, potential cost of impact = $500,000.
- C . Likelihood of failure = 20%, potential cost of impact = $150,000.
- D . Likelihood of failure = 5%, potential cost of impact = $500,000.
Correct Answer: B
B
Explanation:
Likelihood of failure = 10%, potential cost of impact = $500,000. The level of risk to the project can be calculated by multiplying the likelihood of failure by the potential cost of impact.
This gives us the following values for each option:
A: 1% x $1m = $10,000
B. 10% x $500,000 = $50,000
C. 20% x $150,000 = $30,000
D. 5% x $500,000 = $25,000
B
Explanation:
Likelihood of failure = 10%, potential cost of impact = $500,000. The level of risk to the project can be calculated by multiplying the likelihood of failure by the potential cost of impact.
This gives us the following values for each option:
A: 1% x $1m = $10,000
B. 10% x $500,000 = $50,000
C. 20% x $150,000 = $30,000
D. 5% x $500,000 = $25,000
Question #52
What factors should be considered to determine whether enough testing has been performed?
(i) The exit criteria.
(ii) The budget.
(iii) How big the test team is.
(iv) The product’s risk profile.
(v) How good the testing tools are.
(vi) Sufficient details of the system status to allow decisions
- A . i and ii and iv and vi
- B . i and ii and iii and vi
- C . ii and iii and iv and v
- D . i and ii and v and vi
Correct Answer: A
A
Explanation:
These are some of the factors that should be considered to determine whether enough testing has been performed. The exit criteria define the specific goals and requirements for testing completion. The budget limits the resources and time available for testing. The product’s risk profile indicates the areas of highest priority and impact for testing. Sufficient details of the system status allow decisions on whether further testing is needed or not. The other options are not relevant factors for determining enough testing.
A
Explanation:
These are some of the factors that should be considered to determine whether enough testing has been performed. The exit criteria define the specific goals and requirements for testing completion. The budget limits the resources and time available for testing. The product’s risk profile indicates the areas of highest priority and impact for testing. Sufficient details of the system status allow decisions on whether further testing is needed or not. The other options are not relevant factors for determining enough testing.
Question #53
Which of the following statements is most true about test conditions?
- A . An item or event of a component or system that can be verified by one or more test cases.
- B . The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result.
- C . A testable component derived from business requirements.
- D . Applies to software testing only.
Correct Answer: A
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
Question #53
Which of the following statements is most true about test conditions?
- A . An item or event of a component or system that can be verified by one or more test cases.
- B . The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result.
- C . A testable component derived from business requirements.
- D . Applies to software testing only.
Correct Answer: A
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
Question #53
Which of the following statements is most true about test conditions?
- A . An item or event of a component or system that can be verified by one or more test cases.
- B . The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result.
- C . A testable component derived from business requirements.
- D . Applies to software testing only.
Correct Answer: A
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
Question #53
Which of the following statements is most true about test conditions?
- A . An item or event of a component or system that can be verified by one or more test cases.
- B . The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result.
- C . A testable component derived from business requirements.
- D . Applies to software testing only.
Correct Answer: A
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
Question #53
Which of the following statements is most true about test conditions?
- A . An item or event of a component or system that can be verified by one or more test cases.
- B . The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result.
- C . A testable component derived from business requirements.
- D . Applies to software testing only.
Correct Answer: A
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
Question #53
Which of the following statements is most true about test conditions?
- A . An item or event of a component or system that can be verified by one or more test cases.
- B . The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result.
- C . A testable component derived from business requirements.
- D . Applies to software testing only.
Correct Answer: A
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
Question #53
Which of the following statements is most true about test conditions?
- A . An item or event of a component or system that can be verified by one or more test cases.
- B . The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result.
- C . A testable component derived from business requirements.
- D . Applies to software testing only.
Correct Answer: A
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
Question #53
Which of the following statements is most true about test conditions?
- A . An item or event of a component or system that can be verified by one or more test cases.
- B . The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result.
- C . A testable component derived from business requirements.
- D . Applies to software testing only.
Correct Answer: A
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
Question #53
Which of the following statements is most true about test conditions?
- A . An item or event of a component or system that can be verified by one or more test cases.
- B . The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result.
- C . A testable component derived from business requirements.
- D . Applies to software testing only.
Correct Answer: A
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
Question #53
Which of the following statements is most true about test conditions?
- A . An item or event of a component or system that can be verified by one or more test cases.
- B . The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result.
- C . A testable component derived from business requirements.
- D . Applies to software testing only.
Correct Answer: A
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
A
Explanation:
A test condition is an item or event of a component or system that can be verified by one or more test cases. A test condition can be derived from various sources of information, such as requirements, specifications, design documents, use cases, user stories, etc. A test condition can also be based on various aspects of a component or system, such as functionality, usability, performance, reliability, security, etc.
The other statements are not true about test conditions because they describe different concepts related to testing.
For example:
B: The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result: This statement describes a test suite, which is a collection of test cases that are intended to be executed together to achieve a specific test objective or goal.
C: A testable component derived from business requirements: This statement describes a test basis, which is the source of information or data that provides the basis for designing and executing test cases.
D: Applies to software testing only: This statement is false because test conditions can apply to any type of testing, not just software testing. Test conditions can also be used for testing hardware, systems, processes, etc.
You can find more information about test conditions in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.1.
Question #63
End
How many test cases are needed to achieve 100 per cent decision coverage?
- A . 1
- B . 2
- C . 3
- D . 4
Correct Answer: B
B
Explanation:
Decision coverage is a structure-based test technique that involves testing every decision point in the code by testing all possible outcomes or branches of each decision point. Decision coverage requires some knowledge of the internal structure or implementation of the software system; it focuses on how the system does what it does rather than what it does.
The pseudo code given in the question has one decision point at line 4, where the value of Gender is compared to ‘female’.
This decision point has two possible outcomes or branches:
True branch: If Gender = ‘female’, then print “Ms” at line 5.
False branch: If Gender!= ‘female’, then print “Mr” at line 7.
To achieve 100 per cent decision coverage, we need to test both outcomes or branches of the decision point at least once.
Therefore, we need two test cases that cover both scenarios:
TC1: Gender = ‘female’ -> Print “Dear Ms”
TC2: Gender = ‘male’ -> Print “Dear Mr”
The other options are not correct because they do not provide enough or too many test cases to achieve 100 per cent decision coverage.
For example:
A: 1: This option is not enough because it only provides one test case that covers one outcome or branch of the decision point, but not the other.
C: 3: This option is too many because it provides three test cases that cover both outcomes or branches of the decision point, but one of them is redundant or unnecessary.
D: 4: This option is too many because it provides four test cases that cover both outcomes or branches of the decision point, but two of them are redundant or unnecessary.
You can find more information about decision coverage and structure-based testing in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.3.
B
Explanation:
Decision coverage is a structure-based test technique that involves testing every decision point in the code by testing all possible outcomes or branches of each decision point. Decision coverage requires some knowledge of the internal structure or implementation of the software system; it focuses on how the system does what it does rather than what it does.
The pseudo code given in the question has one decision point at line 4, where the value of Gender is compared to ‘female’.
This decision point has two possible outcomes or branches:
True branch: If Gender = ‘female’, then print “Ms” at line 5.
False branch: If Gender!= ‘female’, then print “Mr” at line 7.
To achieve 100 per cent decision coverage, we need to test both outcomes or branches of the decision point at least once.
Therefore, we need two test cases that cover both scenarios:
TC1: Gender = ‘female’ -> Print “Dear Ms”
TC2: Gender = ‘male’ -> Print “Dear Mr”
The other options are not correct because they do not provide enough or too many test cases to achieve 100 per cent decision coverage.
For example:
A: 1: This option is not enough because it only provides one test case that covers one outcome or branch of the decision point, but not the other.
C: 3: This option is too many because it provides three test cases that cover both outcomes or branches of the decision point, but one of them is redundant or unnecessary.
D: 4: This option is too many because it provides four test cases that cover both outcomes or branches of the decision point, but two of them are redundant or unnecessary.
You can find more information about decision coverage and structure-based testing in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], Chapter 4, Section 4.3.
Question #64
What is static analysis?
- A . The decision between using white or black box test techniques.
- B . Executing software to validate the most common path through the code.
- C . A technique to find defects in software source code and software models, performed without executing code.
- D . It is a testing technique used during system testing.
Correct Answer: C
C
Explanation:
Static analysis is a technique to find defects in software source code and software models, performed without executing code. Static analysis can be done manually or automatically using tools that examine the code or design of a software system without running it. Static analysis can help identify and prevent defects, measure complexity, check compliance, or improve quality.
The other statements are not correct definitions of static analysis because they describe different concepts related to testing.
For example:
A: The decision between using white or black box test techniques: This statement describes a test strategy, which is an approach or method for designing and executing test cases based on various factors, such as scope, objectives, risks, resources, etc.
B: Executing software to validate the most common path through the code: This statement describes dynamic testing, which is a technique to find defects in software by executing it under various conditions and inputs and comparing the actual results with the expected results.
D: It is a testing technique used during system testing: This statement describes a test level, which is a group of test activities that are organized and managed together based on some criteria, such as objectives, scope, target audience, etc.
You can find more information about static analysis in [A Study Guide to the ISTQB® Foundation Level
2018 Syllabus], Chapter 6, Section 6.3.
C
Explanation:
Static analysis is a technique to find defects in software source code and software models, performed without executing code. Static analysis can be done manually or automatically using tools that examine the code or design of a software system without running it. Static analysis can help identify and prevent defects, measure complexity, check compliance, or improve quality.
The other statements are not correct definitions of static analysis because they describe different concepts related to testing.
For example:
A: The decision between using white or black box test techniques: This statement describes a test strategy, which is an approach or method for designing and executing test cases based on various factors, such as scope, objectives, risks, resources, etc.
B: Executing software to validate the most common path through the code: This statement describes dynamic testing, which is a technique to find defects in software by executing it under various conditions and inputs and comparing the actual results with the expected results.
D: It is a testing technique used during system testing: This statement describes a test level, which is a group of test activities that are organized and managed together based on some criteria, such as objectives, scope, target audience, etc.
You can find more information about static analysis in [A Study Guide to the ISTQB® Foundation Level
2018 Syllabus], Chapter 6, Section 6.3.
Question #65
Component testing may include:
- A . Sociability testing.
- B . User acceptance testing.
- C . Beta testing.
- D . The use of stubs and drivers.
Correct Answer: D
Question #66
Which type of review has the following main purposes:
discussing, making decisions, evaluating alternatives, finding defects, solving technical problems and checking conformance to specifications, plans, regulations, and standards?
- A . Technical Review
- B . Inspection
- C . Walkthrough
- D . Informal review
Correct Answer: A
A
Explanation:
A
Explanation:
Question #66
Which type of review has the following main purposes:
discussing, making decisions, evaluating alternatives, finding defects, solving technical problems and checking conformance to specifications, plans, regulations, and standards?
- A . Technical Review
- B . Inspection
- C . Walkthrough
- D . Informal review
Correct Answer: A
A
Explanation:
A
Explanation:
Question #66
Which type of review has the following main purposes:
discussing, making decisions, evaluating alternatives, finding defects, solving technical problems and checking conformance to specifications, plans, regulations, and standards?
- A . Technical Review
- B . Inspection
- C . Walkthrough
- D . Informal review
Correct Answer: A
A
Explanation:
A
Explanation:
Question #66
Which type of review has the following main purposes:
discussing, making decisions, evaluating alternatives, finding defects, solving technical problems and checking conformance to specifications, plans, regulations, and standards?
- A . Technical Review
- B . Inspection
- C . Walkthrough
- D . Informal review
Correct Answer: A
A
Explanation:
A
Explanation:
Question #66
Which type of review has the following main purposes:
discussing, making decisions, evaluating alternatives, finding defects, solving technical problems and checking conformance to specifications, plans, regulations, and standards?
- A . Technical Review
- B . Inspection
- C . Walkthrough
- D . Informal review
Correct Answer: A
A
Explanation:
A
Explanation:
Question #66
Which type of review has the following main purposes:
discussing, making decisions, evaluating alternatives, finding defects, solving technical problems and checking conformance to specifications, plans, regulations, and standards?
- A . Technical Review
- B . Inspection
- C . Walkthrough
- D . Informal review
Correct Answer: A
A
Explanation:
A
Explanation:
Question #66
Which type of review has the following main purposes:
discussing, making decisions, evaluating alternatives, finding defects, solving technical problems and checking conformance to specifications, plans, regulations, and standards?
- A . Technical Review
- B . Inspection
- C . Walkthrough
- D . Informal review
Correct Answer: A
A
Explanation:
A
Explanation:
Question #66
Which type of review has the following main purposes:
discussing, making decisions, evaluating alternatives, finding defects, solving technical problems and checking conformance to specifications, plans, regulations, and standards?
- A . Technical Review
- B . Inspection
- C . Walkthrough
- D . Informal review
Correct Answer: A
A
Explanation:
A
Explanation:
Question #66
Which type of review has the following main purposes:
discussing, making decisions, evaluating alternatives, finding defects, solving technical problems and checking conformance to specifications, plans, regulations, and standards?
- A . Technical Review
- B . Inspection
- C . Walkthrough
- D . Informal review
Correct Answer: A
A
Explanation:
A
Explanation:
Question #75
End
What is the minimum number of test cases required to guarantee both 100% statement coverage and 100% decision coverage?
- A . Statement coverage = 3, Decision coverage = 3
- B . Statement coverage = 2, Decision coverage = 2
- C . Statement coverage = 1, Decision coverage = 2
- D . Statement coverage = 2, Decision coverage = 1
Correct Answer: B
B
Explanation:
The minimum number of test cases required to guarantee both 100% statement coverage and 100% decision coverage is 2. Statement coverage means that every statement in the code is executed at least once by the test cases. Decision coverage means that every possible outcome of each decision (such as if-else statements) is executed at least once by the test cases. To achieve both statement and decision coverage, we need to test two scenarios: one where X > Y and one where X <= Y. This will ensure that all statements and decisions are covered by the test cases. A detailed explanation of statement and decision coverage can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 61-671.
B
Explanation:
The minimum number of test cases required to guarantee both 100% statement coverage and 100% decision coverage is 2. Statement coverage means that every statement in the code is executed at least once by the test cases. Decision coverage means that every possible outcome of each decision (such as if-else statements) is executed at least once by the test cases. To achieve both statement and decision coverage, we need to test two scenarios: one where X > Y and one where X <= Y. This will ensure that all statements and decisions are covered by the test cases. A detailed explanation of statement and decision coverage can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 61-671.
Question #76
Which of the following best describes the Black-box technique?
- A . It uses decision coverage for completeness.
- B . It ensures all possible branches in the code are tested.
- C . It is based on the internal structure of the system.
- D . It can be done without reference to the internal structure of the component or system.
Correct Answer: D
D
Explanation:
It can be done without reference to the internal structure of the component or system. Black-box testing techniques are based on the external behavior and functionality of the system, not on its internal structure or code. Black-box testing techniques include equivalence partitioning, boundary value analysis, decision table testing, state transition testing, use case testing, etc. A detailed explanation of black-box testing techniques can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 25-601.
D
Explanation:
It can be done without reference to the internal structure of the component or system. Black-box testing techniques are based on the external behavior and functionality of the system, not on its internal structure or code. Black-box testing techniques include equivalence partitioning, boundary value analysis, decision table testing, state transition testing, use case testing, etc. A detailed explanation of black-box testing techniques can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 25-601.
Question #77
System testing is:
- A . Used to search for defects in software modules that are separately testable.
- B . The responsibility of the users of a system.
- C . Concerned with the behavior of a whole system/product as defined by the scope of a development project.
- D . Triggered by modifications, migration or retirement of the software system.
Correct Answer: C
C
Explanation:
Concerned with the behavior of a whole system/product as defined by the scope of a development
project. System testing is a level of testing that evaluates the system as a whole against its requirements and specifications. System testing is performed after integration testing and before acceptance testing. System testing covers functional and non-functional aspects of the system, such as usability, performance, reliability, security, etc. A detailed explanation of system testing can be found in A Self-Study Guide For The ISTQB Foundation Exam Certified Tester Foundation Level (CTFL) 2018 Syllabus, pages 75-782.
C
Explanation:
Concerned with the behavior of a whole system/product as defined by the scope of a development
project. System testing is a level of testing that evaluates the system as a whole against its requirements and specifications. System testing is performed after integration testing and before acceptance testing. System testing covers functional and non-functional aspects of the system, such as usability, performance, reliability, security, etc. A detailed explanation of system testing can be found in A Self-Study Guide For The ISTQB Foundation Exam Certified Tester Foundation Level (CTFL) 2018 Syllabus, pages 75-782.
Question #78
A client-server system for a web development must support a minimum of 200 enquiries per hour. In peak times, it must be available 24 hours x 7 days due to the critical nature of the application, and must have a response time lower than 20 seconds during peak loads.
Which of the following set of test types would be most appropriate to verify the non-functional requirements expressed in this statement?
- A . Performance, Usability, Regression.
- B . System, Load, Fail-over.
- C . Performance, Load, Stress.
- D . Load, Volume and Component.
Correct Answer: C
C
Explanation:
Performance, Load, Stress. Performance testing is a type of non-functional testing that measures how well the system performs under various conditions, such as response time, throughput, resource utilization, etc. Load testing is a type of performance testing that simulates a high volume of user requests or transactions on the system and measures its behavior under normal and peak load conditions. Stress testing is a type of performance testing that simulates extreme or abnormal conditions on the system and measures its behavior under stress or overload conditions. These test types would help verify the requirements such as minimum number of enquiries per hour, availability, and response time under peak loads. A detailed explanation of performance, load, and stress testing can be found in Software Testing Foundations: A Study Guide for the Certified Tester Exam, pages 187-1913.
C
Explanation:
Performance, Load, Stress. Performance testing is a type of non-functional testing that measures how well the system performs under various conditions, such as response time, throughput, resource utilization, etc. Load testing is a type of performance testing that simulates a high volume of user requests or transactions on the system and measures its behavior under normal and peak load conditions. Stress testing is a type of performance testing that simulates extreme or abnormal conditions on the system and measures its behavior under stress or overload conditions. These test types would help verify the requirements such as minimum number of enquiries per hour, availability, and response time under peak loads. A detailed explanation of performance, load, and stress testing can be found in Software Testing Foundations: A Study Guide for the Certified Tester Exam, pages 187-1913.
Question #79
When an organization considers the use of testing tools, they should:
- A . Use a tool in order to help define a good test process because the tool will force process repeatability and therefore enforce good test process.
- B . Always start by bringing in automated test execution tools as these tools have the greatest return on investment and therefore should be introduced first.
- C . Perform analysis of the test process and then assess whether it can be supported through the introduction of tool support.
- D . Allow the developers to select the testing tools because tools are technical and developers have the appropriate skills to advise on test tool selection and configuration.
Correct Answer: C
C
Explanation:
When an organization considers the use of testing tools, they should C. Perform analysis of the test process and then assess whether it can be supported through the introduction of tool support. Testing tools can provide many benefits to the test process, such as increased efficiency, effectiveness, consistency, quality, etc. However, testing tools also have some challenges and risks associated with them, such as cost, learning curve, compatibility, maintenance, etc. Therefore, before introducing any testing tool, an organization should analyze their current test process and identify their needs, goals, expectations, constraints, etc., and then evaluate whether a tool can support them or not. A detailed explanation of testing tools can be found in Software Testing Foundations: A Study Guide for the Certified Tester Exam, pages 193-1983.
C
Explanation:
When an organization considers the use of testing tools, they should C. Perform analysis of the test process and then assess whether it can be supported through the introduction of tool support. Testing tools can provide many benefits to the test process, such as increased efficiency, effectiveness, consistency, quality, etc. However, testing tools also have some challenges and risks associated with them, such as cost, learning curve, compatibility, maintenance, etc. Therefore, before introducing any testing tool, an organization should analyze their current test process and identify their needs, goals, expectations, constraints, etc., and then evaluate whether a tool can support them or not. A detailed explanation of testing tools can be found in Software Testing Foundations: A Study Guide for the Certified Tester Exam, pages 193-1983.
Question #80
Which of the following test design techniques is not a black box technique?
- A . Equivalence partitioning
- B . State transition testing
- C . Boundary value analysis
- D . Statement coverage
Correct Answer: D
D
Explanation:
Statement coverage is not a black box technique, because it requires knowledge of the internal structure of the code. Black box techniques are based on the external behavior and specification of the software, without looking at the code. Equivalence partitioning, state transition testing, and boundary value analysis are all examples of black box techniques12
D
Explanation:
Statement coverage is not a black box technique, because it requires knowledge of the internal structure of the code. Black box techniques are based on the external behavior and specification of the software, without looking at the code. Equivalence partitioning, state transition testing, and boundary value analysis are all examples of black box techniques12
Question #81
Which of the following are valid test objectives?
(i) Finding defects.
(ii) Gaining confidence about the level of quality and providing information.
(iii) Preventing defects.
(iv) Debugging the code.
- A . i, ii and iii
- B . i, ii and iv
- C . ii and iii
- D . i and iv
Correct Answer: A
A
Explanation:
Finding defects, gaining confidence about the level of quality and providing information, and preventing defects are all valid test objectives according to the ISTQB Foundation Level syllabus. Debugging the code is not a test objective, because debugging is the process of finding and fixing defects, which is done by developers, not testers3
A
Explanation:
Finding defects, gaining confidence about the level of quality and providing information, and preventing defects are all valid test objectives according to the ISTQB Foundation Level syllabus. Debugging the code is not a test objective, because debugging is the process of finding and fixing defects, which is done by developers, not testers3
Question #82
What can testing demonstrate?
- A . Testing can demonstrate that there are no defects
- B . Testing can demonstrate that there are defects
- C . Testing can demonstrate that the software is correct
- D . Testing can demonstrate that there are no hidden defects in the software
Correct Answer: B
B
Explanation:
Testing can demonstrate that there are defects in the software, by finding and reporting them. Testing cannot demonstrate that there are no defects, because it is impossible to test all possible scenarios and inputs. Testing cannot demonstrate that the software is correct, because correctness is a subjective and relative concept that depends on the expectations and requirements of the stakeholders. Testing cannot demonstrate that there are no hidden defects in the software, because hidden defects are those that are not detected by testing or other quality assurance activities.
B
Explanation:
Testing can demonstrate that there are defects in the software, by finding and reporting them. Testing cannot demonstrate that there are no defects, because it is impossible to test all possible scenarios and inputs. Testing cannot demonstrate that the software is correct, because correctness is a subjective and relative concept that depends on the expectations and requirements of the stakeholders. Testing cannot demonstrate that there are no hidden defects in the software, because hidden defects are those that are not detected by testing or other quality assurance activities.
Question #83
Equivalence Partitioning is best defined as:
- A . An analysis technique that divides inputs into groups that are expected to exhibit similar behaviors.
- B . Applying to time-related data classes only.
- C . A form of white-box testing.
- D . A method to reduce test coverage.
Correct Answer: A
A
Explanation:
Equivalence partitioning is best defined as an analysis technique that divides inputs into groups that are expected to exhibit similar behaviors. The idea is to reduce the number of test cases by selecting one representative value from each group or partition. Equivalence partitioning does not apply to time-related data classes only, but to any type of input data that can be divided into partitions. Equivalence partitioning is not a form of white-box testing, but a black-box testing technique. Equivalence partitioning is not a method to reduce test coverage, but a method to achieve test coverage more efficiently.
A
Explanation:
Equivalence partitioning is best defined as an analysis technique that divides inputs into groups that are expected to exhibit similar behaviors. The idea is to reduce the number of test cases by selecting one representative value from each group or partition. Equivalence partitioning does not apply to time-related data classes only, but to any type of input data that can be divided into partitions. Equivalence partitioning is not a form of white-box testing, but a black-box testing technique. Equivalence partitioning is not a method to reduce test coverage, but a method to achieve test coverage more efficiently.
Question #84
Dynamic Analysis Tools are used to:
- A . Determine differences between files or databases.
- B . Monitor and report on how a system behaves under a variety of conditions.
- C . Find defects, such as memory leaks, while software is executing.
- D . Measure the percentage of specific types of code structure that have been exercised.
Correct Answer: C
C
Explanation:
Dynamic analysis tools are used to find defects, such as memory leaks, while software is executing. Dynamic analysis tools monitor the behavior and performance of the software under various conditions and report on any anomalies or errors. Dynamic analysis tools are not used to determine differences between files or databases, which is a function of comparison tools. Dynamic analysis tools are not used to measure the percentage of specific types of code structure that have been exercised, which is a function of code coverage tools.
C
Explanation:
Dynamic analysis tools are used to find defects, such as memory leaks, while software is executing. Dynamic analysis tools monitor the behavior and performance of the software under various conditions and report on any anomalies or errors. Dynamic analysis tools are not used to determine differences between files or databases, which is a function of comparison tools. Dynamic analysis tools are not used to measure the percentage of specific types of code structure that have been exercised, which is a function of code coverage tools.
Question #85
What other details should be included in the following incident report when it is first submitted?
Date of Issue: 23/11/05
Severity: P1
Build: Version15.6
Details: Expected field to be limited to 15 chars, able to enter 27
- A . Suggested solution, priority and number of defects assigned to this developer.
- B . Status of the incident, degree of impact, Test Case Number.
- C . History, related defects and expected fix time.
- D . Line of code, number of defects found, time of day.
Correct Answer: B
B
Explanation:
The other details that should be included in the incident report when it is first submitted are B. Status of the incident, degree of impact, Test Case Number. These details are important to provide information about the current state of the incident, the severity of its effect on the system or user, and the test case that detected the incident. Other details, such as suggested solution, priority, history, related defects, expected fix time, line of code, etc., can be added later during the incident management process. A detailed explanation of incident report can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 99-1001.
B
Explanation:
The other details that should be included in the incident report when it is first submitted are B. Status of the incident, degree of impact, Test Case Number. These details are important to provide information about the current state of the incident, the severity of its effect on the system or user, and the test case that detected the incident. Other details, such as suggested solution, priority, history, related defects, expected fix time, line of code, etc., can be added later during the incident management process. A detailed explanation of incident report can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 99-1001.
Question #86
Which of the following are ‘Exit Criteria?’
- A . Acceptance criteria, completion criteria, pass/fail criteria.
- B . Coverage of code, schedule, estimates of defect density.
- C . The last executable statement within a component.
- D . Cost overruns.
Correct Answer: B
B
Explanation:
Coverage of code, schedule, estimates of defect density. Exit criteria are the conditions that must be met before testing can be completed and the system can be released. Exit criteria can be based on factors such as coverage of code or requirements, schedule or budget constraints, estimates of defect density or severity, etc. Exit criteria help to determine when to stop testing and evaluate the quality of the system. A detailed explanation of exit criteria can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 15-161.
B
Explanation:
Coverage of code, schedule, estimates of defect density. Exit criteria are the conditions that must be met before testing can be completed and the system can be released. Exit criteria can be based on factors such as coverage of code or requirements, schedule or budget constraints, estimates of defect density or severity, etc. Exit criteria help to determine when to stop testing and evaluate the quality of the system. A detailed explanation of exit criteria can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 15-161.
Question #87
What is decision table testing?
- A . It’s a testing design technique based in the internal software structure.
- B . It’s a static test design technique.
- C . It’s a testing design technique to verify decisions.
- D . It’s a testing design technique based in the system requirements.
Correct Answer: D
D
Explanation:
A testing design technique based in the system requirements. Decision table testing is a black-box testing technique that is used to test complex business rules or logic that involve multiple conditions and actions. Decision table testing uses a tabular format to represent all possible combinations of inputs (conditions) and outputs (actions) for a given decision. Decision table testing helps to ensure that all scenarios are covered and tested. A detailed explanation of decision table testing can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 47-511.
D
Explanation:
A testing design technique based in the system requirements. Decision table testing is a black-box testing technique that is used to test complex business rules or logic that involve multiple conditions and actions. Decision table testing uses a tabular format to represent all possible combinations of inputs (conditions) and outputs (actions) for a given decision. Decision table testing helps to ensure that all scenarios are covered and tested. A detailed explanation of decision table testing can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 47-511.
Question #88
Which of the following, select the best description of the fundamental test process:
- A . Planning and control, analysis, design, implementation, execution, evaluation of exit criteria and reporting, test closure.
- B . Executing tests, identifying and recording defects and preparing recommendation and closure reports.
- C . Controls, preparation of test cases, execution of test cases, execution of regression packs, communicating with developers, writing recommendations for release.
- D . Static testing, dynamic testing, defect reporting, reporting and closure.
Correct Answer: A
A
Explanation:
Planning and control, analysis, design, implementation, execution, evaluation of exit criteria and reporting, test closure. The fundamental test process is a generic model that describes the main activities and tasks involved in testing. The fundamental test process consists of five phases: planning and control, analysis and design, implementation and execution, evaluation of exit criteria and reporting, and test closure activities. Each phase has specific objectives, inputs, outputs, and deliverables. A detailed explanation of the fundamental test process can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 13-241.
A
Explanation:
Planning and control, analysis, design, implementation, execution, evaluation of exit criteria and reporting, test closure. The fundamental test process is a generic model that describes the main activities and tasks involved in testing. The fundamental test process consists of five phases: planning and control, analysis and design, implementation and execution, evaluation of exit criteria and reporting, and test closure activities. Each phase has specific objectives, inputs, outputs, and deliverables. A detailed explanation of the fundamental test process can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 13-241.
Question #89
Which of the following processes ensures that all items of testware are identified, version controlled, tracked for changes, so that traceability can be maintained throughout the test process?
- A . Software traceability process
- B . Incidence management process
- C . Testing design process
- D . Configuration management process
Correct Answer: D
D
Explanation:
The process that ensures that all items of testware are identified, version controlled, tracked for changes, so that traceability can be maintained throughout the test process is D. Configuration management process. Configuration management is a process that establishes and maintains the integrity and consistency of all items of testware throughout the test process. Configuration management involves identifying, storing, controlling, tracking, and auditing all items of testware (such as test plans, test cases, test scripts, test data, test results, etc.) and their versions and changes. Configuration management helps to ensure that only authorized and approved items of testware are used for testing and that traceability can be maintained between them. A detailed explanation of configuration management can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 101-1021.
D
Explanation:
The process that ensures that all items of testware are identified, version controlled, tracked for changes, so that traceability can be maintained throughout the test process is D. Configuration management process. Configuration management is a process that establishes and maintains the integrity and consistency of all items of testware throughout the test process. Configuration management involves identifying, storing, controlling, tracking, and auditing all items of testware (such as test plans, test cases, test scripts, test data, test results, etc.) and their versions and changes. Configuration management helps to ensure that only authorized and approved items of testware are used for testing and that traceability can be maintained between them. A detailed explanation of configuration management can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 101-1021.
Question #90
What is the value of static code analysis?
- A . Detection of failures not easily found by other types of testing
- B . Early defect detection
- C . Detection of suspicious operations caused by deviations from regulations
- D . Detect deviations in standards by executing the source code
Correct Answer: B
B
Explanation:
Static code analysis is a technique that examines the source code or other software artifacts without executing them, and can detect defects, vulnerabilities, code smells, and deviations from standards early in the development process1. According to the ISTQB syllabus, one of the benefits of static testing is early defect detection2, which can reduce the cost and effort of fixing them later.
B
Explanation:
Static code analysis is a technique that examines the source code or other software artifacts without executing them, and can detect defects, vulnerabilities, code smells, and deviations from standards early in the development process1. According to the ISTQB syllabus, one of the benefits of static testing is early defect detection2, which can reduce the cost and effort of fixing them later.
Question #91
Which of the following statements about use-case testing are most accurate?
(i) In a use-case diagram an actor represents a type of user.
(ii) Use-cases are the most common test basis for unit testing.
(iii) A use-case describes interactions between actors.
(iv) An actor is always a human user that interacts with the system.
(v) Test cases can be based on use-case scenarios.
(vi) Use-case testing will often identify gaps not found by testing individual components.
- A . ii, iii, iv, v
- B . i, iii, v, vi
- C . i, ii, iv, v
- D . iii, iv, v, vi
Correct Answer: B
B
Explanation:
Use-case testing is a technique that uses use-cases as a test basis to derive test cases2. A use-case is a description of interactions between actors and a system to achieve a goal2. An actor represents a type of user or anything that interacts with the system2. Use-cases are not the most common test basis for unit testing, as they are more suitable for higher levels of testing such as system or acceptance testing3. An actor is not always a human user, as it can also be another system or device2. Test cases can be based on use-case scenarios, which are sequences of actions and events that occur during a use-case execution2. Use-case testing will often identify gaps not found by testing individual components, as it can reveal missing or incorrect requirements, integration issues, and usability problems.
B
Explanation:
Use-case testing is a technique that uses use-cases as a test basis to derive test cases2. A use-case is a description of interactions between actors and a system to achieve a goal2. An actor represents a type of user or anything that interacts with the system2. Use-cases are not the most common test basis for unit testing, as they are more suitable for higher levels of testing such as system or acceptance testing3. An actor is not always a human user, as it can also be another system or device2. Test cases can be based on use-case scenarios, which are sequences of actions and events that occur during a use-case execution2. Use-case testing will often identify gaps not found by testing individual components, as it can reveal missing or incorrect requirements, integration issues, and usability problems.
Question #92
It is recommended to perform exhaustive tests for covering all combinations of inputs and preconditions.
- A . Yes, it’s strongly recommended.
- B . No, risk analysis and priorities should be used to focus testing efforts
- C . Yes, and it’s also necessary to include all the exit combinations
- D . Only the expert testers can make exhaustive tests.
Correct Answer: B
B
Explanation:
Exhaustive testing is a technique that covers all possible combinations of inputs and preconditions2. However, it is not recommended to perform exhaustive testing, as it is usually impractical and impossible due to the large number of test cases required2. Instead, risk analysis and priorities should be used to focus testing efforts on the most important and critical aspects of the system under test2.
B
Explanation:
Exhaustive testing is a technique that covers all possible combinations of inputs and preconditions2. However, it is not recommended to perform exhaustive testing, as it is usually impractical and impossible due to the large number of test cases required2. Instead, risk analysis and priorities should be used to focus testing efforts on the most important and critical aspects of the system under test2.
Question #93
Refer to the exhibit
Given the following State Transition diagram, match the test cases below with the relevant set of state transitions.
(i) X-Z-V-W
(ii) W-Y-U-U
- A . (i) = S1 C S2 C S3 C S4 C S2 and (ii) = S4 C S2 C S4 C S4 C S4
- B . (i) = S1 C S2 C S3 C S4 C S4 and (ii) = S2 CS4 C S4 C S4 C S2
- C . (i) = S2 C S3 C S4 C S2 C S2 and (ii) = S4 C S2 C S4 C S4 C S4
- D . (i) = S2 C S3 C S4 – S4 C S2 and (ii) = S2 CS3 C S4 CS4 C S4
Correct Answer: A
A
Explanation:
State transition testing is a technique that uses state transition diagrams as a test basis to derive test cases2. A state transition diagram shows the states of a system and the transitions between them triggered by events or conditions2. A test case can cover one or more state transitions, depending on the test objective and coverage criterion2.
In this question, the test cases (i) and (ii) cover different sets of state transitions, as shown below:
Test Case State Transitions
(i) X-Z-V-W S1 C S2 C S3 C S4 C S2
(ii) W-Y-U-U S4 C S2 C S4 C S4 C S4
A
Explanation:
State transition testing is a technique that uses state transition diagrams as a test basis to derive test cases2. A state transition diagram shows the states of a system and the transitions between them triggered by events or conditions2. A test case can cover one or more state transitions, depending on the test objective and coverage criterion2.
In this question, the test cases (i) and (ii) cover different sets of state transitions, as shown below:
Test Case State Transitions
(i) X-Z-V-W S1 C S2 C S3 C S4 C S2
(ii) W-Y-U-U S4 C S2 C S4 C S4 C S4
Question #94
A system calculates the amount of customs duty to be paid:
_ No duty is paid on goods value up to, and including, $2,000.
_ The next $8,000 is taxed at 10%.
_ The next $20,000 after that is taxed at 12%.
_ Any further amount after that is taxed at 17%.
To the nearest $, which of these groups of numbers fall into three DIFFERENT equivalence classes?
- A . $20,000 $20,001 $30,001
- B . $2,000 $2,001 $10,000
- C . $2,000 $8,000 $20,000
- D . $1,500 $2,000 $10,000
Correct Answer: C
C
Explanation:
Equivalence partitioning is a technique that divides the input domain of a system into partitions or classes that are expected to behave similarly or produce similar outputs2. A test case can cover one value from each partition, as it is assumed that all values in the same partition are equivalent for testing purposes2. In this question, the groups of numbers fall into different equivalence classes based on the amount of customs duty to be paid, as shown below:
Group Equivalence Classes
$20,000 $20,001 $30,001 No duty (up to $2,000), 10% duty ($2,001-$10,000), 12% duty ($10,001-$30,000), 17% duty (above $30,000)
$2,000 $2,001 $10,000 No duty (up to $2,000), 10% duty ($2,001-$10,000), 12% duty ($10,001-$30,000)
$2,000 $8,000 $20,000 No duty (up to $2,000), 10% duty ($2,001-$10,000), 12% duty ($10,001-$30,000)
$1,500 $2,000 $10,000 No duty (up to $2,000), 10% duty ($2,001-$10,000)
C
Explanation:
Equivalence partitioning is a technique that divides the input domain of a system into partitions or classes that are expected to behave similarly or produce similar outputs2. A test case can cover one value from each partition, as it is assumed that all values in the same partition are equivalent for testing purposes2. In this question, the groups of numbers fall into different equivalence classes based on the amount of customs duty to be paid, as shown below:
Group Equivalence Classes
$20,000 $20,001 $30,001 No duty (up to $2,000), 10% duty ($2,001-$10,000), 12% duty ($10,001-$30,000), 17% duty (above $30,000)
$2,000 $2,001 $10,000 No duty (up to $2,000), 10% duty ($2,001-$10,000), 12% duty ($10,001-$30,000)
$2,000 $8,000 $20,000 No duty (up to $2,000), 10% duty ($2,001-$10,000), 12% duty ($10,001-$30,000)
$1,500 $2,000 $10,000 No duty (up to $2,000), 10% duty ($2,001-$10,000)
Question #95
What are metrics NOT used for?
- A . To identify the percentage of work done in test environment preparation.
- B . To identify the percentage of work done in test case preparation.
- C . To apply to the RAD development model.
- D . To measure whether dates of test milestones were met.
Correct Answer: C
C
Explanation:
To apply to the RAD development model. Metrics are quantitative measures that can be used to monitor, control, and improve the test process and the quality of the system. Metrics can be used for various purposes, such as to identify the percentage of work done in test environment preparation or test case preparation, to measure whether dates of test milestones were met, to compare actual results with expected results, to evaluate the effectiveness and efficiency of testing, etc. However, metrics are not specific to any development model, such as RAD (Rapid Application Development), and can be applied to any type of software development project. A detailed explanation of metrics can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 103-105.
C
Explanation:
To apply to the RAD development model. Metrics are quantitative measures that can be used to monitor, control, and improve the test process and the quality of the system. Metrics can be used for various purposes, such as to identify the percentage of work done in test environment preparation or test case preparation, to measure whether dates of test milestones were met, to compare actual results with expected results, to evaluate the effectiveness and efficiency of testing, etc. However, metrics are not specific to any development model, such as RAD (Rapid Application Development), and can be applied to any type of software development project. A detailed explanation of metrics can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 103-105.
Question #96
Which of the following is a white box testing design characteristic?
- A . To be based on specifications
- B . To be based on an analysis of the test basis documentation
- C . To be based on an analysis of the structure of the component or system
- D . To include both functional and non-functional testing
Correct Answer: C
C
Explanation:
To be based on an analysis of the structure of the component or system. White box testing techniques are based on the internal structure and code of the system, not on its specifications or functionality. White box testing techniques include statement coverage, decision coverage, branch coverage, path coverage, etc. White box testing techniques are usually performed at lower levels of testing, such as unit testing or component testing. A detailed explanation of white box testing techniques can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 68-74.
C
Explanation:
To be based on an analysis of the structure of the component or system. White box testing techniques are based on the internal structure and code of the system, not on its specifications or functionality. White box testing techniques include statement coverage, decision coverage, branch coverage, path coverage, etc. White box testing techniques are usually performed at lower levels of testing, such as unit testing or component testing. A detailed explanation of white box testing techniques can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 68-74.
Question #97
In a system designed to work out the employee tax to be paid:
_ An employee has $4,000 of salary tax free.
_ The next $1,500 is taxed at 10%.
_ The next $28,000 after that is taxed at 22%.
_ Any further amount is taxed at 40%.
Which of these is a valid Boundary Value Analysis test case?
- A . $28,000
- B . $1,500
- C . $33,501
- D . $5,000
Correct Answer: C
C
Explanation:
Boundary Value Analysis is a black-box testing technique that is used to test the boundaries or limits of input or output values for a given system or component. Boundary Value Analysis helps to identify errors at the edges of an input or output domain. For example, in a system designed to work out the employee tax to be paid, there are four boundaries for the salary input: $4,000 (lower boundary for tax free), $5,500 (upper boundary for tax free and lower boundary for 10% tax), $34,000 (upper boundary for 10% tax and lower boundary for 22% tax), and any value above $34,000 (upper boundary for 22% tax and lower boundary for 40% tax). A valid Boundary Value Analysis test case would test one value below, on, and above each boundary. For example, $33,501 is a valid test case because it is one value above the boundary of $34,000. A detailed explanation of Boundary Value Analysis can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 38-41.
C
Explanation:
Boundary Value Analysis is a black-box testing technique that is used to test the boundaries or limits of input or output values for a given system or component. Boundary Value Analysis helps to identify errors at the edges of an input or output domain. For example, in a system designed to work out the employee tax to be paid, there are four boundaries for the salary input: $4,000 (lower boundary for tax free), $5,500 (upper boundary for tax free and lower boundary for 10% tax), $34,000 (upper boundary for 10% tax and lower boundary for 22% tax), and any value above $34,000 (upper boundary for 22% tax and lower boundary for 40% tax). A valid Boundary Value Analysis test case would test one value below, on, and above each boundary. For example, $33,501 is a valid test case because it is one value above the boundary of $34,000. A detailed explanation of Boundary Value Analysis can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 38-41.
Question #98
What is a test condition?
- A . A statement of test objectives and test ideas on how to test.
- B . An item or event that could be verified by one or more test cases.
- C . The process of identifying differences between the actual results and the expected results for a test.
- D . All documents from which the requirements of a component or system can be inferred.
Correct Answer: B
B
Explanation:
An item or event that could be verified by one or more test cases. A test condition is a general term that refers to anything that can be tested by a test case, such as a requirement, a function, a feature, a use case, a user story, etc. A test condition is derived from the test basis (the source of information for testing) and serves as an input for test design and test case creation. A test condition can be expressed in natural language or in a formal notation. A detailed explanation of test condition can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 17-18.
B
Explanation:
An item or event that could be verified by one or more test cases. A test condition is a general term that refers to anything that can be tested by a test case, such as a requirement, a function, a feature, a use case, a user story, etc. A test condition is derived from the test basis (the source of information for testing) and serves as an input for test design and test case creation. A test condition can be expressed in natural language or in a formal notation. A detailed explanation of test condition can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 17-18.
Question #99
Which of the following test organizations has the highest level of independence?
- A . Independent testers within the development teams
- B . Independent testers from the user community
- C . Independent test specialists for specific test types, such as usability, performance or certification test specialists
- D . Code tested by another developer from the development team
Correct Answer: C
C
Explanation:
The test organization that has the highest level of independence is C. Independent test specialists for specific test types, such as usability, performance or certification test specialists. Test independence refers to the degree of separation between the tester and the developer or user of the system or component under test. Test independence can help to reduce bias and increase objectivity in testing. Independent test specialists are testers who have specialized skills and knowledge in specific test types or domains and who are not involved in the development or use of the system or component under test. Independent test specialists can provide more reliable and accurate results than testers who are part of the development team or user community. A detailed explanation of test independence can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 9-10.
C
Explanation:
The test organization that has the highest level of independence is C. Independent test specialists for specific test types, such as usability, performance or certification test specialists. Test independence refers to the degree of separation between the tester and the developer or user of the system or component under test. Test independence can help to reduce bias and increase objectivity in testing. Independent test specialists are testers who have specialized skills and knowledge in specific test types or domains and who are not involved in the development or use of the system or component under test. Independent test specialists can provide more reliable and accurate results than testers who are part of the development team or user community. A detailed explanation of test independence can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 9-10.
Question #100
Which of the following would NOT be a typical target of testing support tools?
- A . Automate activities that require significant resources when done manually
- B . Automate activities that cannot be executed manually
- C . Automate repetitive tasks
- D . Automating repetitive inspections
Correct Answer: D
D
Explanation:
Testing support tools are software tools that assist testers in performing testing activities, such as test management, test design, test execution, test evaluation, and defect management1. According to the ISTQB syllabus, some typical targets of testing support tools are to automate activities that require significant resources when done manually, automate activities that cannot be executed manually, and automate repetitive tasks1. Automating repetitive inspections is not a typical target of testing support tools, as inspections are static testing techniques that involve human review and analysis of software artifacts1.
D
Explanation:
Testing support tools are software tools that assist testers in performing testing activities, such as test management, test design, test execution, test evaluation, and defect management1. According to the ISTQB syllabus, some typical targets of testing support tools are to automate activities that require significant resources when done manually, automate activities that cannot be executed manually, and automate repetitive tasks1. Automating repetitive inspections is not a typical target of testing support tools, as inspections are static testing techniques that involve human review and analysis of software artifacts1.
Question #101
What type of test design technique is the most effective in testing screen-dialog flows?
- A . Use case testing
- B . Boundary value testing
- C . Statement testing and coverage
- D . State transition testing
Correct Answer: A
A
Explanation:
Screen-dialog flows are sequences of screens and dialogs that represent the user interface and interaction of a system. Use case testing is a technique that uses use cases as a test basis to derive test cases1. A use case is a description of interactions between actors and a system to achieve a goal1. Use case testing is the most effective technique in testing screen-dialog flows, as it can capture the user requirements, scenarios, and expected outcomes of the system. Boundary value testing is a technique that uses boundary values as a test basis to derive test cases1. A boundary value is an input value or output value on the edge of an equivalence partition or at the smallest or largest value of a range1. Boundary value testing is not the most effective technique in testing screen-dialog flows, as it is more suitable for testing numerical inputs and outputs. Statement testing and coverage is a technique that uses statements in the source code as a test basis to measure the coverage achieved by a test suite1. A statement is a minimal executable unit of source code1. Statement testing and coverage is not the most effective technique in testing screen-dialog flows, as it is more suitable for testing the internal logic and structure of the code. State transition testing is a technique that uses state transition diagrams as a test basis to derive test cases1. A state transition diagram shows the states of a system and the transitions between them triggered by events or conditions1. State transition testing is not the most effective technique in testing screen-dialog flows, as it is more suitable for testing systems that have complex or dynamic behavior based on different states.
A
Explanation:
Screen-dialog flows are sequences of screens and dialogs that represent the user interface and interaction of a system. Use case testing is a technique that uses use cases as a test basis to derive test cases1. A use case is a description of interactions between actors and a system to achieve a goal1. Use case testing is the most effective technique in testing screen-dialog flows, as it can capture the user requirements, scenarios, and expected outcomes of the system. Boundary value testing is a technique that uses boundary values as a test basis to derive test cases1. A boundary value is an input value or output value on the edge of an equivalence partition or at the smallest or largest value of a range1. Boundary value testing is not the most effective technique in testing screen-dialog flows, as it is more suitable for testing numerical inputs and outputs. Statement testing and coverage is a technique that uses statements in the source code as a test basis to measure the coverage achieved by a test suite1. A statement is a minimal executable unit of source code1. Statement testing and coverage is not the most effective technique in testing screen-dialog flows, as it is more suitable for testing the internal logic and structure of the code. State transition testing is a technique that uses state transition diagrams as a test basis to derive test cases1. A state transition diagram shows the states of a system and the transitions between them triggered by events or conditions1. State transition testing is not the most effective technique in testing screen-dialog flows, as it is more suitable for testing systems that have complex or dynamic behavior based on different states.
Question #102
What content would be in an incident report if that incident report was based on the IEEE 829 Standard for SoftwareTest Documentation?
(i) Identification of configuration items of the software or system.
(ii) Software or system lifecycle process in which the incident was observed.
(iii) Description of the anomaly to enable reproduction of the incident.
(iv) Number of occurrences of the incident.
(v) Classification of the cause of the incident for metrics and for reporting purposes.
Number of correct answers: 1
- A . i, ii, iii
- B . ii, iii
- C . i, iii, iv
- D . i, ii, iii, v
Correct Answer: C
C
Explanation:
According to the IEEE 829 Standard for Software Test Documentation, an incident report should contain the following information:
Identifier: A unique identifier for the incident report
Summary: A brief summary of the incident
Incident description: A description of the incident, including:
Date: The date when the incident was observed
Author: The name of the person who reported the incident
Source: The software or system lifecycle process in which the incident was observed
Version: The identification of configuration items of the software or system
Test case: The identification of the test case that caused the incident
Execution phase: The phase of test execution when the incident was observed
Environment: The hardware and software environment in which the incident was observed
Description: A description of the anomaly to enable reproduction of the incident
Expected result: The expected result of the test case
Actual result: The actual result of the test case
Reproducibility: An indication of whether the incident can be reproduced or not
Impact analysis: An analysis of the impact of the incident on other aspects of the software or system
Incident resolution: A description of how the incident was resolved, including:
Resolution date: The date when the incident was resolved
Resolver: The name of the person who resolved the incident
Resolution summary: A brief summary of how the incident was resolved
Status: The current status of the incident (e.g., open, closed, deferred)
Classification information: A classification of the cause and effect of the incident for metrics and reporting purposes
Therefore, among the options given in this question, only (i), (iii), and (iv) are part of an incident report based on IEEE 829.
C
Explanation:
According to the IEEE 829 Standard for Software Test Documentation, an incident report should contain the following information:
Identifier: A unique identifier for the incident report
Summary: A brief summary of the incident
Incident description: A description of the incident, including:
Date: The date when the incident was observed
Author: The name of the person who reported the incident
Source: The software or system lifecycle process in which the incident was observed
Version: The identification of configuration items of the software or system
Test case: The identification of the test case that caused the incident
Execution phase: The phase of test execution when the incident was observed
Environment: The hardware and software environment in which the incident was observed
Description: A description of the anomaly to enable reproduction of the incident
Expected result: The expected result of the test case
Actual result: The actual result of the test case
Reproducibility: An indication of whether the incident can be reproduced or not
Impact analysis: An analysis of the impact of the incident on other aspects of the software or system
Incident resolution: A description of how the incident was resolved, including:
Resolution date: The date when the incident was resolved
Resolver: The name of the person who resolved the incident
Resolution summary: A brief summary of how the incident was resolved
Status: The current status of the incident (e.g., open, closed, deferred)
Classification information: A classification of the cause and effect of the incident for metrics and reporting purposes
Therefore, among the options given in this question, only (i), (iii), and (iv) are part of an incident report based on IEEE 829.
Question #103
“Experience based" test design techniques, typically…
- A . Use decision tables to generate the Boolean test conditions to be executed.
- B . Identify the structure of the system or software at the component, integration or system level.
- C . Use the skill, intuition and experience of the tester to derive the test cases, using error guessing and exploratory testing.
- D . Establish traceability from test conditions back to the specifications and requirements.
Correct Answer: C
C
Explanation:
Experience-based test design techniques are techniques that use the skill, intuition, and experience of testers to derive test cases, using error guessing and exploratory testing1. Error guessing is a technique that uses common sense and previous experience to guess where defects might occur in a system1. Exploratory testing is an approach that involves simultaneous learning, test design, and test execution1. Experience-based test design techniques are typically used when there is insufficient information or time to apply other more formal techniques1. They do not use decision tables, identify the structure of the system or software, or establish traceability from test conditions back to the specifications and requirements.
C
Explanation:
Experience-based test design techniques are techniques that use the skill, intuition, and experience of testers to derive test cases, using error guessing and exploratory testing1. Error guessing is a technique that uses common sense and previous experience to guess where defects might occur in a system1. Exploratory testing is an approach that involves simultaneous learning, test design, and test execution1. Experience-based test design techniques are typically used when there is insufficient information or time to apply other more formal techniques1. They do not use decision tables, identify the structure of the system or software, or establish traceability from test conditions back to the specifications and requirements.
Question #104
Testers are often seen as the bearer of unwanted news regarding defects.
What are effective ways to improve the communication and relationship between testers and others?
a) Communicate factual information in a constructive way.
b) Try to understand how the other person feels and why they react the way they do.
c) Always outsource testing activities.
d) Never record information that could be used to apportion blame to an individual or team.
- A . a and b
- B . a, b and c
- C . a, b and d
- D . a and c
Correct Answer: A
A
Explanation:
The effective ways to improve the communication and relationship between testers and others are A. a and b. Communicating factual information in a constructive way and trying to understand how the other person feels and why they react the way they do are both important skills for testers to have. Testers often have to report defects and problems that may not be well received by developers or users. Therefore, testers should communicate in a clear, objective, and respectful manner, avoiding personal attacks or blame. Testers should also empathize with the other person’s perspective and emotions, and try to resolve any conflicts or misunderstandings in a positive way. A detailed explanation of communication skills for testers can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 107-108.
A
Explanation:
The effective ways to improve the communication and relationship between testers and others are A. a and b. Communicating factual information in a constructive way and trying to understand how the other person feels and why they react the way they do are both important skills for testers to have. Testers often have to report defects and problems that may not be well received by developers or users. Therefore, testers should communicate in a clear, objective, and respectful manner, avoiding personal attacks or blame. Testers should also empathize with the other person’s perspective and emotions, and try to resolve any conflicts or misunderstandings in a positive way. A detailed explanation of communication skills for testers can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 107-108.
Question #105
Which of the following is a valid reason for writing test cases based on experience and intuition? [K1]
- A . Use of formal techniques requires expensive training
- B . Only experience can ensure all functionality is covered
- C . Tests based on experience and intuition can supplement formal techniques
- D . Formal techniques require the use of expensive tools
Correct Answer: C
C
Explanation:
A valid reason for writing test cases based on experience and intuition is C. Tests based on experience and intuition can supplement formal techniques. Experience and intuition are valuable sources of test ideas that can help testers to identify potential risks, errors, or scenarios that may not be covered by formal techniques. Formal techniques are systematic methods that use rules or algorithms to derive test cases from the test basis (such as specifications, code, etc.). Formal techniques include black-box techniques (such as equivalence partitioning, boundary value analysis, etc.) and white-box techniques (such as statement coverage, decision coverage, etc.). Formal techniques can provide a high level of coverage and consistency, but they may not be able to capture all possible situations or behaviors of the system or component under test. Therefore, tests based on experience and intuition can supplement formal techniques by adding more diversity and creativity to the test cases. A detailed explanation of experience-based testing techniques can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 74-76.
C
Explanation:
A valid reason for writing test cases based on experience and intuition is C. Tests based on experience and intuition can supplement formal techniques. Experience and intuition are valuable sources of test ideas that can help testers to identify potential risks, errors, or scenarios that may not be covered by formal techniques. Formal techniques are systematic methods that use rules or algorithms to derive test cases from the test basis (such as specifications, code, etc.). Formal techniques include black-box techniques (such as equivalence partitioning, boundary value analysis, etc.) and white-box techniques (such as statement coverage, decision coverage, etc.). Formal techniques can provide a high level of coverage and consistency, but they may not be able to capture all possible situations or behaviors of the system or component under test. Therefore, tests based on experience and intuition can supplement formal techniques by adding more diversity and creativity to the test cases. A detailed explanation of experience-based testing techniques can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 74-76.
Question #106
Which of the following test design techniques is classified as a structure-based (white box) technique? [K1]
- A . Exploratory testing
- B . Decision table testing
- C . State transition testing
- D . Statement testing
Correct Answer: D
D
Explanation:
A white box testing design technique is D. Statement testing. Statement testing is a white box testing technique that is based on an analysis of the structure of the component or system. Statement testing aims to cover every executable statement in the code at least once by the test cases. Statement testing can help to detect syntax errors, logic errors, or unreachable code in the system or component under test. Statement testing is usually performed at lower levels of testing, such as unit testing or component testing. A detailed explanation of statement testing can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 68-69.
D
Explanation:
A white box testing design technique is D. Statement testing. Statement testing is a white box testing technique that is based on an analysis of the structure of the component or system. Statement testing aims to cover every executable statement in the code at least once by the test cases. Statement testing can help to detect syntax errors, logic errors, or unreachable code in the system or component under test. Statement testing is usually performed at lower levels of testing, such as unit testing or component testing. A detailed explanation of statement testing can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 68-69.
Question #107
Why is independent testing important? [K1]
- A . Because independent testers make fewer assumptions than developers
- B . Because independent testers are isolated from the development team
- C . Because independent testers can verify assumptions made during specification and implementation of the system
- D . Because independent testers have a greater sense of responsibility for quality than developers
Correct Answer: C
C
Explanation:
Independent testing is important because C. Independent testers can verify assumptions made during specification and implementation of the system. Independent testing refers to testing performed by testers who are not involved in the development or use of the system or component under test. Independent testers can provide an unbiased and objective view of the quality of the system or component under test. Independent testers can also verify assumptions made by developers or users during specification and implementation of the system or component under test. Assumptions are statements that are believed to be true without proof or verification. Assumptions can lead to errors or defects if they are incorrect or inconsistent with reality. Independent testers can help to identify and validate assumptions by using different sources of information, such as requirements, specifications, standards, regulations, etc., and by applying different testing techniques, such as black-box techniques, white-box techniques, etc. A detailed explanation of independent testing can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 9-10.
C
Explanation:
Independent testing is important because C. Independent testers can verify assumptions made during specification and implementation of the system. Independent testing refers to testing performed by testers who are not involved in the development or use of the system or component under test. Independent testers can provide an unbiased and objective view of the quality of the system or component under test. Independent testers can also verify assumptions made by developers or users during specification and implementation of the system or component under test. Assumptions are statements that are believed to be true without proof or verification. Assumptions can lead to errors or defects if they are incorrect or inconsistent with reality. Independent testers can help to identify and validate assumptions by using different sources of information, such as requirements, specifications, standards, regulations, etc., and by applying different testing techniques, such as black-box techniques, white-box techniques, etc. A detailed explanation of independent testing can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 9-10.
Question #108
Which statement BEST describes when test planning should be performed? [K1]
- A . Test planning is performed only once, at the beginning of the life cycle, andgenerates a Master Test Plan
- B . Test planning is performed at the beginning of the life cycle and again at the beginning of test execution
- C . Test planning is performed at the beginning of the life cycle and again at every test level
- D . Test planning is performed continuously in all life cycle processes and activities
Correct Answer: D
D
Explanation:
The statement that BEST describes when test planning should be performed is D. Test planning is performed continuously in all life cycle processes and activities. Test planning is the process of defining the objectives, scope, approach, resources, schedule, risks, and deliverables for testing activities. Test planning is not a one-time activity that is done only at the beginning of the life cycle or at each test level. Test planning is a continuous activity that is done throughout the life cycle in all processes and activities that involve testing. Test planning should be aligned with the development process and should be updated regularly to reflect any changes or feedback from previous testing activities. Test planning should also consider different levels of testing (such as unit testing, integration testing, system testing, acceptance testing, etc.) and different types of testing (such as functional testing, non-functional testing, regression testing, etc.). A detailed explanation of test planning can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 13-15.
D
Explanation:
The statement that BEST describes when test planning should be performed is D. Test planning is performed continuously in all life cycle processes and activities. Test planning is the process of defining the objectives, scope, approach, resources, schedule, risks, and deliverables for testing activities. Test planning is not a one-time activity that is done only at the beginning of the life cycle or at each test level. Test planning is a continuous activity that is done throughout the life cycle in all processes and activities that involve testing. Test planning should be aligned with the development process and should be updated regularly to reflect any changes or feedback from previous testing activities. Test planning should also consider different levels of testing (such as unit testing, integration testing, system testing, acceptance testing, etc.) and different types of testing (such as functional testing, non-functional testing, regression testing, etc.). A detailed explanation of test planning can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 13-15.
Question #109
Refer to the exhibit
The following test cases need to be run, but time is limited, and it is possible that not all will be completed before the end of the test window
The first activity is to run any re-tests, followed by the regression test script. Users have supplied their priority order to tests.
Which of the following gives an appropriate test execution schedule, taking account of the prioritisation and other constraints? [K3]
- A . b, c, g, d, e, i, a, f, h
- B . a, c, d, b, g, e, i, f, h
- C . c, a, d, b, e, g, i, h, f
- D . d, c, a, e, b, g, i, f, h
Correct Answer: C
C
Explanation:
The test execution schedule should take into account the prioritization and other constraints given in the question. The first activity is to run any re-tests, followed by the regression test script. Users have supplied their priority order to tests. Therefore, the test execution schedule should start with the re-test defect no 52, which is shown in the image as a table with 9 rows and 4 columns. The table is titled “Re-test defect no 52”. The columns are labeled: “#”, “Description”, “Priority”, “Note”, “Re-test”. The table is populated with data about different tasks and their priority and notes. The tasks are related to sales figures and account administration. The table is in black and white. The re-test defect no 52 has three tasks: c, a, and d, which have priority 1, 2, and 3 respectively. Therefore, the test execution schedule should start with c, followed by a, and then d. After that, the regression test script should be run, which is task e. Then, the remaining tasks should be run according to the user priority order: b, g, i, h, and f. Therefore, the test execution schedule is c, a, d, e, b, g, i, h, and f.
C
Explanation:
The test execution schedule should take into account the prioritization and other constraints given in the question. The first activity is to run any re-tests, followed by the regression test script. Users have supplied their priority order to tests. Therefore, the test execution schedule should start with the re-test defect no 52, which is shown in the image as a table with 9 rows and 4 columns. The table is titled “Re-test defect no 52”. The columns are labeled: “#”, “Description”, “Priority”, “Note”, “Re-test”. The table is populated with data about different tasks and their priority and notes. The tasks are related to sales figures and account administration. The table is in black and white. The re-test defect no 52 has three tasks: c, a, and d, which have priority 1, 2, and 3 respectively. Therefore, the test execution schedule should start with c, followed by a, and then d. After that, the regression test script should be run, which is task e. Then, the remaining tasks should be run according to the user priority order: b, g, i, h, and f. Therefore, the test execution schedule is c, a, d, e, b, g, i, h, and f.
Question #110
Which of the following factors will MOST affect the testing effort required to test a software product? [K1]
- A . The number of staff available to execute tests
- B . The level of detail in the test plan
- C . The requirements for reliability and security in the product
- D . The test estimation method used
Correct Answer: C
C
Explanation:
The testing effort required to test a software product depends on various factors, such as the size and complexity of the product, the quality of the requirements and design documents, the testability of the product, the test strategy and scope, the test environment and tools, the skills and experience of the testers, and the quality expectations and standards of the stakeholders1. Among these factors, the requirements for reliability and security in the product will most affect the testing effort required to test a software product1. Reliability and security are quality attributes that measure how well a software product performs its intended functions under specified conditions and protects itself from unauthorized access or harm1. Testing for reliability and security requires more rigorous and thorough testing techniques, such as reliability testing, security testing, penetration testing, stress testing, etc1. These techniques may require more time, resources, tools, and skills to perform effectively1. Therefore, the requirements for reliability and security in the product will most affect the testing effort required to test a software product.
C
Explanation:
The testing effort required to test a software product depends on various factors, such as the size and complexity of the product, the quality of the requirements and design documents, the testability of the product, the test strategy and scope, the test environment and tools, the skills and experience of the testers, and the quality expectations and standards of the stakeholders1. Among these factors, the requirements for reliability and security in the product will most affect the testing effort required to test a software product1. Reliability and security are quality attributes that measure how well a software product performs its intended functions under specified conditions and protects itself from unauthorized access or harm1. Testing for reliability and security requires more rigorous and thorough testing techniques, such as reliability testing, security testing, penetration testing, stress testing, etc1. These techniques may require more time, resources, tools, and skills to perform effectively1. Therefore, the requirements for reliability and security in the product will most affect the testing effort required to test a software product.
Question #111
Which of the following metrics could be used to monitor progress along with test preparation and execution? [K1]
- A . The total number of tests planned
- B . The total number of requirements to be tested
- C . The failure rate in testing already completed
- D . The number of testers used for test execution so far
Correct Answer: C
C
Explanation:
Metrics are quantitative measures that can be used to monitor and control various aspects of software testing processes and products1. Metrics can be used to monitor progress along with test preparation and execution by providing information about the status of testing activities, such as test planning, test design, test execution, test evaluation, defect management, etc1. Among the options given in this question, only C is a suitable metric for monitoring progress along with test preparation and execution. The failure rate in testing already completed is a metric that measures how many tests have failed out of the total number of tests executed1. This metric can indicate the quality of the software product under test and the effectiveness of the test cases1. It can also help to identify areas that need more attention or improvement in testing1. Therefore, this metric can be used to monitor progress along with test preparation and execution.
C
Explanation:
Metrics are quantitative measures that can be used to monitor and control various aspects of software testing processes and products1. Metrics can be used to monitor progress along with test preparation and execution by providing information about the status of testing activities, such as test planning, test design, test execution, test evaluation, defect management, etc1. Among the options given in this question, only C is a suitable metric for monitoring progress along with test preparation and execution. The failure rate in testing already completed is a metric that measures how many tests have failed out of the total number of tests executed1. This metric can indicate the quality of the software product under test and the effectiveness of the test cases1. It can also help to identify areas that need more attention or improvement in testing1. Therefore, this metric can be used to monitor progress along with test preparation and execution.
Question #112
Test objectives for systems testing of a safety critical system include completion of all outstanding defect correction. Regression testing is required following defect correction at all test levels.
Which TWO of the following metrics would be MOST suitable for determining whether the test objective has been met? [K2]
a. Regression tests run and passed in systems testing
b. Incidents closed in systems testing
c. Planned tests run and passed in system testing
d. Planned tests run and passed at all levels of testing
e. Incidents raised and closed at all levels of testing
- A . a and e
- B . b and c
- C . d and e
- D . a and b
Correct Answer: A
A
Explanation:
Test objectives are specific goals or targets that define what testing activities should achieve or accomplish1. Test objectives for systems testing of a safety critical system include completion of all outstanding defect correction. Regression testing is required following defect correction at all test levels.
Therefore, to determine whether this test objective has been met, two metrics that would be most suitable are:
Regression tests run and passed in systems testing: This metric measures how many regression tests have been executed and passed in systems testing1. Regression testing is a type of testing that verifies that previously tested software still performs correctly after changes or defect corrections1. This metric can indicate whether all outstanding defect corrections have been completed and verified in systems testing.
Incidents raised and closed at all levels of testing: This metric measures how many incidents have been reported and resolved at all levels of testing1. An incident is any event occurring during testing that requires investigation1. This metric can indicate whether all defects have been identified and corrected at all levels of testing.
A
Explanation:
Test objectives are specific goals or targets that define what testing activities should achieve or accomplish1. Test objectives for systems testing of a safety critical system include completion of all outstanding defect correction. Regression testing is required following defect correction at all test levels.
Therefore, to determine whether this test objective has been met, two metrics that would be most suitable are:
Regression tests run and passed in systems testing: This metric measures how many regression tests have been executed and passed in systems testing1. Regression testing is a type of testing that verifies that previously tested software still performs correctly after changes or defect corrections1. This metric can indicate whether all outstanding defect corrections have been completed and verified in systems testing.
Incidents raised and closed at all levels of testing: This metric measures how many incidents have been reported and resolved at all levels of testing1. An incident is any event occurring during testing that requires investigation1. This metric can indicate whether all defects have been identified and corrected at all levels of testing.
Question #113
Test script TransVal 3.1 tests transaction validation via screen TRN 003B. According to the specification (PID ver 1.3 10b iv) the validation screen should not accept future dated transactions. Test script TransVal 3.1 passes. Test script eod 1.4 tests end of day processing and is run after the execution of TransVal 3.1 using data entered during that test
Which of the following is the BEST detail on an incident report? [K3]
- A . Title. End of Day failure.. Reproducible. Yes. Description. Script eod 1.4 fails when the first transaction of the day is a future dated transaction. Screen shot of the failure attached.
- B . Title. Transaction input screen validation..Reproducible. Yes. Description. Script eod 1..4 fails. Screen shot of the failure attached. Validation of transaction entryon screen TRN-003B should not allow future dated transactions C see PID ver 1.3 para 10b iv.
- C . Title. Screen TRN-003B validation of transaction date.. Reproducible. No. Description. When a future dated transaction is processed by the end of day process, a failure can occur. This does not always happen. Screen shot of the failure attached.
- D . Title. Screen TRN-003B validation of transaction date. Reproducible. Yes. Description. Script eod 1.4 fails when the first transaction of the day is a future dated transaction. Screen shot of the failure attached. Validation of transaction entry on screen TRN-003B should not allow future dated transactions C see PID ver 1.3 para 10b iv.
Correct Answer: D
D
Explanation:
An incident report is a document that records any event occurring during testing that requires investigation1. An incident report should contain sufficient information to enable reproduction of the incident and resolution of the defect1. According to IEEE 829 Standard for Software Test Documentation, an incident report should contain the following information: Identifier: A unique identifier for the incident report
Summary: A brief summary of the incident
Incident description: A description of the incident, including:
Date: The date when the incident was observed
Author: The name of the person who reported the incident
Source: The software or system lifecycle process in which the incident was observed
Version: The identification of configuration items of the software or system
Test case: The identification of the test case that caused the incident
Execution phase: The phase of test execution when the incident was observed
Environment: The hardware and software environment in which the incident was observed
Description: A description of the anomaly to enable reproduction of the incident
Expected result: The expected result of the test case
Actual result: The actual result of the test case
Reproducibility: An indication of whether the incident can be reproduced or not
Impact analysis: An analysis of the impact of the incident on other aspects of the software or system
Incident resolution: A description of how the incident was resolved, including:
Resolution date: The date when the incident was resolved
Resolver: The name of the person who resolved the incident
Resolution summary: A brief summary of how the incident was resolved
Status: The current status of the incident (e.g., open, closed, deferred)
Classification information: A classification of the cause and effect of the incident for metrics and reporting purposes
Therefore, among the options given in this question, only D provides the best detail on an incident report. It contains a clear title, a reproducibility indicator, a description that includes both expected and actual results, a reference to the specification document, and a screen shot of the failure. The other options are either missing some important information or providing inaccurate or irrelevant information
D
Explanation:
An incident report is a document that records any event occurring during testing that requires investigation1. An incident report should contain sufficient information to enable reproduction of the incident and resolution of the defect1. According to IEEE 829 Standard for Software Test Documentation, an incident report should contain the following information: Identifier: A unique identifier for the incident report
Summary: A brief summary of the incident
Incident description: A description of the incident, including:
Date: The date when the incident was observed
Author: The name of the person who reported the incident
Source: The software or system lifecycle process in which the incident was observed
Version: The identification of configuration items of the software or system
Test case: The identification of the test case that caused the incident
Execution phase: The phase of test execution when the incident was observed
Environment: The hardware and software environment in which the incident was observed
Description: A description of the anomaly to enable reproduction of the incident
Expected result: The expected result of the test case
Actual result: The actual result of the test case
Reproducibility: An indication of whether the incident can be reproduced or not
Impact analysis: An analysis of the impact of the incident on other aspects of the software or system
Incident resolution: A description of how the incident was resolved, including:
Resolution date: The date when the incident was resolved
Resolver: The name of the person who resolved the incident
Resolution summary: A brief summary of how the incident was resolved
Status: The current status of the incident (e.g., open, closed, deferred)
Classification information: A classification of the cause and effect of the incident for metrics and reporting purposes
Therefore, among the options given in this question, only D provides the best detail on an incident report. It contains a clear title, a reproducibility indicator, a description that includes both expected and actual results, a reference to the specification document, and a screen shot of the failure. The other options are either missing some important information or providing inaccurate or irrelevant information
Question #114
Which TWO of the following test tools would be classified as test execution tools? [K2]
a. Test data preparation tools
b. Test harness
c. Review tools
d. Test comparators
e. Configuration management tools
- A . a and b
- B . c and d
- C . c and e
- D . b and d
Correct Answer: D
D
Explanation:
The test tools that would be classified as test execution tools are D. b and d. Test execution tools are tools that automate the execution of test cases or test scripts, and compare the actual results with the expected results. Test execution tools can also record and replay user actions, generate test data, and report test results. Test harness and test comparators are examples of test execution tools. A test harness is a tool that creates a test environment for a component or system under test, by simulating the required dependencies, such as stubs, drivers, or mock objects. A test comparator is a tool that compares the actual outputs of a component or system under test with the expected outputs, and reports any differences or anomalies. A detailed explanation of test execution tools can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 111-1121.
D
Explanation:
The test tools that would be classified as test execution tools are D. b and d. Test execution tools are tools that automate the execution of test cases or test scripts, and compare the actual results with the expected results. Test execution tools can also record and replay user actions, generate test data, and report test results. Test harness and test comparators are examples of test execution tools. A test harness is a tool that creates a test environment for a component or system under test, by simulating the required dependencies, such as stubs, drivers, or mock objects. A test comparator is a tool that compares the actual outputs of a component or system under test with the expected outputs, and reports any differences or anomalies. A detailed explanation of test execution tools can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 111-1121.
Question #115
Which of the following is a consideration when deploying test execution tools? [K1]
- A . Data-driven testing cannot be used with test execution tools
- B . Recorded manual tests may become unstable in use
- C . Keyword-driven testing cannot be used with test execution tools
- D . Expected results for tests are not required because the tool generates expected results
Correct Answer: B
B
Explanation:
A consideration when deploying test execution tools is B. Recorded manual tests may become unstable in use. Test execution tools can record manual tests performed by a tester and replay them automatically on demand. However, recorded manual tests may become unstable or unreliable in use, due to various factors, such as changes in the system under test, changes in the test environment, changes in the user interface, timing issues, synchronization issues, etc. Therefore, recorded manual tests may require frequent maintenance or modification to keep them up to date and consistent with the system under test. A detailed explanation of recorded manual tests can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 112-113
B
Explanation:
A consideration when deploying test execution tools is B. Recorded manual tests may become unstable in use. Test execution tools can record manual tests performed by a tester and replay them automatically on demand. However, recorded manual tests may become unstable or unreliable in use, due to various factors, such as changes in the system under test, changes in the test environment, changes in the user interface, timing issues, synchronization issues, etc. Therefore, recorded manual tests may require frequent maintenance or modification to keep them up to date and consistent with the system under test. A detailed explanation of recorded manual tests can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 112-113
Question #116
Which of the following correctly states a limitation in the use of static analysis tools? [K1]
- A . Static analysis tools can be applied to new code but cannot be applied to existing code
- B . Static analysis tools can be used to enforce coding standards
- C . Static analysis tools always generate large numbers of warning messages when applied to new code, even if the code meets coding standards
- D . Static analysis tools do not generate warning messages when applied to existing code
Correct Answer: C
C
Explanation:
A limitation in the use of static analysis tools is C. Static analysis tools always generate large numbers of warning messages when applied to new code, even if the code meets coding standards. Static analysis tools are tools that analyze the code or other software artifacts without executing them, and report any defects, errors, vulnerabilities, or violations of coding standards or conventions. Static analysis tools can help to improve the quality and maintainability of the code or other software artifacts. However, static analysis tools also have some limitations, such as generating large numbers of warning messages when applied to new code, even if the code meets coding standards or conventions. This can make it difficult for developers or testers to identify and prioritize the most important or critical issues to fix or address. A detailed explanation of static analysis tools can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 109-1101.
C
Explanation:
A limitation in the use of static analysis tools is C. Static analysis tools always generate large numbers of warning messages when applied to new code, even if the code meets coding standards. Static analysis tools are tools that analyze the code or other software artifacts without executing them, and report any defects, errors, vulnerabilities, or violations of coding standards or conventions. Static analysis tools can help to improve the quality and maintainability of the code or other software artifacts. However, static analysis tools also have some limitations, such as generating large numbers of warning messages when applied to new code, even if the code meets coding standards or conventions. This can make it difficult for developers or testers to identify and prioritize the most important or critical issues to fix or address. A detailed explanation of static analysis tools can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 109-1101.
Question #117
What is the main reason for using a pilot project to introduce a testing tool into an organization? [K1]
- A . To identify the requirements for using a tool
- B . To make a selection between alternative tools
- C . To assess whether the tool will be cost- effective
- D . To ensure the tools fits existing processes without change
Correct Answer: C
C
Explanation:
The main reason for using a pilot project to introduce a testing tool into an organization is C. To assess whether the tool will be cost-effective. A pilot project is a small-scale trial or experiment that is used to evaluate the feasibility, benefits, risks, and challenges of introducing a testing tool into an organization. A pilot project can help to assess whether the tool will be cost-effective, by comparing the costs of acquiring, deploying, using, and maintaining the tool with the benefits of using the tool, such as increased efficiency, effectiveness, quality, etc. A pilot project can also help to identify any technical, organizational, or human factors that may affect the successful adoption of the tool, and plan for any necessary actions or changes to address them. A detailed explanation of pilot projects can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 115-1161.
C
Explanation:
The main reason for using a pilot project to introduce a testing tool into an organization is C. To assess whether the tool will be cost-effective. A pilot project is a small-scale trial or experiment that is used to evaluate the feasibility, benefits, risks, and challenges of introducing a testing tool into an organization. A pilot project can help to assess whether the tool will be cost-effective, by comparing the costs of acquiring, deploying, using, and maintaining the tool with the benefits of using the tool, such as increased efficiency, effectiveness, quality, etc. A pilot project can also help to identify any technical, organizational, or human factors that may affect the successful adoption of the tool, and plan for any necessary actions or changes to address them. A detailed explanation of pilot projects can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 115-1161.
Question #118
Which of the following BEST describes the relationship between test planning and test execution? [K2]
- A . Test planning ensures the level of detail in test procedures is appropriate for test execution
- B . Test planning schedules test execution but does not assign resources
- C . Test planning defines the overall approach to testing but does not schedule specific activities such as test execution
- D . Test planning identifies test objectives related to scope and risk but does not define the level of detail for test procedures used in test execution
Correct Answer: A
A
Explanation:
The statement that BEST describes the relationship between test planning and test execution is A. Test planning ensures the level of detail in test procedures is appropriate for test execution. Test planning is the process of defining the objectives, scope, approach, resources, schedule, risks, and deliverables for testing activities. Test planning also involves designing and creating test cases and test procedures for test execution. Test procedures are detailed instructions on how to execute each test case and record the results. Test planning ensures that the level of detail in test procedures is appropriate for test execution, by considering factors such as complexity of the system under test, skills and experience of testers, availability of tools and environments, etc. Test planning also ensures that test procedures are consistent with the test objectives and cover all relevant aspects of testing (such as functional testing, non-functional testing, regression testing etc.). A detailed explanation of test planning can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 13-151.
A
Explanation:
The statement that BEST describes the relationship between test planning and test execution is A. Test planning ensures the level of detail in test procedures is appropriate for test execution. Test planning is the process of defining the objectives, scope, approach, resources, schedule, risks, and deliverables for testing activities. Test planning also involves designing and creating test cases and test procedures for test execution. Test procedures are detailed instructions on how to execute each test case and record the results. Test planning ensures that the level of detail in test procedures is appropriate for test execution, by considering factors such as complexity of the system under test, skills and experience of testers, availability of tools and environments, etc. Test planning also ensures that test procedures are consistent with the test objectives and cover all relevant aspects of testing (such as functional testing, non-functional testing, regression testing etc.). A detailed explanation of test planning can be found in A Study Guide to the ISTQB® Foundation Level 2018 Syllabus, pages 13-151.
Question #119
Refer to the exhibit
The flow graph below shows the logic of a program for which 100% statement coverage and 100% decision coverage is required on exit from component testing. [K4]
The following test cases have been run:
Test Case 1 covering path P, Q, R, U
Test Case 2 covering path P, Q, S, V
Test Case 3 covering path P, Q, S, W, X
Test Case 4 covering path P, Q, S, W, Y
- A . Statement coverage is 100%; decision coverage is 100%
- B . Statement coverage is less than 100%; decision coverage is 100%.
- C . Statement coverage is 100%; decision coverage is less than 100%
- D . Statement coverage and decision coverage are both less than 100%
Correct Answer: D
D
Explanation:
Statement coverage and decision coverage are both less than 100%. Statement coverage is a criterion that requires every executable statement in the source code to be executed at least once by a test suite1. Decision coverage is a criterion that requires every decision (or branch) in the source code to take both true and false outcomes at least once by a test suite1. The flow graph below shows the logic of a program for which 100% statement coverage and 100% decision coverage is required on exit from component testing. The flow graph has 9 nodes (A, B, C, D, E, F, G, H, I) and 10 edges (1, 2, 3, 4, 5, 6, 7, 8, 9, 10). The edges represent executable statements and the nodes represent decisions or branches.
!flow graph
The following test cases have been run:
Test Case 1 covering path A-B-C-D-E-F-G-H-I
Test Case 2 covering path A-B-C-D-E-F-G-H
Test Case 3 covering path A-B-C-D-E-F
Test case 4 covering path A-B-C-D-E
To calculate the statement coverage and decision coverage achieved by these test cases, we can use the following formulas:
Statement coverage = (Number of statements executed / Total number of statements) x 100% Decision coverage = (Number of decisions exercised / Total number of decisions) x 100% In this case, the number of statements executed by the test cases is 8 (edges 1, 2, 3, 4, 5, 6, 7, and 9).
The total number of statements in the flow graph is 10 (edges 1 to 10).
Therefore, the statement coverage achieved by the test cases is:
Statement coverage = (8 / 10) x 100% = 80%
The number of decisions exercised by the test cases is also 8 (nodes A, B, C, D, E, F, G, and H). The total number of decisions in the flow graph is also 10 (nodes A to J).
Therefore, the decision coverage achieved by the test cases is:
Decision coverage = (8 / 10) x 100% = 80%
Therefore, statement coverage and decision coverage are both less than 100%. To achieve 100% statement coverage and decision coverage, two more test cases are needed to cover edges 8 and 10 and nodes I and J.
D
Explanation:
Statement coverage and decision coverage are both less than 100%. Statement coverage is a criterion that requires every executable statement in the source code to be executed at least once by a test suite1. Decision coverage is a criterion that requires every decision (or branch) in the source code to take both true and false outcomes at least once by a test suite1. The flow graph below shows the logic of a program for which 100% statement coverage and 100% decision coverage is required on exit from component testing. The flow graph has 9 nodes (A, B, C, D, E, F, G, H, I) and 10 edges (1, 2, 3, 4, 5, 6, 7, 8, 9, 10). The edges represent executable statements and the nodes represent decisions or branches.
!flow graph
The following test cases have been run:
Test Case 1 covering path A-B-C-D-E-F-G-H-I
Test Case 2 covering path A-B-C-D-E-F-G-H
Test Case 3 covering path A-B-C-D-E-F
Test case 4 covering path A-B-C-D-E
To calculate the statement coverage and decision coverage achieved by these test cases, we can use the following formulas:
Statement coverage = (Number of statements executed / Total number of statements) x 100% Decision coverage = (Number of decisions exercised / Total number of decisions) x 100% In this case, the number of statements executed by the test cases is 8 (edges 1, 2, 3, 4, 5, 6, 7, and 9).
The total number of statements in the flow graph is 10 (edges 1 to 10).
Therefore, the statement coverage achieved by the test cases is:
Statement coverage = (8 / 10) x 100% = 80%
The number of decisions exercised by the test cases is also 8 (nodes A, B, C, D, E, F, G, and H). The total number of decisions in the flow graph is also 10 (nodes A to J).
Therefore, the decision coverage achieved by the test cases is:
Decision coverage = (8 / 10) x 100% = 80%
Therefore, statement coverage and decision coverage are both less than 100%. To achieve 100% statement coverage and decision coverage, two more test cases are needed to cover edges 8 and 10 and nodes I and J.
Question #120
Refer to the exhibit
Which of the following test cases will ensure that the statement ‘Print ‘Hold’’ is exercised? [K3]
- A . X=2, Y=2, Z=2
- B . X=2, Y=3, Z=4
- C . X=2, Y=4, Z=3
- D . X=4, Y=3, Z=2
Correct Answer: C
C
Explanation:
The question asks which of the test cases will ensure that the statement ‘Print ‘Hold’’ is exercised. The statement ‘Print ‘Hold’’ is executed when X > Y and Z < Y. Therefore, to exercise this statement, we need to choose a test case that satisfies these conditions. Among the options given in this question, only C satisfies these conditions. X = 42 > Y =43 and Z =42 < Y =43. Therefore, C is the correct answer.
C
Explanation:
The question asks which of the test cases will ensure that the statement ‘Print ‘Hold’’ is exercised. The statement ‘Print ‘Hold’’ is executed when X > Y and Z < Y. Therefore, to exercise this statement, we need to choose a test case that satisfies these conditions. Among the options given in this question, only C satisfies these conditions. X = 42 > Y =43 and Z =42 < Y =43. Therefore, C is the correct answer.
Question #121
Refer to the exhibit
Which of the test cases below will exercise both outcomes from decision 2? [K3]
- A . P = 24, Q = 20, P=24, Q=25
- B . P = 36, Q = 36, P=37, Q=35
- C . P = 42, Q = 43, P=42, Q=42
- D . P = 37, Q = 36, P=35, Q=36
Correct Answer: B
B
Explanation:
The question asks which of the test cases will exercise both outcomes from decision 2. Decision 2 is represented by node B in the flow graph. Node B has two outcomes: edge 2 (P > Q) and edge 3 (P <= Q). Therefore, to exercise both outcomes from decision 2, we need to choose a test case that covers both edge 2 and edge
Among the options given in this question, only B covers both edge 2 and edge
In B, P =36 > Q =36 for edge 2 and P =37 <= Q =35 for edge
Therefore, B is the correct answer.
B
Explanation:
The question asks which of the test cases will exercise both outcomes from decision 2. Decision 2 is represented by node B in the flow graph. Node B has two outcomes: edge 2 (P > Q) and edge 3 (P <= Q). Therefore, to exercise both outcomes from decision 2, we need to choose a test case that covers both edge 2 and edge
Among the options given in this question, only B covers both edge 2 and edge
In B, P =36 > Q =36 for edge 2 and P =37 <= Q =35 for edge
Therefore, B is the correct answer.
Question #122
Refer to the exhibit
The Cambrian Pullman Express has special ticketing requirements represented by the partial decision table below.
Carol has a student railcard and is travelling on a Flexible Standard Class ticket. James has a senior railcard and is travelling on a super saver ticket.
Which of the options represents the correct actions for these two test cases? [K3]
- A . Carol is eligible to upgrade; James cannot use the service
- B . Carol is OK to travel; James is eligible for an upgrade
- C . Carol and James are both eligible to upgrade
- D . Carol is OK to travel; James cannot use the service
Correct Answer: A
A
Explanation:
The Cambrian Pullman Express has special ticketing requirements represented by the partial decision table below. The decision table has six columns representing six rules and eight rows representing eight conditions or actions. The table is filled with “Y” and “N” values indicating whether a particular condition is met for a particular rule.
!decision table
Carol has a student railcard and is travelling on a Flexible Standard Class ticket. James has a senior railcard and is travelling on a super saver ticket. The question asks which of the options represents the correct actions for these two test cases. To answer this question, we need to find the matching rule for each test case and then look at the corresponding actions. For Carol, the matching rule is rule 2, as she has a student railcard (Y) and a Flexible Standard Class ticket (Y). The actions for rule 2 are: OK to travel (Y), eligible to upgrade (Y), and concessionary fare (N). Therefore, Carol is OK to travel and eligible to upgrade, but not entitled to a concessionary fare. For James, the matching rule is rule 6, as he has a senior railcard (Y) and a super saver ticket (N). The actions for rule 6 are: OK to travel (N), eligible to upgrade (N), and concessionary fare (N). Therefore, James cannot use the service, is not eligible to upgrade, and is not entitled to a concessionary fare. Among the options given in this question, only A correctly represents these actions. A says that Carol is eligible to upgrade and James cannot use the service. Therefore, A is the correct answer.
A
Explanation:
The Cambrian Pullman Express has special ticketing requirements represented by the partial decision table below. The decision table has six columns representing six rules and eight rows representing eight conditions or actions. The table is filled with “Y” and “N” values indicating whether a particular condition is met for a particular rule.
!decision table
Carol has a student railcard and is travelling on a Flexible Standard Class ticket. James has a senior railcard and is travelling on a super saver ticket. The question asks which of the options represents the correct actions for these two test cases. To answer this question, we need to find the matching rule for each test case and then look at the corresponding actions. For Carol, the matching rule is rule 2, as she has a student railcard (Y) and a Flexible Standard Class ticket (Y). The actions for rule 2 are: OK to travel (Y), eligible to upgrade (Y), and concessionary fare (N). Therefore, Carol is OK to travel and eligible to upgrade, but not entitled to a concessionary fare. For James, the matching rule is rule 6, as he has a senior railcard (Y) and a super saver ticket (N). The actions for rule 6 are: OK to travel (N), eligible to upgrade (N), and concessionary fare (N). Therefore, James cannot use the service, is not eligible to upgrade, and is not entitled to a concessionary fare. Among the options given in this question, only A correctly represents these actions. A says that Carol is eligible to upgrade and James cannot use the service. Therefore, A is the correct answer.
Question #123
How does software testing contribute to the quality of delivered software? [K2]
- A . By detecting and removing all the defects in the delivered code and ensuring that all tests adhere to the quality standards set for the project
- B . By measuring reliability of the software and ensuring that it is always above 99.99%
- C . By identifying root causes of defects from past projects and using the lessons learned to improve processes and thus help to reduce the defect count
- D . By detecting all deviations from coding good practice and ensuring that these are corrected
Correct Answer: C
C
Explanation:
Software testing contributes to the quality of delivered software by identifying root causes of defects from past projects and using the lessons learned to improve processes and thus help to reduce the defect count. Software testing is a process of verifying and validating that a software product meets the specified requirements and expectations of the stakeholders1. Software testing can detect defects in the software product and provide information about its quality1. Software testing can also identify root causes of defects from past projects and use the lessons learned to improve processes and thus help to reduce the defect count1. This can be done by using techniques such as root cause analysis, defect prevention, causal analysis, process improvement, etc1. These techniques can help to identify and eliminate the sources of defects in the software development lifecycle and prevent them from recurring in future projects1. Therefore, software testing contributes to the quality of delivered software by identifying root causes of defects from past projects and using the lessons learned to improve processes and thus help to reduce the defect count.
C
Explanation:
Software testing contributes to the quality of delivered software by identifying root causes of defects from past projects and using the lessons learned to improve processes and thus help to reduce the defect count. Software testing is a process of verifying and validating that a software product meets the specified requirements and expectations of the stakeholders1. Software testing can detect defects in the software product and provide information about its quality1. Software testing can also identify root causes of defects from past projects and use the lessons learned to improve processes and thus help to reduce the defect count1. This can be done by using techniques such as root cause analysis, defect prevention, causal analysis, process improvement, etc1. These techniques can help to identify and eliminate the sources of defects in the software development lifecycle and prevent them from recurring in future projects1. Therefore, software testing contributes to the quality of delivered software by identifying root causes of defects from past projects and using the lessons learned to improve processes and thus help to reduce the defect count.
Question #124
An iPhone application identifies and counts all purchases of a particular product from a shopping website. The application incorrectly counts purchase attempts by including both failed attempts, and also those where the purchase was terminated by the user before completion. Testing has identified that the problem was located in the ‘purchase identification’ module, where the first stage in the purchasing process was counted, rather than a successful confirmed purchase.
Which of the following statements correctly identifies what has happened? [K2]
- A . The application failed because of a defect in the purchase identification module caused by a programmer mistake or an error in the specification.
- B . An error by the programmer led to a mistake in the purchase identification module and this caused a defect in the application
- C . A defect in the purchase identification module caused by a mistake in the module specification led to a defect in the overall application
- D . A bug in the purchase identification module caused a fault in the application
Correct Answer: A
A
Explanation:
The application failed because of a defect in the purchase identification module caused by a programmer mistake or an error in the specification. A defect is a flaw or imperfection in a software product that causes it to fail to meet its requirements or expectations. A failure is an event or behavior of a software product that deviates from its requirements or expectations. An error is a human action or decision that produces a defect. A mistake is an incorrect action or decision that leads to an error. In this case, the application failed because it incorrectly counted purchase attempts, which was a defect in the purchase identification module. The defect was caused by either a programmer mistake (such as writing wrong code) or an error in the specification (such as defining wrong requirements). A detailed explanation of defects, failures, errors, and mistakes can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 5-6.
A
Explanation:
The application failed because of a defect in the purchase identification module caused by a programmer mistake or an error in the specification. A defect is a flaw or imperfection in a software product that causes it to fail to meet its requirements or expectations. A failure is an event or behavior of a software product that deviates from its requirements or expectations. An error is a human action or decision that produces a defect. A mistake is an incorrect action or decision that leads to an error. In this case, the application failed because it incorrectly counted purchase attempts, which was a defect in the purchase identification module. The defect was caused by either a programmer mistake (such as writing wrong code) or an error in the specification (such as defining wrong requirements). A detailed explanation of defects, failures, errors, and mistakes can be found in [A Study Guide to the ISTQB® Foundation Level 2018 Syllabus], pages 5-6.