Explanation / Rationale

a) Is not correct. The feedback is from stakeholders (e.g., business representative, end user), not from developers, so this feedback is not likely to inform managers which developers are more or less productive
b) Is not correct. Early and frequent feedback from stakeholders is not used by project managers to prioritize how they interact with the different stakeholders
c) Is correct. Obtaining feedback from stakeholders early and often in the software development process can be highly beneficial as it facilitates early communication of potential quality issues, can prevent misunderstandings about requirements, and ensures that any changes in stakeholder requirements are understood and implemented sooner
d) Is not correct. Early and frequent feedback can prevent the development of a product that does not meet stakeholder needs, and results in costly rework and missed deadlines, so, ideally there should be no delay. Also, the feedback is from stakeholders (not to them), which includes the end users, so the end users providing feedback will not aid the end users’ understanding

Explanation / Rationale

a) Is correct. This principle means that if the same tests are repeated over and over again, eventually these tests no longer find any new defects. This is probably why the tests all passed in this release as well
b) Is not correct. This principle says about the mistaken belief that just finding and fixing a large number of defects will ensure the success of a system
c) Is not correct. This principle says that a small number of components usually contain most of the defects
d) Is not correct. This principle states that testing all combinations of inputs and preconditions is not feasible

Explanation / Rationale

a) Is not correct. This is a common characteristic of white-box test techniques. Test conditions, test cases, and test data are derived from a test basis that may include code, software architecture, detailed design, or any other source of information regarding the structure of the software.
b) Is not correct. This is a common characteristic of white-box test techniques. Coverage is measured based on the items tested within a selected structure and the technique applied to the test basis
c) Is correct. This is a common characteristic of experience-based test techniques. This knowledge and experience include expected use of the software, its environment, likely defects, and the distribution of those defects is used to define tests
d) Is not correct. This is a common characteristic of black-box test techniques. Test cases may be used to detect gaps within requirements and the implementation of the requirements, as well as deviations from the requirements

Explanation / Rationale

The average development effort is $900,000 and the average test effort is $90,000 (calculated from the four projects).
The average test-to-development effort ratio is 1:10 ($90,000 : $900,000), which means that historically, on average, the test effort is 10% of the development effort.
So if the development effort is estimated to be $800,000, the estimated test effort is estimated as:

10% * $800,000 = 0.1 * $800,000 = $80,000.

Thus:
a) Is not correct
b) Is correct
c) Is not correct
d) Is not correct

Explanation / Rationale

a) Is correct. This test case is related to acceptance criteria 2 and 3, because we check if we can set price range (acceptance criterion 2) and if the results update dynamically after adjusting the price range filter (acceptance criterion 3)
b) Is not correct. This test case is not related to any of the acceptance criteria. It checks if the filter dynamically sets the default minimum and maximum price range, and not that a customer can do it
c) Is not correct. This test case is not related to any of the acceptance criteria. It checks the currency exchange feature, which is not discussed in this user story
d) Is not correct. This test case is not related to any of the acceptance criteria. It checks the application’s compatibility with different browsers, which is not discussed in this user story

Explanation / Rationale

a) Is not correct. Exploratory testing uses test charters, not a list of possible defects/failures. Although exploratory testing can incorporate the use of other test techniques, in this case fault attack is the most likely option
b) Is correct. This is a list of possible failures. Fault attacks are a methodical approach to the implementation of error guessing and require the tester to create or acquire a list of possible errors, defects and failures, and to design tests that will identify defects associated with the errors, expose the defects, or cause the failures
c) Is not correct. The tester is using a checklist of items to support their testing. Both error guessing and checklist-based testing use such lists, however, the list here is of possible failures, not test conditions, and so the MOST PROBABLE test technique is fault attack, which focuses on errors, defects and failures
d) Is not correct. BVA is based on an analysis of boundary values of equivalence partitions. The above list does not mention equivalence partitions or their boundaries

Explanation / Rationale

a) Is not correct. A member without a missed deadline can get a discount and a gift T-Shirt after 15 bicycle rentals
b) Is not correct. A member without a missed deadline can get a discount but no gift T-Shirt until they rented a bicycle 15 times
c) Is not correct. Non-members cannot get a discount, even if they did not miss a deadline yet
d) Is correct. No discount as a non-member that has also missed a deadline, but only members can receive a gift T-Shirt. Hence, the action is not correct

Explanation / Rationale

a) Is not correct. The fundamental strength of white-box test techniques is that the entire software implementation is taken into account during testing
b) Is not correct. White-box coverage measures provide an objective measure of coverage and provide the necessary information to allow additional tests to be generated to increase this coverage
c) Is not correct. White-box test techniques can be used to perform reviews (static testing)
d) Is correct. This is the weakness of the white-box test techniques. They are not able to identify the missing implementation, because they are based solely on the test object structure, not on the requirements specification

Explanation / Rationale

a) Is not correct. This acceptance criterion describes what rules or regulations the system must adhere to (in this case, the right to be forgotten). This is an example of a rule-oriented acceptance criterion
b) Is correct. This acceptance criterion describes an example scenario that must be realizable by the system. This is an example of a scenario-oriented acceptance criterion
c) Is not correct. This sentence looks more like a line of code that implements some business rule. Acceptance criteria should be written in collaboration with business representatives, and therefore should be written in language they understand. This sentence will most likely be unintelligible to these stakeholders
d) Is not correct. This acceptance criterion describes what rules or regulations the system must adhere to and how compliance will be ensured. Therefore, this is an example of a rule-oriented acceptance criterion, not a scenario-based acceptance criterion

Explanation / Rationale

Test TC 001 must come first, followed by TC 002, to satisfy dependencies. Afterwards, TC 003 to satisfy priority and then TC 004, followed by TC 005.
Thus:
a) Is correct
b) Is not correct
c) Is not correct
d) Is not correct

Explanation / Rationale
a) Is not correct. Retrospectives are used to capture lessons learned and to improve the development and testing process, not to document the acceptance criteria
b) Is correct. This is the standard way to document acceptance criteria
c) Is not correct. Verbal communication does not allow to physically document the acceptance criteria as part of a user story (”card” aspect in the 3C’s model)
d) Is not correct. Acceptance criteria are related to a user story, not a test plan. Also, acceptance criteria are the conditions that have to be fulfilled to decide if the user story is complete. Risks are not such conditions

Explanation / Rationale

a) Is not correct. Decision table testing is a black-box test technique, so it is specification-based, not structure-based – the test cases are not based on the decisions in the source code. In branch testing, the test cases are derived from knowledge of the control flow of the test object
b) Is not correct. Anticipation of potential defects is used in error guessing (an experience-based test technique), not in branch testing (a structure-based technique). In decision table testing, the test cases are derived from the specification that describes the business logic
c) Is not correct. If a test case is based on the knowledge of the control flow of the test object, it is a white-box test technique. Decision table testing is typically based on an analysis of business logic, so it is a black-box test technique. In branch testing, test cases are not derived from the specification – this would make it a black-box test technique. Branch testing is a white-box test technique, where test cases are derived based on the source code structure
d) Is correct. Decision table testing is a black-box test technique, so it is based on an analysis of the specified behavior of the test object without reference to its internal structure. Therefore, the test cases are independent of how the software is implemented. Branch testing is a white-box test technique, so test cases are based on an analysis of the test object’s internal structure and processing. As the test cases are dependent on how the software is designed and coded, they can only be created after the design or implementation of the test object

Explanation / Rationale

Considering each of the listed review types:

1. Technical review - This type of review is performed by technically qualified reviewers and led by a moderator. The objectives are to gain consensus and make decisions on technical problems while also evaluating quality and building confidence in the work product, generating new ideas, motivating and enabling authors to improve, and detecting anomalies
2. Informal review - The main objective is to detect anomalies. The process is not defined and does not require formal documented output
3. Inspection - This is the most formal review type, and it follows the complete generic review process. The primary objective is to find the most anomalies, and other objectives include evaluating quality and building confidence in the work product, motivating and enabling authors to improve, and collecting metrics that can be used to enhance the software development life cycle (SDLC), including the inspection process. The author cannot act as the review leader or scribe
4. Walkthrough - Led by the author, this type of review serves various objectives such as evaluating quality and building confidence in the work product, educating reviewers, gaining consensus, generating new ideas, motivating and enabling authors to improve, and detecting anomalies. Reviewers might perform an individual review before the walkthrough, but this is not mandatory

A. Includes objectives such as gaining consensus, generating new ideas, and motivating authors to improve (A)
B. The main objective is detecting potential defects and it generates no formal documented output (D)
C. The main objective is detecting potential defects and it requires metrics collection to support process improvement (C)
D. Includes objectives such as educating reviewers, gaining consensus, generating new ideas and detecting potential defects (B)

Thus:
a) Is not correct
b) Is correct. The correct match is: 1A, 2D, 3C, 4B
c) Is not correct
d) Is not correct

Explanation / Rationale

a) Is correct. Since 100% statement coverage is achieved, every statement, including the ones with defects, must have been executed and evaluated at least once
b) Is not correct. Coverage depends on what is tested, not on the number of test cases. For example, for code “if (x==0) y=1”, one test case (x=0) achieves 100% statement coverage, but two test cases (x=1) and (x=2) together achieve only 50% statement coverage
c) Is not correct. If there is a loop in the code there may be an infinite number of possible paths, so it is not possible to execute all the possible paths in the code
d) Is not correct. Exhaustive testing is not possible (see the seven testing principles section in the syllabus). For example, for code “input x; print x” any single test with arbitrary x achieves 100% statement coverage, but covers one input value

Explanation / Rationale

Considering each of the listed risks and their mitigations:

1. Long system responses (1) can be tested in performance testing (B)
2. Changes of consumers’ preferences (2) are usually out of our control, so usually we accept this risk (A)
3. Flooding of the server room (3) can cause significant loss, so we should transfer the risk, e.g., by buying an insurance policy (D)
4. That patients above a certain age receive inaccurate reports (4) suggests a potential boundary problem, which can be effectively detected with techniques like BVA (C)

Thus:
a) Is not correct
b) Is not correct
c) Is correct. The correct combinations of risk and mitigation are: 1B, 2A, 3D and 4C
d) Is not correct

Explanation / Rationale

Consider:

i. These behaviors are easily detectable while the software is running. Hence, dynamic testing shall be used to identify them
ii. This is an example of deviations from standards, which is a typical defect that is easier found with static testing
iii. If the software is executed during the test, it is dynamic testing
iv. Identifying defects as early as possible is the test objective of both static testing and dynamic testing
v. This is an example of gaps in the test basis traceability or coverage, which is a typical defect that is easier found with static testing

Thus:
a) Is not correct
b) Is not correct
c) Is not correct
d) Is correct

Explanation / Rationale

a) Is not correct. The manager is responsible for deciding what needs to be reviewed and allocating resources, such as staff and time, for the review
b) Is correct. The moderator (or facilitator) is responsible for ensuring that the review meetings run effectively, including managing time, mediating discussions, and creating a safe environment where everyone can voice their opinions freely
c) Is not correct. The chairperson is not a recognized role in reviews
d) Is not correct. The review leader is responsible for overseeing the review process, such as selecting the review team members, scheduling review meetings, and ensuring that the review is completed successfully

Explanation / Rationale

a) Is correct. This test covers two acceptance criteria: one about editing the document and one about saving changes
b) Is not correct. Acceptance criteria cover the editor activities, not the content owner activities
c) Is not correct. Scheduling the edited content for publication may be a nice feature, but it is not covered by the acceptance criteria
d) Is not correct. Acceptance criteria state about reassigning from an editor to the content owner, not to another editor

Explanation / Rationale

a) Is correct. In sequential development models, in the initial phases, testers participate in requirement reviews, test analysis, and test design. The executable code is usually created in the later phases, so dynamic testing cannot be performed early in the SDLC
b) Is not correct. Static testing can always be performed early in the SDLC
c) Is not correct. Test planning should be performed early in the SDLC before the test project begins
d) Is not correct. Acceptance testing can be performed when there is a working product. In sequential SDLC models the working product is usually delivered late in the SDLC

Explanation / Rationale

a) Is not correct. It is impossible to prove that there are no defects anymore in the system under test. See testing principle 1
b) Is not correct. See testing principle 7
c) Is correct. Testing finds defects and failures which reduces the level of risk and at the same time gives more confidence in the quality level of the test object
d) Is not correct. It is impossible to test all combinations of inputs (see testing principle 2)

Explanation / Rationale

a) Is not correct. Regression tests increase in number as the project progresses, as new regression tests are typically required as changes are made to the system. Similarly, the number of confirmation tests also typically increases as the project progresses as new confirmation tests are needed for each fix made to a system
b) Is not correct. It is the other way round. Confirmation tests are created and run when the test object is fixed, and regression tests are (ideally) run whenever the test object is enhanced (changed)
c) Is not correct. Confirmation testing verifies that a defect has been fixed correctly and so is concerned with testing changes to the test object. However, regression testing ensures that changes (including changes to the operational environment) do not have negative effects on unchanged software and so does not check that the operational environment remains unchanged
d) Is correct. Regression testing ensures that changes do not have negative effects on unchanged software. Confirmation testing verifies that a defect has been fixed – and so is concerned with changed code

Explanation / Rationale

The five listed descriptions and the corresponding review process activities are:

1. This describes part of the ‘communication and analysis’ activity
2. This describes part of the ‘fixing and reporting’ activity
3. This describes part of the ‘individual review’ activity
4. This describes part of the ‘planning’ activity
5. This describes part of the ‘review initiation’ activity

The generic review process from ISO/IEC 20246, which is outlined in the syllabus, comprises the following activities in this logical order:

• Planning (4)
• Review initiation (5)
• Individual review (3)
• Communication and analysis (1)
• Fixing and reporting (2)

Thus:
a) Is not correct
b) Is correct. The correct sequence of activities is: 4 – 5 – 3 – 1 – 2
c) Is not correct
d) Is not correct

Explanation / Rationale

a) Is correct. Test automation can provide measures that are too complicated for humans to derive, such as white-box test coverage measures for all but the most trivial code
b) Is not correct. By using test tools the responsibility for the testing is NOT shared with the tool vendor as the vendor is not involved in the testing, and it is the tester’s responsibility. The only possible responsibility that could be assigned to the tool vendor is if the tool fails to work as expected and provides incorrect test results
c) Is not correct. Testers still need to perform critical thinking when analyzing anomalies in the test results to determine their likely cause
d) Is not correct. Neither testers nor tools can generate test cases simply from an analysis of the program code as the code is the implementation and provides no information on the expected results, which will need to come from another part of the test basis, such as the design specification

Explanation / Rationale

The following three transitions:

“REQUESTING -> CONFIRMED”
“WAITING LIST -> CONFIRMED”
“WAITING LIST -> END”

cannot appear in the same test case, which suggests that at least three test cases are required. All the other transitions can appear in combination with one or more of these three transitions, so we need a minimum of three test cases. In fact, only three sequences are possible:

TC1: START (Room request) → REQUESTING (Available) → CONFIRMED (Pay) → END
TC2: START (Room request) → REQUESTING (Not available) → WAITING LIST (Available) → CONFIRMED (Pay) → END
TC3: START (Room request) → REQUESTING (Not available) → WAITING LIST (Cancel) → END

Thus:
a) Is correct
b) Is not correct
c) Is not correct
d) Is not correct

Explanation / Rationale

a) Is not correct. A lack of usability provided through the user interface can be detected through a review using a suitable checklist, but the lack of usability can also be identified by getting several typical users to dynamically test the user interface and provide feedback on its usability
b) Is correct. A code review can detect code that cannot be reached by any path, however dynamic tests can only exercise reachable code and cannot determine that code cannot be reached without running every possible combination of inputs and input states, which is impractical for real code
c) Is not correct. Poor response times for most of the expected users are difficult to determine without executing the code (i.e., by static testing), so in this situation dynamic testing could find a defect, but static testing is unlikely to find it
d) Is not correct. A review of the code by someone who is aware of the required features could detect that the required features had not been implemented in the code, and dynamic testing could also be used to determine that these required features had not been implemented

Explanation / Rationale

a) Is not correct. This should be a team activity and not overruled by one team member
b) Is correct. If test estimates are not the same, but the variation in the results is small, applying rules like “accept the number with the most votes” can be applied
c) Is not correct. There is no consensus yet as some say 13, others say 8
d) Is not correct. A feature should not be removed only because the team cannot agree on the test estimates

Explanation / Rationale

a) Is not correct. Collaborative user story writing means that all stakeholders create the user stories collaboratively, to obtain the shared vision
b) Is correct. Collaborative user story writing means that all stakeholders create the user stories collaboratively, to obtain the shared vision
c) Is not correct. Collaborative user story writing means that all stakeholders create the user stories collaboratively, to obtain the shared vision
d) Is not correct. This is the list of properties that each user story should have, not the description of the collaboration-based approach

Explanation / Rationale

a) Is not correct. Most work products can be examined using some form of static testing, and a contract must be interpretable by humans and so could be reviewed, which is a form of static testing
b) Is not correct. Most work products can be examined using some form of static testing, and a test plan must be interpretable by humans and so could be reviewed, which is a form of static testing
c) Is correct. Most work products can be examined using some form of static testing; however it is not suitable for work products that are too complex for human interpretation and should not be analyzed by tools, and encrypted code is too complex for humans and if it is properly encrypted it will not be analyzable by most tools
d) Is not correct. Most work products can be examined using some form of static testing, and a test charter must be interpretable by humans and so could be reviewed, which is a form of static testing

Explanation / Rationale

There are two equivalence partitions that are not yet covered, which correspond to “student discount” and “pensioner discount”.
a) Is not correct. CY – BY = 64, so these inputs correspond to the already covered “no discount” partition
b) Is correct. CY – BY = 65, so these inputs correspond to a partition that is not yet covered (“pensioner discount”)
c) Is not correct. CY – BY = –65, so these inputs correspond to the already covered “error message” partition
d) Is not correct. CY – BY = 18, so these inputs correspond to the already covered “no discount” partition
e) Is correct. CY – BY = 0, so these inputs correspond to a partition that is not yet covered (“student discount”)

Explanation / Rationale

The ‘exhaustive testing is impossible’ principle is concerned with the fact that it is not feasible to test every possible variation of test inputs in all different circumstances, except in trivial cases. Instead, testing utilizes test techniques, test case prioritization, and risk-based testing to sample from the set of possibilities and focus testing efforts.
a) Is not correct. The principle states that it is not feasible to test everything except in trivial cases. Testing everything would require testing every possible variation of test inputs in all different circumstances, which is generally infeasible as there will be a practically infinite number. Testing every possible specified output will not address this problem as the relationship between inputs and specified outputs can be different for each test object. Sometimes there may be a practically infinite number of possible specified outputs (e.g., when there are several variables representing real numbers), whereas at other times there may be just two specified outputs, such as with a single variable that can be either true or false
b) Is not correct. The principle states that it is not feasible to test every possible variation of test inputs in all different circumstances. This is because for non-trivial systems there is a practically infinite number. Therefore, in practice, documenting all possible test input variations would be impractical as it would take an infinite length of time
c) Is not correct. Starting testing as early as possible with reviews and other static testing approaches will not address the problem of there being too many possible test cases. The ‘early testing saves time and money’ principle is concerned with fixing defects early on to prevent the occurrence of subsequent defects in derived work products, thereby reducing costs and the likelihood of failures
d) Is correct. The use of equivalence partitioning and boundary value analysis to generate test cases is one way to address the principle as these test techniques provide a systematic way to derive a finite subset of all possible test cases

Explanation / Rationale

In the three-point estimation technique:

E = (optimistic + 4*most likely + pessimistic)/6

E = (2+(4*11)+14)/6 = 10

Thus:
a) Is not correct
b) Is not correct
c) Is not correct
d) Is correct

Explanation / Rationale

a) Is not correct. Estimating the test effort is part of test planning
b) Is correct. This is an example of defining test conditions which is a part of test analysis
c) Is not correct. Using test techniques to derive coverage items is a part of test design
d) Is not correct. Reporting defects found during dynamic testing is a part of test execution

Explanation / Rationale

a) Is correct. This is done by the testers
b) Is not correct. The product backlog is built and maintained by the product owner
c) Is not correct. This is done by the development team
d) Is not correct. This is a managerial role
e) Is correct. This is done by the testers

Explanation / Rationale

a) Is not correct. In exploratory testing, test cases are usually created during the exploratory testing session, alongside test analysis, test implementation and test execution
b) Is not correct. In exploratory testing, tests are simultaneously designed, executed, and evaluated while the tester learns about the test object
c) Is not correct. Exploratory testing results depend heavily on the tester’s experience, so even if the results of exploratory testing can be used as a predictor of risk and used to assess whether there will be fewer or more defects, for example, compared to the previous exploratory testing session, they are not a good example of reliable defect prediction models that can predict the number of remaining defects
d) Is correct. During exploratory testing, the testers can use any techniques that they find useful

Explanation / Rationale

a) Is not correct. The test automation approach is defined by testers with the help of developers and business representatives
b) Is not correct. The test strategy is decided in collaboration with the developers
c) Is not correct. Testers, developers, and business representatives are part of the whole team approach
d) Is correct. Testers will work closely with business representatives to ensure that the desired quality levels are achieved. This includes supporting and collaborating with them to help them create suitable acceptance tests

Explanation / Rationale

a) Is not correct. DevOps generally increases the visibility of non-functional quality characteristics, such as performance and reliability
b) Is not correct. Automated processes like continuous integration/continuous delivery (CI/CD) used in DevOps facilitate stable test environments
c) Is not correct. Automated processes like CI/CD used in DevOps generally reduce the need for manual testing
d) Is correct. DevOps implementation can pose several risks and challenges, including the need to define and set up the delivery pipeline, introduce and maintain CI/CD tools, and establish and maintain test automation

Explanation / Rationale

a) Is correct. Debugging is the process of finding, analyzing, and removing the causes of failures in a component or system
b) Is not correct. Testing is the process concerned with planning, preparation and evaluation of a component or system and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects. It is not related to fixing causes of failures
c) Is not correct. Requirement elicitation is the process of gathering, capturing, and consolidating requirements from available sources. It is not related to fixing causes of failures
d) Is not correct. Defect management is the process of recognizing, recording, classifying, investigating, resolving, and disposing of defects. It is not related to fixing causes of failures

Explanation / Rationale

From the graph we have:

A(4)=6 and A(3)=8 (the last two gray boxes).

From the formula we obtain:

E(5) = (3*A(4) + A(3)) / 4 = (3*6+8) / 4 = 26 / 4 = 6.5 person-days.

Thus:
a) Is not correct
b) Is not correct
c) Is correct
d) Is not correct

Explanation / Rationale

a) Is not correct. The expected result is “the application should accept the provided input and create the user”. The actual result is “The application hangs up after entering “Test input. $ä””.
b) Is not correct. There is a reference to the test case and to the related requirement and it states that the defect is rejected. Also, the defect status would not be very helpful for the developers
c) Is correct. We do not know in which test environment the anomaly was detected, and we also do not know which application (and its version) is affected
d) Is not correct. The defect report states that the anomaly is urgent, that it is a global issue (i.e., many, if not all, test administration accounts are affected) and states the impact is high for business stakeholders

Explanation / Rationale

Some defect types that can only be detected by static testing, such as unreachable code, design patterns not implemented as desired and defects in non-executable work products. Some defect types that can be found by both static testing and dynamic testing, such as a programming defect that can be observed by a reviewer in a code review and which causes an observable failure during dynamic testing. And some defect types that can only be detected by dynamic testing, such as performance issues or memory issues that can only be observed when executing the code or system.

Thus:
a) Is not correct
b) Is not correct
c) Is correct
d) Is not correct