Explanation / Rationale

a) Is correct. System testing examines the behavior and capabilities of the complete system and covers non-functional testing of quality characteristics, which includes security testing. This type of testing is often performed by an independent test team based on system specifications
b) Is not correct. System integration testing examines the interfaces with other systems and external services
c) Is not correct. Beta testing is a type of acceptance testing performed at an external site by roles outside the development organization
d) Is not correct. Component integration testing involves testing the (interfaces and) interactions between components of a system, such as the user interface and database

Explanation / Rationale

a) Is correct. Test-Driven Development (TDD) is a well-known example of a test-first approach to development
b) Is not correct. Coverage-Driven Development is not a correct example of a test-first approach to development
c) Is not correct. Quality-Driven Development is not a correct example of a test-first approach to development
d) Is not correct. Feature-Driven Development is not an example of a test-first approach to development, but is, instead, an agile software development methodology based around delivering features (as opposed to user stories in Scrum)

Explanation / Rationale

a) Is correct. A fundamental strength that all white-box test techniques share is that the entire software implementation is taken into account during testing, which facilitates defect detection even when the software specification is vague, outdated or incomplete. This means white-box testing can find defects such as an extra feature added to the code (either accidentally or deliberately) that is not supposed to be there, which black-box testing cannot detect
b) Is not correct. The fact that the coverage can be precisely defined is not the right reason. The achieved level of coverage would have much more impact than the possibility to measure the coverage
c) Is not correct. If the software does not implement one or more requirements, white-box testing is unlikely to detect the resulting defects of omission
d) Is not correct. While this is true, this is not the right answer, because there is no connection between the capability to be used in both static testing and dynamic testing and the claim that white-box testing facilitates defect detection with poor specifications

Explanation / Rationale

The testware under consideration is a test charter

Test charters are the output from test design
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. 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. Product quality metrics measure quality characteristics. Mean time to failure measures maturity, so it is a product quality metric
b) Is not correct. This is an example of a defect metric, not a product quality metric
c) Is not correct. This is an example of a coverage metric, not a product quality metric
d) Is not correct. This is an example of a defect metric, not a product quality metric

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

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

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. 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. 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. Test environment readiness is a resource availability criterion; hence it belongs to the entry criteria
b) Is not correct. This is a resource availability criterion; hence it belongs to the entry criteria
c) Is correct. Estimated defect density is a measure of diligence; hence it belongs to the exit criteria.
d) Is not correct. Requirements translated into a given format result in testable requirements; hence it belongs to the entry criteria
e) Is correct. Automation of regression tests is a completion criterion; hence it belongs to the exit criteria

Explanation / Rationale

a) Is correct. Value “1” covers “length incorrect” and covers “number of different digits incorrect”, however the system would not validate against this partition when hitting the first incorrect partition. Value “1111” covers “length correct” and “number of different digits incorrect. Value “1234” again covers “length correct” and also “number of different digits correct”
b) Is not correct. These three values achieve full coverage of the equivalence partitions, but full coverage can be achieved with two values
c) Is not correct. These two values only cover “number of different digits
d) Is not correct. These two values does not cover “number of different digits incorrect” equivalence partition

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

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

a) Is not correct. The whole-team approach allows any team member with the requisite skills and knowledge to undertake any task, however that does not mean that team members can take on any role at any time. Typically, they only take on roles in which they are competent, and there is no suggestion that every team member can do every role
b) Is not correct. The whole-team approach applies to how a single team (typically in Agile software development) works; it does not cover how multiple teams are supposed to work on larger projects, and it does not suggest that only one ‘whole’ team is needed for a complete project
c) Is not correct. The whole-team approach does not expect every team member to be involved in every important decision. For instance, there is no need for the business representative (i.e. the Product Owner) to be involved in every technical decision that does not affect the business outcome and implementing such an approach would unnecessarily slow down the team’s progress
d) Is correct. By leveraging the diverse skill sets of each team member most effectively, the whole-team approach fosters superior team dynamics, promotes robust communication and collaboration, and generates a team synergy that benefits the entire project

Explanation / Rationale

a) Is not correct. Assuming that testers could check the ease of changing the currency exchange system then it would be done by maintainability testing rather than maintenance testing, so this is not a trigger for maintenance testing
b) Is correct. A system modification (such as a fix or enhancement) is an example of a trigger for maintenance testing. The removal of the refund option of the currency exchange system was a fix that would lead to maintenance testing
c) Is not correct. If the agile team has started developing a user story that adds a new customer loyalty feature to the currency exchange system, then this will result in them testing the new feature, and then they would perform regression testing. No maintenance testing is required in this situation
d) Is not correct. Reconfiguration of the currency exchange system to support both the local language and English currency transactions is not a system modification, a change to the operational environment, or a system retirement, which are the three triggers for maintenance testing

Explanation / Rationale

Using the three-point estimation technique, the final estimate (E) is calculated as:

E = (a + 4*m + b) / 6,

where a is the most optimistic estimate, m is the most likely estimate, and b is the most pessimistic estimate.

Thus:
a) Is correct. In this case, the estimate for executing a single test case is:

E = (1h + 4*3h + 8h) / 6 = 3.5 hours

So, the total time needed for the tester to execute 4 test cases is:

3.5h * 4 = 14 hours

b) Is not correct
c) Is not correct
d) Is not correct

Explanation / Rationale

a) Is not correct. DevOps enhances testing in several ways, such as by providing fast feedback on code quality, automated regression testing that minimizes regression risk, and promoting a shift-left approach with high-quality code submission and component tests. This is largely provided through continuous integration, where the developers submit component (unit) tests with their new code, which must pass for the code to be admitted to the build. Therefore, developers do need to complete component testin
b) Is correct. DevOps enhances testing in several ways, such as by providing fast feedback on code quality, automated regression testing that minimizes regression risk, and promoting a shift-left approach with high-quality code submission and component tests
c) Is not correct. DevOps enhances testing in several ways, such as by providing fast feedback on code quality, automated regression testing that minimizes regression risk, and promoting a shift-left approach with high-quality code submission and component tests. Testers do not attempt to treat developers and operations equally by spending more time on release testing, although a shift-right approach to testing (testing in production) may well be used
d) Is not correct. Automated processes like continuous integration/continuous delivery (CI/CD) in DevOps facilitate stable test environments and reduce the need for manual testing, however, there is a risk of overlooking the importance of manual testing, especially from a user's perspective

Explanation / Rationale

a) Is not correct. Risk management consists of risk analysis and risk control. Neither of these activities supports the reassembly of the files that made up the release, because these activities deal with risks, not with configuration items
b) Is not correct. Test monitoring is concerned with gathering information about testing. This information is used to assess test progress and to measure whether the test exit criteria or the test tasks associated with the exit criteria are satisfied, such as meeting the targets for coverage of product risks, requirements, or other acceptance criteria. Test control uses the information from test monitoring to provide, in the form of control directives, guidance and the necessary corrective actions to achieve the most effective and efficient testing. None of these activities deal with the management of configuration items
c) Is not correct. The whole-team approach builds on the tester’s skill to work effectively in a team context and to contribute positively to the team goals. So, it focuses on team-related issues, not on configuration items
d) Is correct. Configuration management provides a discipline for identifying, controlling, and tracking work products. Configuration management keeps a record of changed configuration items when a new baseline is created. Using configuration management, it is possible to revert to a previous baseline in order to reproduce previous test results

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

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

a) Is not correct. Testing quadrants group test levels and test types separately according to several criteria. They do not represent any combinations of test levels and test types and they are not related to any location within a software development lifecycle. Both test levels and test types are treated separately in the testing quadrants model
b) Is not correct. Testing quadrants group test levels and test types according to several criteria. They do not describe the degree of granularity of individual test types performed at each test level. Such a model, regarding the test levels, is called the test pyramid
c) Is not correct. The statement is wrong, because in general any test type can be performed at any test level
d) Is correct. The testing quadrants group test levels, test types, activities, test techniques and work products in Agile software development. In this model, tests can be business facing or technology facing. Tests can support the team (i.e., guide the development) or critique the product (i.e., measure its behavior against expectations). The combination of these two viewpoints determines the four quadrants

Explanation / Rationale

a) Is not correct. We do not accept the risk; concrete actions are proposed
b) Is not correct. No contingency plans are proposed
c) Is correct. The proposed actions are related to testing, which is a form of risk mitigation
d) Is not correct. Risk is not transferred but mitigated

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

Explanation / Rationale

Considering each of the listed example defects:

i. Two different parts of the design specification disagree due to the complexity of the design – this is an example of a specification defect, which includes inconsistencies, ambiguities, contradictions, omissions, inaccuracies, and duplications, which can most easily be found by static testing
ii. A response time is too long and so makes users lose patience – this is an example of a response time defect, which can only be detected in practice by executing the program and measuring the response time, which can most easily be found by dynamic testing
iii. A path in the code cannot be reached during execution - this is an example of a coding defect, which includes variables with undefined values, undeclared variables, duplicated or unreachable code, and excessive code complexity, which can most easily be found by static testing
iv. A variable is declared but never subsequently used in the program - this is an example of a coding defect, which includes variables with undefined values, undeclared variables, duplicated or unreachable code, and excessive code complexity, which can most easily be found by static testing
v. The amount of memory needed by the program to generate a report is too high – this is an example of a performance defect, which can only be detected in practice by executing the program and measuring the memory used, which can most easily be found by dynamic testing

Thus:
a) Is not correct
b) Is not correct
c) Is not correct
d) Is correct. The correct match for static testing is i, iii, and iv

Explanation / Rationale

a) Is correct. Defect management is no less expensive. Finding and fixing defects later in SDLC is more costly
b) Is not correct. This is a benefit of static testing
c) Is not correct. This is a benefit of static testing
d) Is not correct. This is a benefit of static testing

Explanation / Rationale

We want to run test cases according to their priorities, but we also need to consider the dependencies.
If we only consider priorities, we want to first run TC 5 and TC 7 (highest priority), then TC 1, TC 3, and TC 4, and finally TC 2 and TC 6 (lowest priority).
However, in order to run TC 7, we need to first run TC 4.
In order to run TC 5, we need to run TC 4 and TC 2, but TC 2 is blocked by TC 1, which should be run prior to TC 2.
So, in order to run priority 1 test cases as early as possible, the first five test cases should be: TC 4 - TC 7 - TC 1 - TC 2 - TC 5.
Next, we need to run TC 3, because it has higher priority than TC 6.
Thus the full schedule will be TC 4 – TC 7 – TC 1 – TC 2 – TC 5 – TC 3 – TC 6.
So, the sixth test case will be TC 3.

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

Explanation / Rationale

a) Is not correct. The detection of additional high-severity defects would be a benefit of test automation, rather than a risk
b) Is not correct. The provision of measures that are too complicated for humans to derive themselves is normally considered to be a benefit of test automation
c) Is correct. If the test automation is incompatible with the development platform, then it will not be able to integrate them, and, for instance, pass test inputs to the test object and receive test results from the test object
d) Is not correct. Substantially reduced test execution times would normally be considered a benefit that is provided by test automation

Explanation / Rationale

a) Is not correct. Risk impact and risk likelihood are independent
b) Is not correct. Risk impact and risk likelihood are independent
c) Is correct. Risk impact and risk likelihood are independent
d) Is not correct. We need both factors to calculate risk level

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

Risk assessment can use a quantitative or qualitative approach, or a mix of them. In the quantitative approach the risk level is calculated as the multiplication of risk likelihood and risk impact. So, Risk level = Risk likelihood * Risk impact
Then, Risk impact = Risk level / Risk likelihood.
In our case, Risk impact = $1,000 / 50% = $1,000 / 0.5 = $2,000.
Thus:
a) Is not correct
b) Is correct
c) Is not correct
d) Is not correct

Explanation / Rationale

a) Is not correct. Coverage is always defined as the percentage of the covered elements. Therefore, it cannot exceed 100%
b) Is correct. If the statements executed by T1 and T2 were disjoint, the coverage of the test suite {T1, T2} would be 105%, which is impossible (see answer a). Therefore, at least 5% of executable statements must have been executed by both T1 and T2
c) Is not correct. Statement coverage does not tell us anything about the number of non-executable statements in the code
d) Is not correct. Even if a test suite achieves full statement coverage, this does not imply achieving full branch coverage