Provide ISTQB ISTQB-CTFL Practice Test Engine for Preparation [Q18-Q34]

Q18. A typical objective of testing is to

Determine the most appropriate level of detail with which to design test cases.

Verify the compliance of the test object with regulatory requirements.

Plan test activities in accordance with the existing test policy and test strategy

Verify the correct creation and configuration of the test environment

Q19. 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.

I. Ill

I. IV

II. IV

II. Ill

Generally, decision tables are generated for low risk test items. Decision tables are not related to risk level, but rather to complexity level. Decision tables are generated for test items that have complex logic or multiple conditions and actions that need to be tested.

Q20. Which of the following statements about test estimation approaches is CORRECT?

The Wideband Delphi estimation technique is an example of the risk-based approach

The Wideband Delphi estimation technique is an example of the expert-based approach

Bumdown charts used in Agile development is an example of the risk-based approach

Burndown charts used in Agile development is an example of the expert-based approach

Q21. During iteration planning, a scrum team uses an estimation technique called planning poker to estimate the effort required to deliver a critical user story. In advance of the estimation session, the team agreed on some ground rules to limit the number of poker rounds and save time.
The team agreed on the following:
1. They will use the following progression for estimation: Extra-small, Small, Medium, Large, Extra-large, and Extra-extra-large.
2. If estimation values differ significantly, the highest score will be used for estimation purposes.
The result of the first round of planning poker:
Team MemberEstimation
BusinessLarge
DevelopmentExtra-extra-large
TestingExtra-extra-large
Which of the following options best represent the team’s next actions?

The fact that all estimations are high indicate that the user story is not well understood or should be broken down into multiple smaller stories.

The pre-agreed rules state that the highest score should be used for estimation, resulting in the user story being categorised as Extra-extra-large.

Since the business representative is likely to have the most informed view of the requirement, the user story is categorised as a Large.

the team discusses the differences in the estimates and repeats the poker round until an agreemet is reached.

Q22. Which of the following statements is true?

Experience-based test techniques rely on the experience of testers to identify the root causes of defects found by black-box test techniques

Some of the most common test basis used by white-box test techniques include user stories, use cases and business processes

Experience-based test techniques are often useful to detect hidden defects that have not been targeted by black-box test techniques

The primary goal of experience-based test techniques is to design test cases that can be easily automated using a GUI-based test automation tool

Experience-based test techniques are test design techniques that rely on the experience, knowledge, intuition, and creativity of the testers to identify and execute test cases that are likely to find defects in the software system. Experience-based test techniques are often useful to detect hidden defects that have not been targeted by black-box test techniques, which are test design techniques that use the external behavior and specifications of the software system as the test basis, without considering its internal structure or implementation.
Experience-based test techniques can complement black-box test techniques by covering aspects that are not explicitly specified, such as usability, security, reliability, performance, etc. The other statements are false, because:
* Experience-based test techniques do not rely on the experience of testers to identify the root causes of defects found by black-box test techniques, but rather to identify the potential sources of defects based on their own insights, heuristics, or exploratory testing. The root causes of defects are usually identified by debugging or root cause analysis, which are activities that involve examining the code or the development process to find and fix the errors that led to the defects.
* Some of the most common test basis used by white-box test techniques include the source code, the design documents, the architecture diagrams, and the control flow graphs of the software system.
White-box test techniques are test design techniques that use the internal structure and implementation of the software system as the test basis, and aim to achieve a certain level of test coverage based on the code elements, such as statements, branches, paths, etc. User stories, use cases, and business processes are examples of test basis used by black-box test techniques, as they describe the functional and non-functional requirements of the software system from the perspective of the users or the stakeholders.
* The primary goal of experience-based test techniques is not to design test cases that can be easily automated using a GUI-based test automation tool, but rather to design test cases that can reveal defects that are not easily detected by other test techniques, such as boundary value analysis, equivalence partitioning, state transition testing, etc. Test automation is the use of software tools to execute test cases and compare actual results with expected results, without human intervention. Test automation can be applied to different types of test techniques, depending on the test objectives, the test levels, the test tools, and the test resources. However, test automation is not always feasible or beneficial, especially for test cases that require human judgment, creativity, or exploration, such as those designed by experience-based test techniques. References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 sources and documents:
* ISTQB Certified Tester Foundation Level Syllabus v4.0, Chapter 2.2.1, Black-box Test Design Techniques
* ISTQB Certified Tester Foundation Level Syllabus v4.0, Chapter 2.2.2, White-box Test Design Techniques
* ISTQB Certified Tester Foundation Level Syllabus v4.0, Chapter 2.2.3, Experience-based Test Design Techniques
* ISTQB Glossary of Testing Terms v4.0, Experience-based Test Technique, Black-box Test Technique, White-box Test Technique, Test Basis, Test Coverage, Test Automation

Q23. A company runs a pilot project for evaluation of a test automation tool. Which of the following is NOT a valid object of this pilot project?

Get familiar with the functionality and options of the tool

Check haw the tool fits to the existing test processes

Train all testers on using the tool

Decide upon standards for tool implementation

Q24. Which of the following is NOT a product risk?

Poor software usability

Failure-prone software is delivered

Problems in defining the right requirements

Software does not perform the intended functions

Q25. An Incident Management tool implements the following defect states; Open, Assigned, Solved, Closed Consider the following defect report:
Id T000561
Test Object “Warehouse Management’ application
Tester name; John Bishop
Date: 10th. April 2010
Test Case MRT558I
Status OPEN
Severity Serious
Priority
Problem- After inputting the Total Quantity item = 450 in the SV034 screen, the system shows an unexpected Error message=47 Correction:
Developer name:
Closing date:
Which of the following is a valid criticism of this report?

The Priority, the Correction description and the Developer name are missing

The version of the application is missing

There is no link to the applicable requirement (traceability)

The description is not highlighting the source of the problem

A valid criticism of this report is that the version of the application is missing. The version of the application is an important piece of information that should be included in a defect report, as it helps to identify which release or build of the software product contains the defect. The version of the application can also help to reproduce and debug the defect, as different versions may have different behaviors or features. The other options are not valid criticisms of this report. The priority, the correction description and the developer name are not missing, but rather not applicable for this report. The priority is a measure of how urgently a defect needs to be fixed, which can be assigned by the project manager or the defect tracking system, not by the tester who reports the defect. The correction description and the developer name are information that are added after the defect has been resolved, not when it has been reported. There is no link to the applicable requirement (traceability) is not a valid criticism of this report, because traceability is not a mandatory attribute of a defect report, but rather an optional one.Traceability is a relationship between two or more entities (such as requirements, test cases, defects, etc.) that shows how they are related or dependent on each other. Traceability can help to verify that the requirements are met by the test cases and defects, but it is not essential for reporting a defect. The description is not highlighting the source of the problem is not a valid criticism of this report, because highlighting the source of the problem is not a responsibility of the tester who reports the defect, but rather of the developer who fixes the defect. The description should provide enough information to describe what happened when the defect occurred, such as input values, expected results, actual results, error messages, screenshots, etc., but it does not need to explain why or how it happened. Verified References: A Study Guide to the ISTQB Foundation Level 2018 Syllabus – Springer, page 140.

Q26. You are an experienced tester on a project with incomplete requirements and under pressure to deploy.
What type of testing should you do?

Decision-based testing.

Checklist-based testing.

Error guessing.

Exploratory testing.

Q27. The statement: “Test activities should start in the early stages of the lifecycle, adhering to the testing principle of early testing” is relevant to which of the recognized software development models?

Sequential development model.

Iterative development model.

Incremental development model.

All the above

Q28. Which test approach will best fit a new project, with little documentation and high probability for bugs?

Exploratory testing

Requirements based testing

Metric based approach

Regression testing

Q29. You are responsible for applying the correct technique for a review of the requirements document for a project to develop a new software application. You identify the reviewers and the required roles, including the meeting leader, who is the requirements document author, and a separate role for a scribe. Additionally, you decide to take a relatively informal approach to the requirements review. The goal of the review is to find defects in the requirements document, such as omissions, Inconsistencies, and duplications. Another goal of the review is to improve the software application’s usability and accessibility by considering the various stakeholders’ viewpoints.
Which of the following statements BEST describes this scenario?

This scenario is using a pair review type and a perspective-based review technique

This scenario is using a walkthrough review type and a checklist-based review technique

This scenario is using a walkthrough review type and a perspective-based review technique

This scenario is using a pair review type and a checklist-based review technique

Q30. 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?

V-Model

Agile

Waterfall

Prototyping

Q31. Which of the following statements about re-testing and regression testing are TRUE?
I Re-testing should be performed after a defect is fixed.
II Regression testing should always be performed after a defect is fixed.
III. Re-testing and regression testing may be performed at any test level.
IV Regression testing may include functional, non-functional and structural testing.
V. Re-testing should be included in the debugging activity.

I, III. Iv

II, v

I, Ill

II. IV, V

The following statements about re-testing and regression testing are true:
* I) Re-testing should be performed after a defect is fixed. Re-testing is a type of testing that verifies that a defect has been successfully resolved by executing a test case that previously failed due to that defect.
Re-testing should be performed after a defect is fixed and delivered to ensure that it does not cause any new failures or side effects.
* III) Re-testing and regression testing may be performed at any test level. Re-testing and regression testing are not limited to a specific test level, but can be applied at any level depending on the context and objectives. For example, re-testing and regression testing can be performed at unit level, integration level, system level or acceptance level.
* IV) Regression testing may include functional, non-functional and structural testing. Regression testing is a type of testing that verifies that previously tested software still performs correctly after changes.
Regression testing may include various types of testing depending on the scope and purpose of the changes. For example, regression testing may include functional testing to check if the software meets its requirements, non-functional testing to check if the software meets its quality attributes, or structural testing to check if the software meets its design or code standards. The following statement about re-testing and regression testing is false:
* II) Regression testing should always be performed after a defect is fixed. Regression testing is not always necessary after a defect is fixed, as some defects may have a low impact or low likelihood of affecting other parts of the software. Regression testing should be performed after a defect is fixed only
* if there is a risk of introducing new defects or causing existing defects due to the changes made to fix the defect. Verified References: A Study Guide to the ISTQB Foundation Level 2018 Syllabus – Springer, Chapter 2, page 19; Chapter 4, page 45.

Q32. The testers in company A were part of the development team. Due to an organizational change they moved to be part of the support team.
What are the advantages and the disadvantages of this change?

Advantage: More independence in deciding what and how to test,Disadvantage: Isolation from me development team knowledge

Advantage: being closer to customer perspective,Disadvantage less independence in perspectives

Advantage: pulled to support tasks and having less time for testing, Disadvantage less chances to move a tester to development

Advantage: increased chances to move a tester to development; Disadvantage: pulled to support tasks and having less time for testing

Q33. Which of the following would be the LEAST likely to be used as the basis for a test exit criteria?

Test schedules

Cost of testing performed so far

Confidence of testers in tested code

Number of unfixed defects

Q34. Which of the following lists factors That contribute to PROJECT risks?

problems in defining the right requirements; contractual issues; poor software quality characteristics.

skill and staff shortages; problems in defining the right requirements, contractual issues.

poor software quality characteristics; software does not perform its intended functions.

skill and staff shortages; software does not perform its intended functions; problems in defining the right requirements.

Provide ISTQB ISTQB-CTFL Practice Test Engine for Preparation [Q18-Q34]

Be the first to reply

Leave a Reply Cancel reply