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. Tester and developer are NOT roles in a formal review
b) Is not correct. Developer is NOT a role in a formal review
c) Is not correct. Designer is NOT a role in a formal review
d) Is correct. See reasons from incorrect answers

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

Explanation / Rationale

a) Is not correct. While recognizing different kinds of failures is a benefit of tester independence, in the scenario here no code yet exists that can fail, and the problem is that the developer and product owner are both assuming different things about the acceptance criteria
b) Is not correct. Developers losing a sense of responsibility for quality is a drawback, not a benefit
c) Is not correct. While the effect of the discovery of this disagreement is the earlier removal of the defect, prior to coding, defects can be discovered early by various people, not just independent testers
d) Is correct. Challenging stakeholder assumptions is a benefit of tester independence, and here the developer and product owner are both assuming different things about the acceptance criteria

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. One too few (see the four correct partitions in the correct answer)
b) Is not correct. One too much (see the four correct partitions in the correct answer)
c) Is not correct. Two too few (see the four correct partitions in the correct answer)
d) Is correct. The 4 equivalence partitions correspond to the description in the question, i.e., at least one test case must be created for each equivalence partition:

1. Equivalence partition: 0 ≤ employment time ≤ 2
2. Equivalence partition: 2 < employment time < 5
3. Equivalence partition: 5 ≤ employment time ≤ 10
4. Equivalence partition: 10 < employment time

Explanation / Rationale

a) Is not correct. Estimates may be updated as more information becomes available, but estimates are needed to assist with planning before the testing starts
b) Is not correct. In the expert-based approach, the experts need to be experts in testing, not in using the test object
c) Is correct. Test Managers, who will be leading testers doing the testing, are considered experts in their respective areas and suitable for estimating the necessary resources needed
d) Is not correct. While it is useful to know the testing costs from previous projects, a more sophisticated approach is needed than simply taking an average of past projects (the new project may not be like the previous projects, e.g., it may be far larger or far smaller than previous projects)

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

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

There are three equivalence partitions, with the boundaries as shown:

• Invalid too low (0.4 and below)
• Valid (0.5 to 25.0)
• Invalid too high (25.1 and above)

Thus:
a) Is not correct. None of those four boundary values are included in this set of tests. These tests do cover the equivalence partitions
b) Is not correct. All these four boundary values are included in this set of tests, but two additional values are included, one for each boundary. These are the values associated with three-point boundary value analysis
c) Is correct. Each of those four two-point boundary values are included in this set of tests
d) Is not correct. These four values are all included in the valid partition

Explanation / Rationale

a) Is correct. One of the major objectives of testing
b) Is not correct. Validation of the project plan would be a project management activity
c) Is not correct. Contradiction to principle #2; complete/exhaustive testing is not possible
d) Is not correct. “Comparing actual results with expected results” is a test performing activity, but not a test objective

Explanation / Rationale

a) Is not correct. A path through source code is one potential route through the code from the entry point to the exit point that could exercise a range of decision outcomes. Two different paths may exercise all but one of the same decision outcomes, and by just changing a single decision outcome a new path is followed. Test cases that would achieve decision coverage are typically a tiny subset of the test cases that would achieve path coverage. In practice, most non-trivial programs (and all programs with unconstrained loops, such as ‘while’ loops) have a potentially infinite number of possible paths through them and so measuring the percentage covered is practically infeasible
b) Is not correct. Coverage of business flows can be a focus of use case testing, but use cases rarely cover a single component. It may be possible to cover the decisions within business flows, but only if they were specified in enough detail, however this option only suggests coverage of “business flows” as a whole. Even if business flows would cover some decisions, the measure “Decision Coverage” don’t measure the percentage of business flows, but the percentage of decision outcomes exercised by the business flows
c) Is not correct. Achieving full decision coverage does require all ‘if’ statements to be exercised with both true and false outcomes, however, there are typically several other decision points in the code (e.g., ‘case’ statements and the code controlling loops) that also need to be taken into consideration when measuring decision coverage
d) Is correct. Decision coverage is a measure of the proportion of decision outcomes exercised (normally presented as a percentage)

Explanation / Rationale

a) Is not correct. This is an example of a mistake made by the developer
b) Is not correct. This is an example of a defect (something wrong in the code that may cause a failure)
c) Is correct. This is a deviation from the expected functionality - a cruise control system should not be affected by the radio
d) Is not correct. This is an example of a defect (something wrong in a specification that may cause a failure if subsequently implemented)

Explanation / Rationale

a) Is not correct. Defect clustering has to do with where defects are most likely to be found, not whether all of them can be found
b) Is correct. Testing can show the presence of defects but cannot prove their absence, which makes it impossible to know if you have caught all the bugs. Further, the impossibility of exhaustive testing makes it impossible for you to catch all the bugs
c) Is not correct. This principle says that you can find and remove many bugs but still release an unsuccessful software product, which is not what the product owner is asking you to ensure
d) Is not correct. Root cause analysis is not a testing principle

Explanation / Rationale

Test 01.001 must come first, followed by 01.002, to satisfy dependencies. Afterwards, 01.004 and 01.003 should be run in either order, followed by 01.005, to satisfy priority.
Thus:
a) Is not correct
b) Is correct
c) Is not correct
d) Is not correct

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. Testing does not identify the source of defects, debugging identifies the source of defects
b) Is correct. Dynamic testing can show failures that are caused by defects in the software. Debugging eliminates the defects, which are the source of failures
c) Is not correct. Testing does not remove faults, but debugging removes faults, which is synonyms for defects, that may cause the failures
d) Is not correct. Dynamic testing does not directly prevent the causes of failures (defects) but detects the presence of defects

Explanation / Rationale

a) Is not correct. See reason from correct answer
b) Is not correct. See reason from correct answer
c) Is correct. This is a case where the requirement gives an enumeration of discrete values. Each enumeration value is an equivalence class by itself; therefore, each will be tested when using equivalence partitioning test technique
d) Is not correct. See reason from correct answer

Explanation / Rationale

a) Is not correct. Static testing (reviews) contributes, but could not ensure, that requirements are detailed enough
b) Is correct. Testing contributes to the achievement of quality in a variety of ways, e.g., such as reducing the risk of inadequate software quality
c) Is not correct. This is quality assurance but not testing
d) Is not correct. The quality cannot be measured by counting the number of executed test cases without knowing the outcome

Explanation / Rationale

a) Is not correct. Technical reviews are appropriate for technical documents such as a system architecture
b) Is correct. Adequate time for preparation is important, but people are working overtime and no adjustments are made for this new set of tasks
c) Is not correct. Gathering metrics from a review to evaluate participants is a factor that leads to failure, not success, because it destroys trust
d) Is not correct. A well-managed review meeting is important, but there is no reason to think the review meeting will not be well managed based on the information provided

Explanation / Rationale

a) Is not correct. Definition of feature according to glossary
b) Is correct. From glossary
c) Is not correct. Definition of functionality suitability according to glossary
d) Is not correct. Like Definition of Decision table testing according to glossary

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

The correct pairings of examples to entry and exit criteria are:

• Entry criteria

o (3) The trading performance test environment has been designed, set-up and verified – example of the need for a test environment to be ready before testing can begin
o (5) The autopilot design specifications have been reviewed and reworked – example of the need for the test basis to be available before testing can begin
o (6) The tax rate calculation component has passed unit testing – example of the need for a test object to have met the exit criteria for a prior level of testing before testing can begin

• Exit criteria

o (1) The original testing budget of $30,000 plus contingency of $7,000 has been spent – example of spending the testing budget being a signal to stop testing
o (2) 96% of planned tests for the drawing package have been executed and the remaining tests are now out of scope – example of all the planned tests being run being a signal to stop testing (normally used alongside the exit criteria on outstanding defects remaining)
o (4) Current status is no outstanding critical defects and two high-priority ones – example of the number of outstanding defects achieving a planned limit being a signal to stop testing (normally used alongside the exit criteria on planned tests being run).

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

a) Is correct. Incremental development involves establishing requirements, designing, building, and testing a system in pieces
b) Is not correct. This is a sequential model
c) Is not correct. This describes the waterfall model
d) Is not correct. Testing alone is not an increment/additional step in the development

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. Exploratory testing is often carried out when timescales are short, so making in-depth investigations of the background of the test object is unlikely
b) Is correct. Glossary definition
c) Is not correct. Based on the Glossary definition of session-based testing, but with test execution replaced by test analysis
d) Is not correct. Glossary definition of experience-based testing

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

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

Considering each of the pieces of information:

1. Degree of impact (severity) of the defect – the developers are already aware of the problem and are waiting to fix it, so this is a less important piece of information.
2. Identification of the test object – as the developers are already aware of the problem and you are performing system testing, and you have already provided the version of the system you are testing you can assume they know the object that was being tested, so this is a less important piece of information.
3. Details of the test environment – the set-up of the test environment may have a noticeable effect on the test results, and detailed information should be provided, so this is an important piece of information.
4. Urgency/priority to fix – the developers are already aware of the problem and are waiting to fix it, so this is a less important piece of information.
5. Actual results – the actual results may well help the developers to determine what is going wrong with the system, so this is an important piece of information.
6. Reference to test case specification – this will show the developers the tests you ran, including the test inputs that caused the system to fail (and expected results), so this is an important piece of information.

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

Explanation / Rationale

a) Is not correct. Selection of tools is a test manager task
b) Is correct. See reasons from incorrect answers
c) Is not correct. The tester does not decide on the release of the test object
d) Is not correct. The tester specifies the test cases, the test manager does the prioritization

Explanation / Rationale

a) Is correct. This is an objective listed
b) Is not correct. This is debugging
c) Is not correct. This is an activity within the test execution group of activities within the test process
d) Is not correct. This is part of debugging

Explanation / Rationale

a) Is correct. One of the typical tasks of a test manager
b) Is not correct. One of the typical tasks of a tester
c) Is not correct. One of the typical tasks of a tester
d) Is not correct. One of the typical tasks of a tester

Explanation / Rationale

a) Is not correct. Testing is context dependent, regardless of it being manual or automated (principle #6), but does not result in detecting a decreasing number of faults as described above
b) Is not correct. Exhaustive testing is impossible, regardless of the amount of effort put into testing (principle #2)
c) Is correct. Principle #5 says “If the same tests are repeated over and over again, eventually these tests no longer find any new defects. To detect new defects, existing tests and test data may need changing, and new tests may need to be written.” Automated regression testing of the same test cases will not bring new findings
d) Is not correct. ”Defect cluster together” (principle #4). A small number of modules usually contain most of the defects, but this does not mean that fewer and fewer defects will be found

Explanation / Rationale

a) Is not correct. ‘Collection of metrics’ belongs to the main activity “Fixing and Reporting”
b) Is not correct. ‘Answer any question.’ belongs to the main activity “Initiate Review”
c) Is correct. The checking of entry criteria takes place in the planning of a formal review
d) Is not correct. The evaluation of the review findings against the exit criteria belongs to the main activity “Issue communication and analysis”

Explanation / Rationale

a) Is not correct. error guessing is not a usability technique for guessing how users may fail to interact with the test object
b) Is not correct. Although a tester who used to be a developer may use their personal experience to help them when performing error guessing, the technique is not based on prior knowledge of development
c) Is correct. The basic concept behind error guessing is that the tester tries to guess what mistakes may have been made by the developer and what defects may be in the test object based on past-experience (and sometimes checklists)
d) Is not correct. Duplicating the development task has several flaws that make it impractical, such as the requirement for the tester to have equivalent skills to the developer and the time involved in performing the development. It is not error guessing

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

Given the annotated state model below:

The options achieve the following transition coverage:
a) Is not correct: OFF (2) WAIT (1) OFF (2) WAIT (3) TRICKLE (5) CHARGE (9) HIGH (10) CHARGE (7) LOW = 7 transitions (out of 10)
b) Is not correct: WAIT (3) TRICKLE (4) WAIT (1) OFF (2) WAIT (3) TRICKLE (5) CHARGE (7) LOW (8) CHARGE = 7 transitions (out of 10)
c) Is not correct: HIGH (10) CHARGE (7) LOW (8) CHARGE (6) TRICKLE (4) WAIT (3) TRICKLE (4) WAIT (3) TRICKLE = 6 transitions (out of 10)
d) Is correct: WAIT (3) TRICKLE (5) CHARGE (9) HIGH (10) CHARGE (6) TRICKLE (4) WAIT (1) OFF (2) WAIT = 8 transitions (out of 10)

Explanation / Rationale

a) Is not correct. Reviews should increase the quality of specifications, however the time required for development and testing should decrease
b) Is not correct. Detecting defects is generally easier earlier in the lifecycle
c) Is not correct. Reviews will result in fewer missed requirements and better communication between testers and developers, however this is not true for static analysis
d) Is correct. This is a benefit of static analysis