Explanation / Rationale

a) Is not correct. Informal review does not use a formal process
b) Is not correct. Use of checklists are optional
c) Is correct. Inspection is a formal process based on rules and checklists
d) Is not correct. Does not explicitly require a formal process and the use of checklists is optional

Explanation / Rationale

a) Is correct. If the expected security features are not supported by the system architecture, then the system could be seriously flawed. As the system being produced is the problem here, it is a product risk
b) Is not correct. If the developers run over budget, or run out of time, that is a problem with the running of the project – it is a project risk
c) Is not correct. If the test cases do not provide full coverage of the requirements, this means the testing may not fulfil the requirements of the test plan – it is a project risk
d) Is not correct. If the test environment is not ready, this means the testing may not be done, or it may have to be done on a different environment and it is impacting how the project is run – it is a project risk

Explanation / Rationale

a) Is not correct. This activity is performed during the test design activity (test design)
b) Is not correct. This activity is performed during the test implementation activity (test implementation)
c) Is not correct. This activity is performed during the test completion activity (test completion)
d) Is correct. This activity is performed during the test analysis activity (test analysis)

Explanation / Rationale

Performance testing is a test type, not a test level. Component testing focuses on defects in separately testable modules or objects, integration testing on defects in interfaces and interactions, system testing on defects in the whole test object, and acceptance testing is not typically focused on identifying defects.

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

Explanation / Rationale

a) Is not correct. While scope is a topic addressed in a test plan, the implementation of a risk-based testing strategy on this project is the approach, so this topic should be addressed in that section
b) Is correct. Approach is a topic addressed in a test plan and the implementation of a risk-based testing strategy on this project is the approach
c) Is not correct. While metrics for test monitoring and control is a topic addressed in a test plan, the implementation of a risk-based testing strategy on this project is the approach, so this topic should be addressed in that section
d) Is not correct. Configuration management is not a topic addressed in a test plan

Explanation / Rationale

a) Is not correct. System testing does not test interfaces between components and interactions between different parts of the system; this is a target of integration tests
b) Is correct. Examples of work products that can be used as a test basis for component testing include detailed design, code, data model, component specifications. Examples of work products for system testing include system and software requirement specifications (functional and non-functional) use cases
c) Is not correct. Component testing does not ONLY focus on functional characteristics
d) Is not correct. Component tests are also executed by developers, whereas system testing typically is the responsibility of (independent) testers

Explanation / Rationale

a) Is not correct. It is described that the software architect must have completed the system specification
b) Is not correct. ‘Checklist-based’, last sentence it is documented that you should also look for defects outside the checklist
c) Is not correct. It is described: every reviewer did his review done comment
d) Is correct. It is described that a checklist is available, but who provides the checklist?

Explanation / Rationale

Each transition must be traversed at least once. To do so, the first test can cover the happy path, a successful purchase, the next test cancels, or timeout from waiting for pumping, the next test cancels, or timeout from waiting for fuel type, and the last test the insertion of an invalid credit card. While the order is immaterial, fewer than four tests fail to cover one of the transitions inbound to waiting for customer or violates the rules about where a test starts or ends. More than four tests include tests that re-traverse already-covered transitions.

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

Explanation / Rationale

a) Is correct
b) Is not correct. The evaluation of the test automation skills and training, mentoring and coaching needs of the testers who will use the tool should have been performed as part of the tool selection activity
c) Is not correct. The decision on whether the tool provides the required functionality and does not duplicate existing tools should have been performed as part of the tool selection activity
d) Is not correct. The evaluation of the tool vendor in terms of the training and other support they provide should have been performed as part of the tool selection activity

Explanation / Rationale

a) Is not correct. Based on definition of equivalence partition
b) Is correct. Based on definition from Glossary
c) Is not correct. Based on Glossary definition of testware
d) Is not correct. Based on definition of test oracle

Explanation / Rationale

The possible mappings of points 1 to 4 can be justified as follows:

1. Approach 3 is analytical: Risk-based testing is an example of an analytical approach, where tests are designed and prioritized based on the level of risk
2. Approach 2 is standard-compliant: The control algorithms is checked against industry-specific standard of the energy saving regulation.
3. Approach 4 is consultative: This type of test strategy is driven primarily by the advice, guidance, or instructions of stakeholders, business domain experts, or technology experts, who may be outside the test team or outside the organization itself
4. Approach 1 is reactive: Exploratory testing is a common technique employed in reactive strategies, whereby the explorative testing is assigned to the experience-based testing category

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

Explanation / Rationale

a) Is not correct. Analyzing a defect is part of debugging, not testing
b) Is correct. Creating test data is a test implementation task
c) Is not correct. While a tester may need to identify a test item’s version for results reporting purposes, assigning a test item’s version is part of configuration management
d) Is not correct. Writing a user story is not a testing activity and should be done by the product owner

Explanation / Rationale

a) Is correct. This information has been defined earlier in the test project
b) Is not correct. This information is included in a test report: information on what occurred during a test period
c) Is not correct. This information is included in a test report:

• Status of testing and product quality with respect to the exit criteria or definition of done
• Metrics of defects, test cases, test coverage, activity progress, and resource consumption

d) Is not correct. This information is included in a test report: Information and metrics to support recommendations and decisions about future actions, such as an assessment of defects remaining, the economic benefit of continued testing, outstanding risks, and the level of confidence in the tested software

Explanation / Rationale

a) Is correct. See reasons from incorrect answers
b) Is not correct. The “degree of tester’s independence” does not play a role in exit criteria
c) Is not correct. “Availability of test environment” is an entry criterion
d) Is not correct. “The Qualification of Tester” is not a typical exit criterion

Explanation / Rationale

a) Is correct. Test management tools support the activities associated with test manager including metrics
b) Is not correct. Static code analysis metrics would have to do with the code only, not testing as a whole
c) Is not correct. These tools report on test basis coverage and code coverage only, not testing as a whole
d) Is not correct. Model-Based testing tools focus on one specific area, not testing as a whole

Explanation / Rationale

The correct pairing of test activities and tasks is:

A. Test design – (2) Identifying test data to support the test cases
B. Test implementation – (3) Prioritizing test procedures and creating test data
C. Test execution – (4) Analyzing discrepancies to determine their cause
D. Test completion – (1) Entering change requests for open defect reports

Thus:
a) Is correct
b) Is not correct
c) Is not correct
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. The accepting of invalid inputs is the 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

a) Is not correct. The lack of familiarity of the requirements author with the fitness domain is a root cause
b) Is not correct. The lack of training of the tester in state transition testing was one of the root causes of the defect (the developer presumably created the defect, as well)
c) Is correct. The incorrect configuration data represents faulty software in the fitness tracker (a defect), that may cause failures
d) Is not correct. The lack of experience in designing user interfaces for wearable devices is a typical example of a root cause of a defect

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
c) Is correct. The list of user interface best practices is the list of test conditions
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

Considering the potential inconsistencies:

• 6-10 – If librarians should get system responses within 5 seconds, it is NOT inconsistent for borrowers to get system responses within 3 seconds.
• 6-15 - If librarians should get system responses within 5 seconds, it is inconsistent for all users to get system responses within 3 seconds.
• 7-12 – If borrowers can borrow a maximum of 3 books at one time it is NOT inconsistent for them to also reserve books (if they are on-loan).
• 9-11 – If a borrower can be fined for failing to return a book within 3 weeks it is inconsistent for them to also be allowed to borrow a book at no cost for a maximum of 4 weeks – as the length of valid loans are different.

Of the potential inconsistencies, 6-15 and 9-11 are valid inconsistencies.

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

Explanation / Rationale

a) Is not correct. If inadequate developer testing were the problem, the confirmation test would not pass in step 3
b) Is not correct. The same tester who successfully performed the confirmation test in step 3 is repeating it in step 5
c) Is correct. Configuration management maintains the integrity of the software. If a test that passes in step 3 fails in step 5, then something is different between those two steps. One possible difference is the test object, the option listed here. Another possible difference is the between the development environment and the test environment, but that is not an option listed here
d) Is not correct. If the developers were not fixing the defect, the confirmation test would not pass in step 3

Explanation / Rationale

a) Is not correct. While enabling required tests to be identified in an early stage is a testing contribution to success, there is no indication in the question that the tester did so
b) Is not correct. Ensuring processes are carried out properly is part of quality assurance, not a testing contribution to success
c) Is correct. Reducing the risk of fundamental design defects is a testing contribution to success. Database structure is related to design, and performance problems can be a significant product risk
d) Is not correct. While reducing the risk of untestable functionality is a testing contribution to success, the tester here has not identified something untestable, but rather something that would result in performance tests failing

Explanation / Rationale

a) Is correct. Percentage of test cases prepared is a common metric during test preparation while percentage of test cases passed, failed, not run, etc., are common during test execution
b) Is not correct. Defect reports are typically filed during test execution, based on failures found
c) Is not correct. Test environment preparation is part implementation and would generally be complete before test execution
d) Is not correct. Defects are typically reported during test execution, based on failures found, so the cost to find the next defect is available during test execution only

Explanation / Rationale

The correct pairing of descriptions with the different categories of test techniques is:

• Black-box test techniques
Deviations from the requirements are checked (4) User stories are used as the test basis (5)
• White-box test techniques
Coverage is measured based on a selected structure of the test object (1) The processing within the test object is checked (2)
• Experience-based test techniques
Tests are based on defects’ likelihood and their distribution (3)

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

Explanation / Rationale

a) Is correct. Test case execution (e.g., number of test cases run/not run, and test cases passed/failed)
b) Is not correct. This metric can be measured, but its value is low. The number of testers does not give any information about the quality of the test object or test progress
c) Is not correct. the coverage of requirements by source code is not measured during test execution. At most, the TEST(!) coverage of the code or requirements is measured
d) Is not correct. This metric is part of test preparation and not test execution

Explanation / Rationale

Considering the attributes:

• There is a role of a scribe – specified for walkthroughs, technical reviews, and inspections; thus, the reviews being performed cannot be informal reviews
• The purpose is to detect potential defects – the purpose of detecting potential defects is specified for all types of review.
• The review meeting is led by the author – this is not allowed for inspections and is typically not the author for technical reviews, but is part of walkthroughs, and allowed for informal reviews
• Reviewers find potential issues by individual review - all types of reviews can include individual review (even informal reviews)
• A review report is produced - all types of reviews can produce a review report, although it would be less likely for an informal review

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

Explanation / Rationale

The test cases should be scheduled in priority order, but the schedule must also take account of the dependencies.

The two highest priority test cases (TC1 and TC3) are both dependent on TC4, so the first three test cases should be scheduled as either TC4 – TC1 – TC3 or TC4 – TC3 – TC1 (we have no way to discriminate between TC1 and TC3).
Next, we need to consider the remaining medium priority test case, TC6. TC6 is dependent on TC5, but TC5 is dependent on TC2, so the next two three cases must be scheduled as
TC2 – TC5 – TC6.
This means there are two possible optimal schedules:

• TC4 – TC1 – TC3 – TC2 – TC5 – TC6 or
• TC4 – TC3 – TC1 – TC2 – TC5 – TC6

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

Explanation / Rationale

a) Is correct. This explains that each use case specifies some behavior that a subject can perform in collaboration with one or more actors. It also (later) explains that tests are designed to exercise the defined behaviors (basic, exceptional and errors)
b) Is not correct. Use cases normally specify requirements, and so do not ‘include’ the components that will implement them
c) Is not correct. Tests based on use cases do exercise interactions between the actor and the system, but they are focused on the functionality and do not consider the ease of use of user interfaces
d) Is not correct. Tests do cover the use case paths through the use case, but there is no concept of decision coverage of these paths, and certainly not of business process flows

Explanation / Rationale

a) Is not correct. Both developers and testers gain from experience
b) Is correct. Developers are often more interested in designing and building solutions than in contemplating what might be wrong with those solutions
c) Is not correct. Both developers and testers should be able to communicate well
d) Is not correct. Testers shall focus on the quality, not on the quantity

Explanation / Rationale

Proposed test case covers all five possible single valid transitions in the given state diagram (S1->S2, S2->S1, S2->S3, S3->S2, and S3->S1).

Thus:
a) Is not correct. Because no invalid transitions are covered
b) Is correct. Because all valid transitions are covered
c) Is not correct. Because all valid transitions are covered
d) Is not correct. Because the test cases do not have pairs of transitions specified

Explanation / Rationale

Traceability assists with:

• Selecting regression tests in terms of analyzing the impact of changes (1D)
• Evaluating completeness of test execution which makes testing auditable (2B)
• Identifying which user stories have open defect reports which improves understandability of test status reports to include status of test basis items (3A)
• Evaluating whether the number of tests for each requirement is consistent with the level of product risk which provides information to assess test process quality (i.e., alignment of test effort with risk) (4C)

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

Explanation / Rationale

a) Is not correct. Statement coverage measures the percentage of statements exercised by test cases
b) Is correct. Statement testing exercises the executable statements in the code. Statement coverage is measured as the number of statements executed by the tests divided by the total number of executable statements in the test object, normally expressed as a percentage
c) Is not correct. The coverage does not measure pass/fail
d) Is not correct. It is a metric and does not provide true/false statements

Explanation / Rationale

a) Is not correct. Statement coverage is a measure of the proportion of executable statements exercised by tests. The number of executable statements is often close to the number of lines of code minus the comments, but this option only talks about the number of lines of code exercised and not the proportion exercised
b) Is correct. Statement coverage is a measure of the proportion of executable statements exercised by tests (normally presented as a percentage)
c) Is not correct. Statement coverage is a measure of the percentage of executable statements exercised by tests, however many of the lines of source code are not executable (e.g., comments)
d) Is not correct. Statement coverage is a measure of the proportion of executable statements exercised by tests. This option only talks about the number of executable statements exercised and not the proportion (or percentage) exercised

Explanation / Rationale

a) Is not correct. If there was no agreement on targets, it is impossible to reach the targets. Since this situation can´t occur, this is not a scenario happening in reality
b) Is not correct. The test case is objectively wrong, since under these conditions no bonus is paid because the agreed target was not reached
c) Is not correct. There was no agreement on targets, it is impossible to reach the targets. Since this situation can´t occur, this is not a scenario happening in reality
d) Is correct. The test case describes the situation that the too short period of employment and the non-fulfilment of the agreed target leads to non-payment of the bonus. This situation can occur in practice but is missing in the decision table

Explanation / Rationale

The following valid input equivalence partitions can be identified:

• Hours

1. Below 3 hours
2. 3 to 6 hours
3. Above 6 hours

• Intensity

4. Very low
5. Low
6. Medium
7. High

The given test cases cover the following valid input equivalence partitions:

Thus, the missing valid input equivalence partitions are: (2), (5) and (7). These can be covered by two test cases, as (2) can be combined with either (5) or (7).
Thus:
a) Is not correct
b) Is correct
c) Is not correct
d) Is not correct

Explanation / Rationale

a) Is not correct. The test described is a non-functional test, it is a portability test, not a performance test
b) Is not correct. Processor test is not a defined test type
c) Is not correct. The test described is a non-functional test, specifically a portability test
d) Is correct. Testing supported devices is a non-functional test, specifically a portability test

Explanation / Rationale

Product risks exist when a work product may fail to satisfy legitimate needs, while project risks are situations that could have a negative impact on the project’s ability to achieve its objectives. So:

A. Incorrect totals on screens = product risk
B. Change to acceptance criteria during acceptance testing = project risk
C. Users find the soft keyboard too hard to use with your app = product risk
D. System responds too slowly to user input during search string entry = product risk
E. Testers not allowed to report test results in daily standup meetings = project risk

Thus:
a) Is not correct. This list is entirely backwards
b) Is correct
c) Is not correct. While E is about product quality and product risks, the failure to communicate test results is a project risk per the syllabus
d) Is not correct. Product risks can be functional and non-functional, so d is also a product risk

Explanation / Rationale

a) Is not correct. While this test does match the description of an integration test, it is a non-functional test
b) Is correct. This test matches the description of an integration test and it is a non-functional test
c) Is not correct. This test does not match the description of a component test and it is not a functional test
d) Is not correct. While this test is a non-functional test, it does not match the description of a component test

Explanation / Rationale

a) Is not correct. Structure-based, or white-box techniques are based on an analysis of the architecture, detailed design, internal structure, or the code of the test object
b) Is correct. Behavior-based, or black-box techniques are based on an analysis of the appropriate test basis (e.g., formal requirements documents, specifications, use cases, user stories, or business processes), which describe functional and non-functional behavior
c) Is not correct. Experience-based techniques leverage the experience of developers, testers, and users to determine what should be tested
d) Is not correct. Error guessing is a type of experience-based testing, which is not black-box

Explanation / Rationale

Considering the scenario:

1. ‘testing is based on interface specifications’ – the test basis for integration testing includes interface specifications (along with communication protocol specification), while these are not included for any of the other test levels
2. ‘testing is focused on finding failures in communication’ - failures in the communication between tested components is included as a typical failure for integration testing, but failures in communication is not included for any of the other test levels
3. ‘the test approach uses both functional and structural test types’ - functional and structural test types are both included as possible approaches for integration testing, and would also be appropriate for any of the other test levels, although they are only otherwise explicitly mentioned in the syllabus for system testing

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