Which of the following statements about error guessing is true?
Error guessing is a system that adopts artificial intelligence to predict whether software components are likely to contain defects or not
Experienced testers, when applying error guessing, rely on the use of a high-level list of what needs to be tested as a guide to find defects
Error guessing refers to the ability of a system or component to continue normal operation despite the presence of erroneous inputs
Experienced testers, when applying error guessing technique, can anticipate where errors, defects and failures have occurred and target their tests at those issues
This answer is correct because error guessing is a test design technique where the experience and intuition of the tester are used to anticipate where errors, defects and failures have occurred or are likely to occur, and to design test cases to expose them. Error guessing can be based on factors such as the complexity of the system or component, the known or suspected weaknesses of the system or component, the previous history of defects, or the common types of errors in the domain or technology. Error guessing can be used as a complementary technique to other more systematic or formal techniques, or when there is insufficient information or time to apply them. References: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 2.3.2.5
The whole-team approach:
promotes the idea that all team members should have a thorough understanding of test techniques
is a consensus-based approach that engages the whole team in estimating the user stories
promotes the idea that all team members should be responsible for the quality of the product
is mostly adopted in projects aimed at developing safety-critical systems, as it ensures the highest level of testing independence
This answer is correct because the whole-team approach is a way of working in agile projects where all team members share the responsibility for the quality of the product, and collaborate on delivering value to the customer. The whole-team approach involves testers, developers, business analysts, product owners, and other stakeholders in planning, designing, developing, testing, and delivering the product. The whole-team approach fosters communication, feedback, learning, and continuous improvement within the team. References: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 3.1.1.1
Which ONE of the following statements does NOT describe how testing contributes to higher quality?
Properly designed tests that pass reduce the level of risk in a system.
The testing of software demonstrates the absence of defects.
Software testing identifies defects, which can be used to improve development activities.
Performing a review of the requirement specifications before implementing the system can enhance quality.
References =
Which sequence of stated in the answer choices is correct in accordance with the following figure depicting the life-cycle of a defect?
S0->S1->S2->S3->S5->S1
S0->S1->S2->S3->S5->S1->S2->S3
S0->S1->S2~>S3->S4
S0->S1 ->S2->S3->S5->S3->S4
According to the ISTQB Certified Tester Foundation Level (CTFL) v4.0, the life cycle of a defect typically follows a sequence from its discovery to its closure. In the provided figure, it starts with S0 (New), moves to S1 (Assigned), then to S2 (Resolved), followed by S3 (Verified). If the defect is not fixed, it can be Re-opened (S5) and goes back for verification (S3). Once verified, it is Closed (S4). References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Section 1.4.3, Page 17.
Which of the following statements is not correct?
Looking for defects in a system may require Ignoring system details
Identifying defects may be perceived as criticism against product
Looking for defects in system requires professional pessimism and curiosity
Testing is often seen as a destructive activity instead of constructive activity
In a two-hour uninterrupted test session, performed as part of an iteration on an Agile project, a heuristic checklist was used to help the tester focus on some specific usability issues of a web application.
The unscripted tests produced by the tester's experience during such session belong to which one of the following testing quadrants?
Q1
Q2
Q3
Q4
The unscripted tests produced by the tester’s experience during the two-hour test session belong to the testing quadrant Q3. The testing quadrants are a classification of testing types based on two dimensions: the test objectives (whether the testing is focused on supporting the team or critiquing the product) and the test basis (whether the testing is based on the technology or the business). The testing quadrants are labeled as Q1, Q2, Q3, and Q4, and each quadrant represents a different testing perspective, such as unit testing, acceptance testing, usability testing, or performance testing. The testing quadrant Q3 corresponds to the testing types that have the objective of critiquing the product from the business perspective, such as exploratory testing, usability testing, user acceptance testing, alpha testing, beta testing, etc. The unscripted tests performed by the tester in the given scenario are examples of exploratory testing and usability testing, as they are based on the tester’s experience, intuition, and learning of the web application, and they focus on some specific usability issues, such as the user interface, the user satisfaction, the user feedback, etc. The other options are incorrect, because:
Which of the following is a task the Author is responsible for, as part of a typical formal review?
Determining the people who will be involved in the review
Recording the anomalies found during the review meeting
Identifying potential anomalies in the work product under review
Fixing the anomalies found in the work product under review
This answer is correct because identifying potential anomalies in the work product under review is one of the tasks the Author is responsible for, as part of a typical formal review. The Author is the person who creates the work product to be reviewed, such as a requirement specification, a design document, or a test case. The Author’s tasks include preparing the work product for the review, identifying potential anomalies in the work product, and fixing the anomalies found in the work product after the review. References: ISTQB Glossary of Testing Terms v4.0, ISTQB Foundation Level Syllabus v4.0, Section 2.4.2.1
Following a risk-based testing approach you have designed 10 tests to cover a product risk with a high-risk level. You want to estimate, adopting the three-point test estimation technique, the test effort required to reduce the risk level to zero by executing those 10 tests. You made the following three initial estimates:
• most optimistic = 6 person hours
• most likely = 30 person hours
• most pessimistic = 54 person hours
Based only on the given information, which of the following answers about the three-point test estimation technique applied to this problem is true?
The final estimate is between 22 person hours and 38 person hours
The final estimate is exactly 30 person hours because the technique uses the initial most likely estimate as the final estimate
The final estimate is between 6 person hours and 54 person hours
The final estimate is exactly 30 person hours because the technique uses the arithmetic mean of the three initial estimates as the final estimate
The three-point test estimation technique is a method of estimating the test effort based on three initial estimates: the most optimistic, the most likely, and the most pessimistic. The technique uses a weighted average of these three estimates to calculate the final estimate, which is also known as the expected value. The formula for the expected value is:
Expected value = (most optimistic + 4 * most likely + most pessimistic) / 6
Using the given values, the expected value is:
Expected value = (6 + 4 * 30 + 54) / 6 Expected value = 30 person hours
However, the expected value is not the only factor to consider when estimating the test effort. The technique also calculates the standard deviation, which is a measure of the variability or uncertainty of the estimates. The formula for the standard deviation is:
Standard deviation = (most pessimistic - most optimistic) / 6
Using the given values, the standard deviation is:
Standard deviation = (54 - 6) / 6 Standard deviation = 8 person hours
The standard deviation can be used to determine a range of possible values for the test effort, based on a certain level of confidence. For example, using a 68% confidence level, the range is:
Expected value ± standard deviation
Using the calculated values, the range is:
30 ± 8 person hours
Therefore, the final estimate is between 22 person hours and 38 person hours, which is option A.
References: ISTQB® Certified Tester Foundation Level Syllabus v4.01, Section 2.3.2, page 24-25; ISTQB® Glossary v4.02, page 33.
Which of the following statements refers to good testing practice to be applied regardless of the chosen software development model?
Tests should be written in executable format before the code is written and should act as executable specifications that drive coding
Test levels should be defined such that the exit criteria of one level are part of the entry criteria for the next level
Test objectives should be the same for all test levels, although the number of tests designed at various levels can vary significantly
Involvement of testers in work product reviews should occur as early as possible to take advantage of the early testing principle
The statement that refers to good testing practice to be applied regardless of the chosen software development model is option D, which says that involvement of testers in work product reviews should occur as early as possible to take advantage of the early testing principle. Work product reviews are static testing techniques, in which the work products of the software development process, such as the requirements, the design, the code, the test cases, etc., are examined by one or more reviewers, with or without the author, to identify defects, violations, or improvements. Involvement of testers in work product reviews can provide various benefits for the testing process, such as improving the test quality, the test efficiency, and the test communication. The early testing principle states that testing activities should start as early as possible in the software development lifecycle, and should be performed iteratively and continuously throughout the lifecycle. Applying the early testing principle can help to prevent, detect, and remove defects at an early stage, when they are easier, cheaper, and faster to fix, as well as to reduce the risk, the cost, and the time of the testing process. The other options are not good testing practices to be applied regardless of the chosen software development model, but rather specific testing practices that may or may not be applicable or beneficial for testing, depending on the context and the objectives of the testing activities, such as:
Can "cost" be regarded as Exit criteria?
Yes. Spending too much money on test ng will result in an unprofitable product, and having cost as an exit criterion helps avoid this
No. The financial value of product quality cannot be estimated, so it is incorrect to use cost as an exit criterion
Yes. Going by cost as an exit criterion constrains the testing project which will hello achieve the desired quality level defined for the project
No The cost of testing cannot be measured effectively, so it is incorrect to use cost as an exit criterion
Cost can be regarded as an exit criterion for testing, because it is a factor that affects the profitability and feasibility of the software product. Testing is an investment that aims to improve the quality and reliability of the software product, but it also consumes resources, such as time, money, and human effort. Therefore, testing should be planned and executed in a way that balances the cost and benefit of testing activities. Having cost as an exit criterion helps to avoid spending too much money on testing, which may result in an unprofitable product or a loss of competitive advantage. Cost can also help to prioritize and focus the testing efforts on the most critical and valuable features and functions of the software product. However, cost should not be the only exit criterion for testing, as it may not reflect the true quality and risk level of the software product. Other exit criteria, such as defect rate, test coverage, user satisfaction, etc., should also be considered and defined in the test plan.
The other options are incorrect, because they either deny the importance of cost as an exit criterion, or they make false or unrealistic assumptions about the cost of testing. Option B is incorrect, because the financial value of product quality can be estimated, for example, by using cost-benefit analysis, return on investment, or cost of quality models. Option C is incorrect, because going by cost as an exit criterion does not necessarily constrain the testing project or help achieve the desired quality level. Cost is a relative and variable factor that depends on the scope, complexity, and context of the software product and the testing project. Option D is incorrect, because the cost of testing can be measured effectively, for example, by using metrics, such as test effort, test resources, test tools, test environment, etc.
During component testing of a program if 100% decision coverage is achieved, which of the following coverage criteria is also guaranteed to be 100%?
100% Stale transition coverage
100% Equivalence class coverage
100% Boundary value coverage
100% Statement coverage
Statement coverage is a structural coverage metric that measures the percentage of executable statements in the source code that are executed by a test suite1. Decision coverage is another structural coverage metric that measures the percentage of decision outcomes (such as branches or conditions) in the source code that are executed by a test suite1. Decision coverage is a stronger metric than statement coverage, because it requires that every possible outcome of each decision is tested, while statement coverage only requires that every statement is executed at least once2. Therefore, if a test suite achieves 100% decision coverage, it also implies that it achieves 100% statement coverage, because every statement in every branch or condition must have been executed. However, the converse is not true: 100% statement coverage does not guarantee 100% decision coverage, because some branches or conditions may have multiple outcomes that are not tested by the test suite2. For example, consider the following pseudocode:
if (x > 0) then print(“Positive”) else print(“Non-positive”) end if
A test suite that executes this code with x = 1 and x = -1 will achieve 100% statement coverage, because both print statements are executed. However, it will not achieve 100% decision coverage, because the condition x > 0 has only been tested with two outcomes: true and false. The third possible outcome, x = 0, has not been tested by the test suite. Therefore, the test suite may miss a potential bug or error in the condition or the branch.
The other options, such as stale transition coverage, equivalence class coverage, and boundary value coverage, are not guaranteed to be 100% by achieving 100% decision coverage. Stale transition coverage is a structural coverage metric that measures the percentage of transitions between states in a state machine that are executed by a test suite3. Equivalence class coverage is a functional coverage metric that measures the percentage of equivalence classes (or partitions) of input or output values that are tested by a test suite4. Boundary value coverage is another functional coverage metric that measures the percentage of boundary values (or extreme values) of input or output ranges that are tested by a test suite4. These metrics are independent of decision coverage, because they are based on different aspects of the system under test, such as its behavior, functionality, or specification. Therefore, achieving 100% decision coverage does not imply achieving 100% of any of these metrics, and vice versa. References = ISTQB® Certified Tester Foundation Level Syllabus v4.0, Test Coverage in Software Testing - Guru99, Structural Coverage Metrics - MATLAB & Simulink - MathWorks India, Test Design Coverage in Software Testing - GeeksforGeeks.
Which of the following statements about the shift-left approach is true?
Shift-left in testing can be implemented only in Agile/DevOps frameworks, as it relies completely on automated testing activities performed within a continuous integration process
Performance testing performed during component testing, is a form of shift-left in testing that avoids planning and executing costly end-to-end testing at the system test level in a production-like environment
Shift-left in testing can be implemented in several ways to find functional defects early in the lifecycle, but it cannot be relied upon to find defects associated with non-functional characteristics
Continuous integration supports shift-left in testing as it can reduce the time between the introduction of a defect and its detection, thereby reducing the cost to fix it
This answer is correct because shift-left in testing is an approach that aims to perform testing activities as early as possible in the software development lifecycle, in order to find and fix defects faster and cheaper, and to improve the quality of the software product. Continuous integration is a practice that supports shift-left in testing, as it involves integrating and testing the software components frequently, usually several times a day, using automated tools and processes. Continuous integration can reduce the time between the introduction of a defect and its detection, thereby reducing the cost to fix it and the risk of accumulating defects that could affect the functionality or performance of the software product. References: ISTQB Foundation Level Syllabus v4.0, Section 3.1.1.3, Section 3.2.1.3
For each of the test cases to be executed, the following table specifies the priority order and dependencies on other test cases
Which of the following test execution schedules is compatible with the logical dependencies and allows executing the test cases in priority order?
TC4, TC3, TC2, TC6, TC5. TC1
TC4, TC6, TC3, TC2, TC5, TC1
TC3, TC5, TC6, TC1, TC4, TC3
TC4, TC3, TC2, TC6, TC1, TC5
This answer is correct because it follows the logical dependencies and allows executing the test cases in priority order. TC4, TC3, and TC2 are executed first because they have the highest priority. TC6 is executed next because it has a logical dependency on TC2. TC1 is executed next because it has a logical dependency on TC5. Finally, TC5 is executed last because it has the lowest priority. References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 documents
A new web app aims at offering a rich user experience. As a functional tester, you have run some functional tests to verify that, before releasing the app, such app works correctly on several mobile devices, all of which are listed as supported devices within the requirements specification. These tests were performed on stable and isolated test environments where you were the only user interacting with the application. All tests passed, but in some of those tests you observed the following issue: on some mobile devices only, the response time for two web pages containing images was extremely slow.
Based only on the given information, which of the following recommendation would you follow?
You should open a defect report providing detailed information on which devices and by running which tests you observed the issue
The issue is related to performance efficiency, not functionality. Thus, as a functional tester, you should not open any defect report as all the functional tests passed
You should not open any defect report as the problem is most likely due to poor hardware equipment on the devices where you observed the issue
You should not open any defect report and inform the test manager that the devices on which you observed the issue should no longer be supported so that they will be removed from the requirements specification
As a functional tester, you should open a defect report providing detailed information on which devices and by running which tests you observed the issue. A defect report is a document that records the occurrence, nature, and status of a defect detected during testing, and provides information for further investigation and resolution. A defect report should include relevant information such as the defect summary, the defect description, the defect severity, the defect priority, the defect status, the defect origin, the defect category, the defect reproduction steps, the defect screenshots, the defect attachments, etc. Opening a defect report is a good practice for any tester who finds a defect in the software system, regardless of the type or level of testing performed. The other options are not recommended, because:
Which of the following statements about how different types of test tools support testers is true?
The support offered by a test data preparation tool is often leveraged by testers to run automated regression test suites
The support offered by a performance testing tool is often leveraged by testers to run load tests
The support offered by a bug prediction tool is often used by testers to track the bugs they found
The support offered by a continuous integration tool is often leveraged by testers to automatically generate test cases from a model
The support offered by a performance testing tool is often leveraged by testers to run load tests, which are tests that simulate a large number of concurrent users or transactions on the system under test, in order to measure its performance, reliability, and scalability. Performance testing tools can help testers to generate realistic workloads, monitor system behavior, collect and analyze performance metrics, and identify performance bottlenecks. The other statements are false, because:
The following chart represents metrics related to testing of a project that was competed. Indicate what is represented by tie lines A, B and the axes X.Y
A)
B)
C)
D)
Option A
Option B
Option C
Option D
Option D correctly explains what is represented by the lines A, B and the axes X, Y in a testing metrics chart. According to option D:
This information is essential in understanding and analyzing the testing metrics of a completed project.
References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Section 2.5.1, Page 35.
Which of the following coverage criteria results in the highest coverage for state transition based test cases?
Can't be determined
Covering all transitions at least once
Covering only start and end states
Covering all states at least once
Covering all transitions at least once is the highest coverage criterion for state transition based test cases, because it ensures that every possible change of state is tested at least once. This means that all the events that trigger the transitions, as well as the actions and outputs that result from the transitions, are verified. Covering all transitions at least once also implies covering all states at least once, but not vice versa. Therefore, option D is not the highest coverage criterion. Option C is the lowest coverage criterion, because it only tests the initial and final states of the system or component, without checking the intermediate states or transitions. Option A is incorrect, because the coverage criteria for state transition based test cases can be determined and compared based on the number of transitions and states covered. References = CTFL 4.0 Syllabus, Section 4.2.3, page 49-50.
What is test oracle?
The source of lest objectives
The source for the actual results
The source of expected results
The source of input conditions
A test oracle is a mechanism or principle that can be used to determine whether the observed behavior or output of a system under test is correct or not1. A test oracle can be based on various sources of expected results, such as specifications, user expectations, previous versions, comparable systems, etc2. References: ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus, Section 1.2.1, Page 91; ISTQB Glossary of Testing Terms, Version 4.0, Page 332.