Explanation / Rationale

a) Is correct. 19 covers the “no discount” partition, 20 covers the “50% discount” partition, and 30 covers the “10% discount” partition. These three values cover all three of the valid equivalence partitions
b) Is not correct. 11 and 12 cover the “no discount” partition, while 20 covers the “50% discount” partition, so covering two of the three valid equivalence partitions
c) Is not correct. 1 covers the “no discount” partition, while 10 and 50 cover the “10% discount” partition. The “50% discount” partition is not covered, so overall two of the three valid equivalence partitions are covered
d) Is not correct. 29 and 31 cover the “no discount” partition, while 10 and 30 cover the “10% discount” partition. The “50% discount” partition is not covered, so overall two of the three valid equivalence partitions are covered

Explanation / Rationale

There are three equivalence partitions: {…, –2, –1}, {0, 1, 2}, {3, 4, …}.
For 2-value BVA all the boundary values for all the equivalence partitions must be covered.
The boundary values are –1 (for the “temperature too low” partition), 0, 2 (for the “temperature OK” partition) and 3 (for the “temperature too high” partition).

Thus:
a) Is not correct
b) Is not correct
c) Is correct. The correct option is: –1, 0, 2, 3
d) Is not correct

Explanation / Rationale

a) Is not correct. The root cause is the distraction that the programmer experienced while programming
b) Is not correct. Accepting invalid inputs is a failure
c) Is not correct. The error is the mistaken thinking that resulted in putting the defect in the code
d) Is correct. The problem in the code is a defect

Explanation / Rationale

According to the dependencies, SEARCH tests must be executed first, then VIEW tests, then ADD tests and, at the end, ORDER tests. Within each of these groups the order is determined by the priorities of the test cases.
So, TC1 must be executed first, then TC2, then TC4 followed by TC3, and then TC5 as the last one.
So, the ordering is: TC1, TC2, TC4, TC3, TC5.
Thus:
a) Is correct. TC3 will be the fourth test case executed
b) Is not correct
c) Is not correct
d) Is not correct

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

a) Is not correct. Risk monitoring is part of risk control, not risk analysis
b) Is not correct. Risk identification itself does not allow us to implement risk mitigation activities. The mitigating actions are defined during the risk control phase
c) Is correct. This is an example of how risk analysis influences the thoroughness and scope of testing
d) Is not correct. Coverage items are derived using test techniques, not through risk analysis

Explanation / Rationale

a) Is not correct. Usability testing is business facing testing that critiques the product (Q3)
b) Is not correct. Functional testing is business facing testing (Q2)
c) Is not correct. User acceptance testing is business facing testing that critiques the product (Q3)
d) Is correct. Component integration testing is technology facing testing that supports the team (guides the development) (Q1)

Explanation / Rationale

Considering each of the listed tool categories:

i. Collaboration tools – facilitate communication. Communication does not include the facilitation of test execution
ii. DevOps tools - support the DevOps delivery pipeline, workflow tracking, automated build process(es) and CI/CD. The delivery pipeline and CI/CD both include the facilitation of test execution, such as component testing for CI
iii. Management tools – increase the test process efficiency by facilitating management of the SDLC, requirements, tests, defects and configuration. The management of these items does not include the facilitation of test execution
iv. Non-functional testing tools – allow the tester to perform non-functional testing that is difficult or impossible to perform manually. Non-functional testing can include both static testing and dynamic testing, including test execution
v. Test design and implementation tools – facilitate generation of test cases, test data and test procedures. The generation of this testware does not include the facilitation of test execution

Thus:
a) Is not correct
b) Is correct. Both DevOps tools (ii) and Non-functional testing tools (iv) facilitate test execution
c) Is not correct
d) Is not correct

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

Considering each of the listed test activities and their output testware:

A. Test analysis - prioritized test conditions (4) (e.g., acceptance criteria), and defect reports for defects identified in the test basis
B. Test design - prioritized test cases, test charters, coverage items (1), test data requirements, and test environment requirements
C. Test implementation - test procedures, automated test scripts, test suites, test data, test execution schedule (3), and test environment elements such as stubs, drivers, simulators, and service virtualizations
D. Test completion - test completion report, documented lessons learned, action items for improvement, and change requests (2) (as product backlog items)

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

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

Considering each of the listed tool categories and their descriptions:

A. Static testing tools – support the tester in performing reviews and static analysis (4)
B. Tools supporting scalability and deployment standardization – For example, virtual machines, containerization tools (3)
C. DevOps tools – support the DevOps delivery pipeline, workflow tracking, automated build process(es), continuous integration/continuous delivery (CI/CD) (1)
D. Collaboration tools – facilitate communication (2)

Thus:
a) Is not correct
b) Is not correct
c) Is correct. The correct match is: 1C, 2D, 3B, 4A
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

There are three equivalence partitions: {..., 10, 11}, {12}, and {13, 14, ...}.
The boundary values are 11, 12 and 13. In the three-point boundary value analysis for each boundary, we need to test the boundary and both its neighbors, so:

• for 11 we test 10, 11, 12

• for 12 we test 11, 12, 13

• for 13 we test 12, 13, 14

Altogether we need to test 10, 11, 12, 13, and 14

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

Explanation / Rationale

a) Is correct. Test design involves using test conditions to create test cases and other necessary testware, such as test data requirements and test charters for exploratory testing. Test environment requirements are also specified, including the necessary infrastructure and tools
b) Is not correct. Test execution involves executing test cases (as part of test procedures), however it does not directly cover the other testware mentioned in the question, such as test data requirements, test environment requirements and test conditions
c) Is not correct. Test analysis is used to identify the features that require testing. The test basis is analyzed and defined as test conditions, which are then prioritized along with related risks. While this activity involves working with test conditions, it does not cover the other testware mentioned in the question, such as test data requirements, test environment requirements and test cases
d) Is not correct. Test implementation includes the generation of test procedures, such as manual and automated test scripts, which are created from test cases and may be assembled into test suites. Test procedures are prioritized and arranged in a test execution schedule. Test data is created, and the test environment built, and its set up verified. While this activity involves explicitly working with test cases, and may use test data requirements and test environment requirements to create test data and the test environment, it does not cover test conditions

Explanation / Rationale

a) Is not correct. The rule-oriented format includes formats like bullet point verification lists or tabulated forms of input-output mappings, explicitly showing the rules to be followed. Given/When/Then is a scenario-oriented format because it describes a scenario to be verified
b) Is correct. This is a Given/When/Then format, which is scenario-oriented
c) Is not correct. There no "product-oriented" format of acceptance criteria
d) Is not correct. There is no "process-oriented" format of acceptance criteria

Explanation / Rationale

There are 12 boundary values for the final result values: 0, 50, 51, 60, 61, 70, 71, 80, 81, 90, 91, and 100.
The test cases cover six of them (TC1 – 91, TC2 – 50, TC3 – 81, TC4 – 60, TC5 – 70 and TC7 – 51).
Therefore, the test cases cover 6/12 = 50%.
Thus:
a) Is correct
b) Is not correct
c) Is not correct
d) Is not correct

Explanation / Rationale

a) Is not correct. The benefits of retrospectives include team bonding and learning from sharing issues, and better collaboration between developers and testers through reviewing and improving working practices. Calling out individuals who a team member may feel did not fully contribute to achieving quality as required by the whole-team approach will not contribute to this team bonding and collaboration
b) Is correct. During the retrospective, the group discusses what aspects of the project were successful and should be retained, as well as areas that could be improved, and how to do so
c) Is not correct. The benefits of retrospectives are based on increased effectiveness and efficiency through process improvements; they are not an opportunity to let off steam and criticize management and customers. Also, the results are recorded, usually in the test completion report, so anything said in the meeting could be read by other stakeholders
d) Is not correct. Retrospectives are meetings that are typically held at the end of an iteration where team members will focus on discussing quality-related issues that have occurred in the current iteration. They are not used for making plans or technical decisions for the next iteration; this would be done in the iteration planning meeting at the start of the next iteration

Explanation / Rationale

a) Is not correct. Test progress reports are mostly used during test monitoring and control, and test completion, not during test design
b) Is correct. A test completion report is prepared during test completion, when a project, test level, or test type is complete and when, ideally, its exit criteria have been met. This report uses information from test progress reports and other data
c) Is not correct. Test progress reports are mostly used during test monitoring and control, and test completion, not during test analysis
d) Is not correct. Test progress reports are most used during test monitoring and control, and test completion, not during test planning

Explanation / Rationale

Considering:

• The test basis for acceptance testing is the user’s business needs (1D)
• Communication between components is tested during component integration testing (2B)
• Failures in logic can be found during component testing (3A)
• Business rules are the test basis for system testing (4C)

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

Explanation / Rationale

a) Is not correct. Finding and fixing defects in the test object is not a typical test objective as although identifying defects is an objective of testing, fixing defects is not a testing activity
b) Is not correct. Maintaining effective communications with developers is not a typical test objective as although it is useful in achieving other objectives of testing, such as providing stakeholders with information that enables them to make informed decisions, it is not a primary reason for performing testing
c) Is not correct. Validating that legal requirements have been met is not a typical test objective because validation is concerned with checking whether the system meets users’ and other stakeholders’ needs in its operational environment. Checking that legal requirements have been met is a form of verification
d) Is correct. Building confidence in the quality of the test object is achieved by executing tests that pass

Explanation / Rationale

a) Is not correct. The test pyramid emphasizes having a larger number of tests at the lower test levels
b) Is correct. It is not true that near the top of pyramid, test automation should be more formal
c) Is not correct. Usually component testing and component integration testing are automated using API-based tools
d) Is not correct. For system testing and acceptance testing, the automated tests are typically created using GUI-based tools

Explanation / Rationale

a) Is not correct. Impediments to testing can be high level and business-related, so this is an important piece of information for business stakeholders
b) Is correct. Branch testing is a technical metric used by developers and technical testers. This information is of no interest to business representatives
c) Is not correct. Test progress is project related, so it may be useful for business representatives
d) Is not correct. Risks impact product quality, so it may be useful for business representatives

Explanation / Rationale

i. Is true. Having domain knowledge is an important tester skill
ii. Is false. This is a task of the business analyst together with the business representative
iii. Is true. Being a good team player is an important skill
iv. Is false. Planning and organizing the work of the team is a task of the test manager or, mostly in an Agile software development project, the whole team and not just the tester
v. Is true. Critical thinking is one of the most important skills of testers

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

Explanation / Rationale

a) Is not correct. The paragraph contains information on test levels and exit criteria, which are part of the test approach
b) Is not correct. The paragraph contains information on test levels and exit criteria, which are part of the test approach
c) Is not correct. The paragraph contains information on test levels and exit criteria, which are part of the test approach
d) Is correct. The paragraph contains information on test levels and exit criteria, which are part of the test approach

Explanation / Rationale

a) Is not correct. Traceability between the mitigated risks and passing test cases provides little information, because to be mitigated (by testing) the risks would need to have a corresponding passing test case. To be able to assess residual risk, traceability between all risks and test results needs to be available, so that the risks that do not have a corresponding passing test can be identified as the residual risks
b) Is correct. Traceability between user requirements and test execution results provides an indication of which user requirements have been tested and so provides a means of measuring project progress (in the context of testing) against business goals
c) Is not correct. It is not clear that failing test cases provide an indication of tester skills any more than passing test cases. It would partly depend on the test objective (e.g., building confidence or causing failures). Also, such measurement of testers based on passing and failing test cases can be counter-productive as it could cause the testers to optimize their testing based on that metric rather than the test objective
d) Is not correct. Traceability between the identified risks and written test conditions provides a means of determining which further test conditions need to be written. Determining which risks are worth testing is part of risk management, and risk mitigation in particular

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. Test monitoring involves the ongoing checking of all activities and comparison of actual progress against the test plan. Test control involves taking the actions necessary to meet the test objectives of the test plan. No test data are prepared during these activities
b) Is not correct. Test analysis includes analyzing the test basis to identify test conditions and prioritize them. Test design includes elaborating the test conditions into test cases and other testware. Test data are not prepared during these activities
c) Is correct. Test implementation includes creating or acquiring the testware necessary for test execution (e.g., test data)
d) Is not correct. Test completion activities occur at project milestones (e.g., release, end of iteration, test level completion), so it is too late for preparing test data

Explanation / Rationale

a) Is not correct. Although it is correct to say that in Agile software development, some of the test management tasks may be handled by the Agile team itself, the testing role is not primarily the responsibility of a single individual from outside the team. Instead the testing is more likely to be performed by various team members following the whole-team approach
b) Is not correct. The test management role primarily involves activities related to test planning, test monitoring and control, and test completion. So, although this statement is partially correct, it is wrong to say that the testing role is primarily responsible for test monitoring and control
c) Is correct. In Agile software development, some of the test management tasks may be handled by the Agile team itself. However, for test activities that span multiple teams within an organization, test managers outside of the development team may perform these tasks
d) Is not correct. The test management role primarily involves activities related to test planning, test monitoring and control, and test completion, while the testing role is primarily responsible for the technical and engineering aspects of testing, such as test analysis, test design, test implementation, and test execution. Thus the test management role is not normally responsible for test analysis and test design, although it is correct to say that the testing role is primarily responsible for test implementation and execution

Explanation / Rationale

a) Is correct. For a complex configuration item (e.g., a test environment), CM records the items it consists of, their relationships, and versions
b) Is not correct. CM tools do not execute test cases and do not calculate coverage
c) Is not correct. A CM tool is not a license management tool
d) Is not correct. CM tools do not generate test data

Explanation / Rationale

a) Is not correct. QA concentrates on process improvement and implementation, using a preventive approach to avoid errors and defects, while testing is a form of QC that is used to detect defects
b) Is correct. QC aims to achieve appropriate levels of quality by focusing on identifying and correcting product defects. Testing is a significant part of QC and helps to uncover these defects
c) Is not correct. Although testing is a significant part of QC and helps to uncover defects, other (non-testing) techniques utilized in QC include formal methods like model checking and proof of correctness, as well as simulation and prototyping
d) Is not correct. QA concentrates on process improvement and implementation, using a preventive approach to avoid errors and defects, while testing is a form of QC that is used to detect defects

Explanation / Rationale

a) Is correct. The number of defects found is related to the test object quality
b) Is not correct. This is the measure of the test efficiency not the test object quality
c) Is not correct. The number of test cases executed does not tell us anything about the quality; test results might do
d) Is correct. defect density is related to the test object quality
e) Is not correct. Time to repair is a process metric. It does not tell us anything about the product quality

Explanation / Rationale

The ‘absence-of-defects fallacy’ is concerned with the idea that ensuring correctness in accordance with the requirements (i.e., verifying the absence of implementation defects) does not guarantee user satisfaction with the system. To address this it is also necessary to validate that the system meets users' needs and expectations, fulfills business objectives, and outperforms competing systems.
a) Is not correct. The ‘testing shows the presence, not the absence of defects’ principle explains that while testing can detect the existence of defects in the test object, it is not possible to demonstrate that there are no defects and, therefore, guarantee its correctness. Therefore, explaining that it is not possible for testing to show the absence of defects would partially address this principle, not the ‘absence-of-defects’ fallacy
b) Is correct. By supporting the end user to perform acceptance testing it should be possible to validate that the system meets users' needs and expectations
c) Is not correct. It is not possible to ensure that no implementation defects remain in the delivered system as the ‘testing shows the presence, not the absence of defects’ principle explains that while testing can detect the existence of defects in the test object, it is not possible to demonstrate that there are no defects and, therefore, guarantee its correctness
d) Is not correct. Modifying tests that cause no failures to ensure few defects remain is one way to address the ‘tests wear out’ principle. This principle is concerned with the idea that repeating identical tests on unaltered code is unlikely to uncover novel defects and therefore, modifying tests may be essential. This will not validate that the system meets users' needs and expectations

Explanation / Rationale

a) Is not correct. Retrospectives are more useful for identifying improvement opportunities and have little importance for clients
b) Is not correct. Business representatives are not giving feedback about the product itself. Therefore, there is no financial gain to the organization
c) Is correct. Regularly conducted retrospectives, when appropriate follow up activities occur, are critical to continual improvement of development and testing
d) Is not correct. Courage and respect are values of Extreme Programming and are not closely related to retrospectives

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 not correct. It is more often used in behavior-driven development (BDD)
b) Is not correct. It is the description of test-driven development (TDD)
c) Is correct. In acceptance test-driven development (ATDD) tests are written from acceptance criteria as part of the design process
d) Is not correct. It is used in BDD

Explanation / Rationale

a) Is not correct. The book provides general guidance, and is not a formal requirements document, a specification, or a set of use cases, user stories, or business processes
b) Is not correct. While you could consider the list as a set of test charters, it more closely resembles the list of test conditions to be checked
c) Is correct. The list of user interface best practices is the list of test conditions to be systematically checked
d) Is not correct. The tests are not focused on failures that could occur, but rather on knowledge about what is important for the user, in terms of usability

Explanation / Rationale

a) Is correct. Performing only black-box testing does not provide a measure of actual code coverage. White-box coverage measures provide an objective measurement of coverage and provide the necessary information to allow additional tests to be generated to increase this coverage, and subsequently increase confidence in the code
b) Is not correct. This statement is correct, but it has nothing to do with black-box testing
c) Is not correct. In general there are no subsumes relationships between white-box and black-box techniques
d) Is not correct. White-box techniques are used to design tests based on the test object itself, while black-box techniques are used to design tests based on the specification. Therefore, there is no relation between coverage items derived from these two types of techniques

Explanation / Rationale

a) Is not correct. In agile software development, deliverables are produced in each iteration, and the frequent delivery of increments necessitates extensive regression testing. Although some (or all) of this regression testing may be automated, the regression testing (automated or not) cannot be replaced by system test automation
b) Is correct. If a sequential development model is used, then early in the lifecycle no code is available for execution, and so during this time static testing (e.g., reviews) is performed. Later in the lifecycle, when code is available for execution, dynamic testing is possible. Note, however, that preparation for dynamic testing will often occur early in any software development lifecycle
c) Is not correct. If an iterative development model, like agile software development, is used, then component tests may well be used for regression testing for each iteration. In which case, there is a strong argument for automating these component tests, which will have to be run frequently, and there is unlikely to be a strong argument for developers performing these component tests manually
d) Is not correct. In most incremental development models, deliverables are produced in each increment, requiring both static and dynamic testing at all test levels for each increment delivered

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