ISTQB-CTFL Exam Practice Questions prepared by ISTQB Professionals

Use Valid New ISTQB-CTFL Questions - Top choice Help You Gain Success

NEW QUESTION # 24
Which of the following statements about test reports are TRUE?
I Test reports shall be approved by the test team.
II Test reports shall give stakeholders information as basis for decisions.
Ill Test reports shall summarize what happened through a period of testing.
IV Test reports shall be approved by the development team, the test team and the customer V Test reports shall include information about remaining risks.

• A. I, III, v
• B. I, II, IV
• C. II, III, IV
• D. II, III, V

Answer: D

Explanation:
Statements II, III and V are true about test reports. Test reports are documents that provide information on the results and status of testing activities for a given period or phase. Test reports should give stakeholders information as basis for decisions, such as whether to release the software product, whether to continue testing, whether to change the scope or priorities of testing, etc. Test reports should summarize what happened through a period of testing, such as what test cases were executed, what defects were found, what risks were identified, what issues were encountered, what achievements were made, etc. Test reports should include information about remaining risks, such as what defects are still open, what test cases are still pending, what functionalities are still untested, what uncertainties are still unresolved, etc. Statements I and IV are not true about test reports. Test reports do not need to be approved by the test team, the development team, or the customer, unless it is specified by the test policy or the test plan. Test reports only need to be reviewed and verified by the test leader or the test manager before being distributed to the intended recipients. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 141.

NEW QUESTION # 25
Which of the following is NOT a deciding factor m determining the extent of testing required?

• A. Level of risk of the product or features
• B. Budget to do testing
• C. A particular tester involved in testing
• D. Time available to do testing

Answer: C

Explanation:
The extent of testing required for a software product depends on various factors, such as the level of risk, the budget, and the time available. The level of risk reflects the potential impact of failures on the stakeholders and the environment. The budget determines how much resources can be allocated for testing. The time available defines the schedule and deadlines for testing activities. The particular tester involved in testing is not a deciding factor for the extent of testing required, as testing should be based on objective criteria and not on personal preferences or abilities. Verified Reference: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Chapter 2, page 14-15.

NEW QUESTION # 26
Which of the following is correct with regards to debugging?

• A. Debugging is often performed by test engineers
• B. Debugging is considered part of the testing activities
• C. Debugging is intended to find as many defects as possible in the code
• D. Debugging identifies the cause of a failure

Answer: D

Explanation:
Debugging is the process of finding, analyzing and removing the causes of failures in software. Debugging is not considered part of testing, but rather a development activity that can involve testing. Debugging is not intended to find as many defects as possible, but rather to fix the specific failure that was observed. Debugging is usually performed by developers, not by test engineers. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, Chapter 1, page 6.

NEW QUESTION # 27
Software was found lo take much more time than the stated requirement of less than one second to save a file. Upon investigation it was found that there was an unnecessary check inside a loop which was slowing down the file-save operation. The software not being able to meet the desired response time is an example of

• A. It is not a defect
• B. Error
• C. Failure
• D. Defect

Answer: C

Explanation:
A failure is an event in which a component or system does not perform a required function within specified limits. A failure is observable by the software users or other stakeholders. A failure is caused by one or more defects in the software. In this case, the software not being able to meet the desired response time is an example of a failure, as it deviates from the stated requirement and affects the user experience. It is not a defect, which is a flaw in the software that causes the failure. It is not an error, which is a human action that produces an incorrect result. It is not a non-defect, as it clearly violates a specified requirement. Verified Reference: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Chapter 1, page 4.

NEW QUESTION # 28
Consider the following statements about risk-based testing.
I) Risk-based testing has the objective to reduce the level of protect risks.
II) Tests should be prioritized to find tie critical detects as early as possible.
III) Non-testing activities may also help to reduce risk
IV) Risks have to be reassessed on a regular basis.
V) The project stakeholders can give useful input to determine the risks

• A. II, III IV and V are correct. I is false.
• B. II, Ill and V are true. 1 ants Iv are false.
• C. I III IV and V are true. II is false.
• D. I, II and IV are true. III and V are false.

Answer: A

Explanation:
The following statements about risk-based testing are correct:
II) Tests should be prioritized to find tie critical detects as early as possible. Risk-based testing involves prioritizing tests based on risk level, which reflects both the likelihood and impact of defects or failures. Tests with higher risk level should be executed earlier than tests with lower risk level, in order to find and fix critical defects as soon as possible.
III) Non-testing activities may also help to reduce risk. Risk-based testing does not only involve testing activities, but also other activities that can help mitigate risks, such as reviews, inspections, audits, simulations or prototyping.

NEW QUESTION # 29
In which of the following cases you would NOT execute maintenance testing?

• A. Migration of the system data to a replacement system
• B. Modifications to a released software or system
• C. Update to the Maintainability requirements during the development phase
• D. Retirement of the software or system

Answer: C

Explanation:
Maintenance testing is testing performed on a software product after delivery to correct defects or improve performance or other attributes. Maintenance testing can be triggered by various situations, such as modifications to a released software or system, migration of the system data to a replacement system, or retirement of the software or system. Maintenance testing is not executed when there is an update to the maintainability requirements during the development phase, as this is not a maintenance situation but rather a change request that should be handled by the development process. Verified Reference: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Chapter 2, page 18-19.

NEW QUESTION # 30
For withdrawing money tram an Automated Teller Machine (ATM), the following conditions are required:
- The bank card is valid
- The PIN code is correct
- Money is available in the user's account
The following are some possible interactions between the user and the ATM:
- The entered card is invalid The card is rejected
- The PIN code is wrong The ATM asks for another PIN code
- The requested amount is more than available in the user's account: The ATM asks for another amount
- The requested amount is available in the user's account The ATM dispenses the money Which test design technique should be used to cover all possible combinations of the input conditions?

• A. Decision table
• B. Use case based testing
• C. Boundary value analysis
• D. Equivalence class partitioning

Answer: A

Explanation:
A decision table is a technique that should be used to cover all possible combinations of input conditions for withdrawing money from an Automated Teller Machine (ATM). A decision table shows combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects). A decision table consists of four quadrants: conditions (inputs), actions (outputs), condition entries (values) and action entries (results). A decision table can be used to test components that have multiple inputs and outputs that depend on logical combinations of conditions. For example, for testing the ATM, we can identify three input conditions: the bank card is valid, the PIN code is correct, and money is available in the user's account. We can also identify four output actions: the card is rejected, the ATM asks for another PIN code, the ATM asks for another amount, and the ATM dispenses the money. A decision table can show all possible combinations of these conditions and actions in a systematic way.
Use case based testing is not a technique that can cover all possible combinations of input conditions for withdrawing money from an ATM. Use case based testing is a technique that verifies that a software product or system meets its specified requirements or user stories by executing realistic scenarios or workflows. Use case based testing can be used to test components that have complex or dynamic interactions with users or other systems. For example, for testing the ATM, we can identify several use cases, such as withdraw money, check balance, transfer money, etc. Each use case can have one or more scenarios that describe the steps and outcomes of the interaction. However, use case based testing may not cover all possible combinations of input conditions, as some scenarios may be omitted or overlooked.
Boundary value analysis is not a technique that can cover all possible combinations of input conditions for withdrawing money from an ATM. Boundary value analysis is a technique that tests boundary values between partitions of equivalent data. Boundary values are values at the edge of an equivalence partition or at the smallest incremental distance on either side of an edge. Boundary value analysis can be used to test components that have input values that can be divided into partitions of equivalent data. For example, for testing the ATM, we can identify boundary values for the input amount, such as the minimum and maximum amount allowed by the system or the user's account. However, boundary value analysis may not cover all possible combinations of input conditions, as some conditions may not have boundary values or may not be related to input values.
Equivalence class partitioning is not a technique that can cover all possible combinations of input conditions for withdrawing money from an ATM. Equivalence class partitioning is a technique that divides the input data and output results of a software component into partitions of equivalent data. Each partition should contain data that is treated in the same way by the component. Equivalence class partitioning can be used to test components that have input values that can be divided into partitions of equivalent data. For example, for testing the ATM, we can identify equivalence partitions for the input amount, such as valid amount (within the range allowed by the system and the user's account) and invalid amount (outside the range allowed by the system or the user's account). However, equivalence class partitioning may not cover all possible combinations of input conditions, as some conditions may not be related to input values or may have more than two partitions. Verified Reference: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Chapter 4, page 34-46.

NEW QUESTION # 31
In maintenance testing, what is the relationship between impact analysis and regression testing?

• A. The impact analysis is used to evaluate the amount of regression testing to be performed.
• B. Impact analysis requires a regression testing for only the tests that have detected faults in previous SW release
• C. There is no relationship between impact analysis and regression testing.
• D. Impact analysis requires a regression testing for all program elements which were newly integrated (new functionalities).

Answer: A

Explanation:
In maintenance testing, the relationship between impact analysis and regression testing is that the impact analysis is used to evaluate the amount of regression testing to be performed. Maintenance testing is a type of testing that is performed on an existing software product after it has been delivered or deployed, in order to ensure that it still meets its requirements and functions correctly after a change or a modification. Maintenance testing can be triggered by various reasons, such as corrective maintenance (fixing defects), adaptive maintenance (adapting to new environments), perfective maintenance (improving performance), preventive maintenance (avoiding future problems), etc. Impact analysis is a technique that is used to assess the extent and nature of changes introduced by maintenance activities on the software product or project. Impact analysis helps to identify which parts of the software product are affected by the changes, which parts need to be modified or updated accordingly, which parts need to be retested or verified for correctness or compatibility, etc. Regression testing is a type of testing that verifies that previously tested software still performs correctly after a change or a modification. Regression testing helps to detect any side effects or unintended consequences of maintenance activities on the software product's functionality or quality. Regression testing can be performed at various levels and scopes depending on the impact analysis results. Therefore, in maintenance testing, impact analysis is used to evaluate the amount of regression testing to be performed. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 20.

NEW QUESTION # 32
As the last stage of a test cycle of an embedded device, you are performing exploratory testing. You observed that some character. (A, X and Z) sent via a serial port to the device do not get registered on the device whereas they should be. You suspect that this could be due to a wrong configuration of the "bit parity" parameter.
Which of the following items of an incident report would you be UNABLE to write down based on this information?

• A. Test setup details
• B. Test case identifier
• C. Expected result
• D. Actual result

Answer: B

Explanation:
An incident report is a document that records the details of an incident. An incident report typically contains the following items:
Identifier: A unique identifier for the incident report
Summary: A concise summary of the incident
Description: A detailed description of the incident, including the steps to reproduce it, the expected and actual results, and any relevant screenshots or logs Severity: The degree of impact that the incident has on the system Priority: The level of urgency for resolving the incident Status: The current state of the incident, such as new, open, resolved, closed, etc.
Resolution: The action taken to resolve the incident, such as fix, workaround, reject, etc. Based on the information given in the question, the tester would be able to write down all of these items except for the test case identifier. A test case identifier is a unique identifier for a test case that is used to link it to other test artifacts, such as test plans, test scripts, test results or incident reports. However, since the tester is performing exploratory testing, there is no predefined test case that can be associated with the incident. Exploratory testing is an approach to testing that emphasizes learning, test design and test execution at the same time. Exploratory testing relies on the tester's skills, creativity and intuition to explore the software under test and discover defects. Exploratory testing does not use formal test cases or scripts, but rather uses test charters or missions that guide the tester's actions and objectives. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, Chapter 3, page 32-33; Chapter 5, page 47-48.

NEW QUESTION # 33
Why should you choose a test technique?

• A. Because this way you cover the full scope of the product's functionality
• B. Because you need to match the way you test to the content of the product under test
• C. Because choosing a test technique is a common practice in software testing
• D. Because of the time constraints that usually accompany a test project

Answer: B

Explanation:
You should choose a test technique because you need to match the way you test to the content of the product under test. A test technique is a method or process for deriving and selecting test cases based on some criteria or rules. Different test techniques are suitable for different types of software products, depending on their characteristics, functionalities, requirements, specifications, risks, etc. Choosing a test technique helps to ensure that the test cases are relevant, effective, and efficient for the product under test. The other options are not correct reasons to choose a test technique. Time constraints are not a factor for choosing a test technique, but rather for prioritizing or optimizing testing activities. Covering the full scope of the product's functionality is not a guarantee of choosing a test technique, but rather a goal of testing. Choosing a test technique is not a common practice in software testing, but rather a professional skill and responsibility. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 31.

NEW QUESTION # 34
A test manager defined the following test levels in her test plan; Component, System and Acceptance.
Which Software Development lifecycle is the Test Manager most likely following?

• A. Agile
• B. V-Model
• C. Prototyping
• D. Waterfall

Answer: B

Explanation:
The test manager is most likely following the V-model for software development. The V-model is a software development model that defines four testing levels that correspond to four development phases: component testing corresponds to component design, integration testing corresponds to architectural design, system testing corresponds to system requirements specification, and acceptance testing corresponds to user requirements specification. The V-model also defines the test planning and test execution activities for each testing level. Agile is a software development model that follows an iterative and incremental approach, where testing is integrated into each iteration and adapts to changing requirements and feedback. Waterfall is a software development model that follows a sequential and linear approach, where testing is performed after the development phase is completed. Prototyping is a software development model that involves creating a simplified version of the software to elicit user feedback and validate requirements before developing the final product. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 18.

NEW QUESTION # 35
Which of the following is a function of a dynamic analysis tool?

• A. Execute programs step-by-step in order to reproduce failures and find corresponding defects
• B. Monitor the allocation, use and de-allocation of memory during run-time of a program
• C. Provide support for traceability of tests, test results and incidents to source documents
• D. Provide support for release of baselines consisting of configuration items

Answer: B

Explanation:
A dynamic analysis tool is a tool that performs analysis of a software product based on its behavior during execution. A dynamic analysis tool can monitor various aspects of a program's run-time performance, such as memory usage, CPU load, response time, or resource leaks. A dynamic analysis tool can monitor the allocation, use and de-allocation of memory during run-time of a program, which can help detect defects such as memory leaks, buffer overflows, or memory corruption. A dynamic analysis tool cannot provide support for traceability of tests, test results and incidents to source documents, as this is a function of a test management tool. A dynamic analysis tool cannot execute programs step-by-step in order to reproduce failures and find corresponding defects, as this is a function of a debugging tool. A dynamic analysis tool cannot provide support for release of baselines consisting of configuration items, as this is a function of a configuration management tool. Verified Reference: [A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer], Chapter 6, page 56-57.

NEW QUESTION # 36
Why it is essential that defects found in a review be reported objectively?

• A. In order to allow augmentation of existing checklists used for reviewing the work product (S)
• B. In order to allow the review moderator to easily understand them, and assign them to the right developer for fixing
• C. In order to facilitate easy entry of detected defects in a OTS (Defect Tracking System)
• D. In order to allow the author of reviewed work product(S) to take the feedback positively as an effort at improving the product (S) and not as a personal assault

Answer: D

Explanation:
The purpose of a review is to find defects and improve the quality of the work product, not to criticize or blame the author. Reporting defects objectively means describing them factually and constructively, without using negative or emotional language that could offend the author or damage their motivation. This way, the author can take the feedback positively as an effort at improving the product and not as a personal assault. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 138.

NEW QUESTION # 37
ST is a Software Testing organization which utilizes a testing knowledge base. Access to ST knowledge base can be either full or limited. Access level is determined based on ST certification and testing experience as follows:
1. If ST certified, with less than 5 years testing experience - allow limited access
2. If ST certified, 5-10 years of testing experience - allow full access
3. If not ST certified with 5-10 years of testing experience - allow limited access.
What would be the results for:
A - ST certified. 12 years of testing experience
B - Not ST certified. 7 years of testing experience
C - Not ST certified. 3 years of testing experience

• A. A - full access
  B - limited access
  C - limited access
• B. A - full access
  B - limited access
  C - unknown
• C. A - unknown
  B - limned access
  C- unknown
• D. A - unknown
  B - full access
  C - unknown

Answer: B

Explanation:
The correct answer can be derived by applying the given rules to each case:
A is ST certified and has 12 years of testing experience, which is more than 10 years. Therefore, A does not match any of the rules and the result is unknown.
B is not ST certified and has 7 years of testing experience, which is between 5 and 10 years. Therefore, B matches rule 3 and the result is limited access.
C is not ST certified and has 3 years of testing experience, which is less than 5 years. Therefore, C does not match any of the rules and the result is unknown. Verified Reference: This question does not require any external references, as it is based on logical reasoning.

NEW QUESTION # 38
Which of the following statements is LEAST likely to be describing component testing?

• A. Simulators and stubs may be required.
• B. It may be applied using a test-first approach.
• C. It identifies defects in modules and classes.
• D. It mainly tests interfaces and interaction between components.

Answer: D

Explanation:
Component testing (also known as unit testing or module testing) is a level of testing that focuses on verifying the functionality and quality of individual software components (such as modules, classes, functions, methods, etc.). Component testing mainly tests interfaces and interaction between components, as well as internal logic and data structures of the components. Component testing may be applied using a test-first approach (such as test-driven development or behavior-driven development), where tests are written before the code is implemented. Component testing does not identify defects in modules and classes, as this is a result of component testing, not an objective. Simulators and stubs may be required for component testing, as they can simulate or replace missing or incomplete components or external systems that are needed for testing. Verified Reference: A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer, page 19.

NEW QUESTION # 39
......

ISTQB-CTFL Exam Practice Materials Collection: https://www.testsimulate.com/ISTQB-CTFL-study-materials.html