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. Performing the impact analysis will not give information about completeness of tests. Analyzing the impact analysis of changes will help to select the right test cases for execution
b) Is not correct. Traceability does not give information about the estimated level of residual risk if the test cases are not traced back to risks
c) Is correct. Performing the impact analysis of the changes helps in selecting the test cases for the regression test
d) Is not correct. Analyzing the traceability between the test basis, test objects and test cases does not help in selecting test data to achieve the assumed coverage of the test object. Selecting test data is more related to test analysis and test implementation, not traceability

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

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

Only third-party executable code cannot be reviewed.
Thus:
a) Is not correct
b) Is not correct
c) It is correct
d) Is not correct

Explanation / Rationale

Consider:

i. It is a Project risk
ii. It is a Product risk
iii. It is a Product risk
iv. It is a Project risk
v. It is a Product risk

Thus:
a) Is correct
b) Is not 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

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

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

a) Is not correct. Test automation does not introduce unknown regressions in production
b) Is correct. Wrong allocation of effort to maintain testware is a risk
c) Is not correct. Test tools must be selected so that they and their testware can be relied upon
d) Is not correct. The primary goal of test automation is to reduce manual testing. So, this is a benefit, not a risk

Explanation / Rationale

The equivalence partitions are: {…, 99, 100}, {101, 102, …, 198, 199}, {200, 201, …}.
Thus, there are 4 boundary values, which are: 100, 101, 199 and 200.
In 2-value BVA, for each boundary value there are two coverage items (the boundary value and its closest neighbor belonging to the adjacent partition). As the closest neighbors are also boundary values in the adjacent partition, then there are just four coverage items.

Thus:
a) Is not correct. Only 100 and 200 are valid coverage items for 2-value BVA, so we achieve 50% coverage
b) Is not correct. Only 100 and 200 are valid coverage items for 2-value BVA, so we achieve 50% coverage
c) Is not correct. Only 100 and 101 are valid coverage items for 2-value BVA, so we achieve 50% coverage
d) Is correct. 101, 199 and 200 are valid coverage items for 2-value BVA, so we achieve 75% coverage

Explanation / Rationale

a) Is not correct. Feedback can improve the test process, but if one only wants to improve future projects, the feedback does not need to come early or frequently
b) Is not correct. Feedback is not used to prioritize requirements
c) Is not correct. The quality of changes can be measured in multiple ways
d) Is correct. Early and frequent feedback allows for the early communication of potential quality problems

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

The domain for the password length has three equivalence partitions:

• passwords too short {0, 1, …, 4, 5}
• passwords OK {6, 7, …, 11, 12}
• passwords too long {13, 14, …}

To achieve full coverage for 3-value BVA we need to test the following values:

0, 1, 4, 5, 6, 7, 11, 12, 13, 14.

Since 2-value BVA is already covered, this means that we have already tested the passwords of length:

0, 5, 6, 12 and 13.

This means that the additional lengths that need to be covered to move from 2-value to 3-value are:

1, 4, 7, 11 and 14.

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

Explanation / Rationale

Considering:

Testing and quality assurance are not the same. Testing is the process consisting of all software development lifecycle (SDLC) activities, both static and dynamic, 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. Quality assurance is focused on establishing, introducing, monitoring, improving, and adhering to the quality-related processes.

Thus:
a) Is not correct
b) Is not correct
c) Is not correct
d) Is 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

a) Is correct. The ‘tests wear out’ 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. By using high-level test conditions to generate new tests each time, the tests will not be identical and should not ‘wear out’
b) Is not correct. The ‘absence-of-defects fallacy’ principle is concerned with ensuring that users’ needs are fulfilled even if lots of testing is done and no defects are found (i.e., validation is also necessary). The use of high-level test conditions to generate test cases and execute tests does not directly address this concern
c) Is not correct. 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. This is typically addressed by starting testing (both static and dynamic) as early as possible, but this is not addressed by using high-level test conditions to generate test cases and execute tests
d) Is not correct. The ‘Defects cluster together’ principle is concerned with the distribution of defects in a system, which typically follows a Pareto distribution. The use of high-level test conditions to generate test cases and execute tests does not address this concern, which is typically addressed by risk-based testing

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

a) Is not correct. The miscalculation of bonuses is a failure by the system, not a defect
b) Is not correct. The system not suitably supporting disabled users is a failure which eventually results in a fine, but the fine itself is not a failure (it appears to be the correct functioning of the regulatory system)
c) Is correct. The error is made by the programmer and this mistake is caused by them working under severe time pressure, which is the root cause of the subsequent defect
d) Is not correct. The poor design of the user interface, which does not suitably address disabled users, is a design defect caused by the designer error. Thus the design of the user interface includes a design defect not a designer error

Explanation / Rationale

a) Is not correct. Testers should review work products as soon as drafts are available to enable early testing as part of a shift-left approach. If they waited until the next development phase, then unnecessary development (and test) work could be started on unreviewed, flawed work products
b) Is correct. Testers should review work products as soon as drafts are available to enable early testing as part of a shift-left approach
c) Is not correct. Testers typically review work products that form the test basis as part of test analysis, not before test analysis and design
d) Is not correct. Testers should review work products as soon as drafts are available to enable early testing as part of a shift-left approach. Waiting until they are published means that any defects that could be found by tester review will be in the published document

Explanation / Rationale

In branch testing the coverage items are branches, which are represented by the edges of a control flow graph. There are 8 edges in the control flow graph.
Thus:
a) Is not correct
b) Is not correct
c) Is correct
d) Is not correct

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

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. Validating that documented requirements are met is incorrect as validation is concerned with meeting user requirements and expectations, while verification is concerned with meeting specified requirements, so this would be correct if we replaced ‘validating’ with ‘verifying’
b) Is correct. Causing failures and identifying defects is probably the most common objective of dynamic testing
c) Is not correct. Initiating errors and identifying root causes is incorrect because testers do not initiate errors, they try to cause failures. Errors are typically made by developers (and cannot really be initiated) and result in defects, which testers attempt to identify either directly through static testing or indirectly through failures with dynamic testing. Identifying root causes is useful but is part of debugging, which is a separate activity to testing
d) Is not correct. Verifying the test object meets user expectations is incorrect as verification is concerned with checking specified (documented) requirements are met, while validation is concerned with meeting user requirements and expectations, so this would be correct if we replaced ‘verifying’ with ‘validating’

Explanation / Rationale

a) Is not correct. Priorities for user stories are determined by the business representative together with the development team
b) Is not correct. Testers focus on both functional and non-functional aspects of the system to be tested
c) Is correct. According to the syllabus, this is one of the ways testers add value to iteration and release planning
d) Is not correct. Early test design is not part of release planning. Early test design does not automatically guarantee the release of quality software

Explanation / Rationale

Consider:

i. Is true. Faster product release and faster time to market is an advantage of DevOps
ii. Is false. Typically, we need less effort for manual tests because of the use of test automation
iii. Is true. Constant availability of executable software is an advantage
iv. Is false. More regression tests are needed
v. Is false. Not everything is automated and setting up a test automation framework is expensive

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

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 correct. Behavior-Driven Development (BDD) is a well-known example of a test-first approach to development
b) Is not correct. Test Level Driven Development is not a correct example of a test-first approach to development
c) Is not correct. Function-Driven Development is not a correct example of a test-first approach to development
d) Is not correct. Performance-Driven Development is not a correct example of a test-first approach to development

Explanation / Rationale

a) Is not correct. This is an example of a risk monitoring activity, not risk analysis
b) Is not correct. This is an example of an architectural decision, not related with testing
c) Is not correct. This is an example of performing a quantitative risk analysis and is not related to thoroughness or scope of testing
d) Is correct. This shows how risk analysis impacts the thoroughness of testing (i.e., the level of detail)

Explanation / Rationale

“test” and “error” transitions cannot occur in one test case.
Neither can both “done” transitions.
This means we need at least three test cases to achieve transition coverage. For example:

TC1: test, done
TC2: run, error, done
TC3: run, pause, resume, pause, done

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

Explanation / Rationale

a) Is correct. Each test level has specific and distinct test objectives as a different form of test object (e.g., single component, complete system) is tested at each test level and overlapping test objectives would lead to unnecessary duplication
b) Is not correct. Test analysis and design for a given test level should start during the corresponding development phase to facilitate early testing (e.g., acceptance test analysis and design should begin during requirements analysis). Test implementation will generally start later, and test execution will start during the test level
c) Is not correct. Test design for a given test level should start during the corresponding development phase to facilitate early testing, however test design (e.g., test case generation) needs to be based on an agreed test basis, not an early draft, otherwise significant test effort may be wasted on creating test cases for a design that later changes
d) Is not correct. Quality control applies to all development activities, meaning that every software development activity has a corresponding test activity. However, the same symmetry does not apply to dynamic and static testing. There are some static testing activities (e.g., static analysis) for which there is no obvious corresponding dynamic testing activity

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. Although it is true that the tester can implement and execute detailed test cases based on the checklist, it does not explain how this would result in increased coverage
b) Is not correct. Checklist items should not be automated. But even if they are, the automated test scripts always execute the tests in the same way, which usually does not result in increased coverage
c) Is not correct. It is true that each checklist item should be tested separately and independently. But this impacts the test execution order and does not impact the achieved coverage, and so does not result in increased coverage
d) Is correct. If the checklists are high-level, some variability in the actual testing is likely to occur, resulting in potentially greater coverage but less repeatability. If two testers follow a checklist of high-level items, each of them may use different test data, test steps, etc. This way, one tester will probably cover some areas not covered by the other tester and this will result in increased coverage

Explanation / Rationale

a) Is correct. This is something that can (and should) be checked before the code is submitted to version control
b) Is not correct. This is something that can be checked after step (2) is performed, because merge conflict reporting can be done after the code is submitted and merged
c) Is not correct. This fits better as the entry criterion for step (3)
d) Is not correct. This fits better as the exit criterion for step (3)

Explanation / Rationale

a) Is not correct. This is important, but not as important as test environment elements
b) Is correct. The important thing that is missing is the identification of the browser and device used for the testing. The browser and device information are important because such a defect can be browser- or device-specific. For example, a login button may work fine on one browser (or one version of a specific browser) but not on another. Therefore, the browser and device information can help the developers to reproduce the issue and find the root cause of the problem more quickly
c) Is not correct. The test object is identified (WebShop v0.99)
d) Is not correct. The impact is included – this is severity (high)

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. Confirmation testing to check that the updates have resulted in a correct implementation is necessary, however, it would then be sensible to perform regression testing to ensure that no defects have been introduced or uncovered in unchanged areas of the system
b) Is correct. Confirmation testing will check that the updates have resulted in a correct implementation, and then regression testing will be used to ensure that no defects have been introduced or uncovered in unchanged areas of the system
c) Is not correct. Regression testing should be used to ensure that no defects have been introduced or uncovered in unchanged areas of the system when the update was made, however it is also necessary to perform confirmation testing that will check that the updates have resulted in a correct implementation
d) Is not correct. Confirmation testing will check that the updates have resulted in a correct implementation, and regression testing will be used to ensure that no defects have been introduced or uncovered in unchanged areas of the system. However, when performed (i.e., when an update needs to be tested), confirmation testing precedes regression testing