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

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

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 deviation from standards is a typical, we are not given any standard with which the user stories should comply
b) Is correct. Contradiction is a typical requirements defect. AC3 and AC5 conflict if the Rod is touched to an object that extends more than 1 meter in any direction from the point at which touched, since AC1 does not limit the size of the objects to be touched
c) Is not correct. While security vulnerabilities are typical defects, there is nothing here related to security
d) Is not correct. While test coverage gaps are typical defects, including missing tests for acceptance criteria, we are not provided with any information about which tests do and do not exist

Explanation / Rationale

a) Is correct. Defects found early are often much cheaper to remove than defects detected later in the lifecycle
b) Is not correct. Dynamic testing still has its challenging because they find other types of defects
c) Is not correct. This is dynamic testing
d) Is not correct. Static testing is important for safety-critical computer systems

Explanation / Rationale

a) Is not correct. This is the Glossary definition of quality assurance
b) Is correct. This is the Glossary definition of quality
c) Is not correct. This is the Glossary definition of security
d) Is not correct. This is the Glossary definition of cost of quality

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 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 not correct. This is an objective for a pilot, but you have achieved it because you understand the tool much better due to the pilot
b) Is not correct. This is an objective for a pilot, but you have achieved it because you have tailoring your testing processes
c) Is not correct. This is an objective for a pilot, but you have achieved it because you have standardized an approach to using the tool and its associated work products
d) Is correct. Assessing the benefits and configuring the metrics collection are the two objectives missing from this list

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. While this information is useful for developers, it does not provide managers with a sense of the impact on product quality
b) Is not correct. This summary does not provide developers or managers with the necessary information and attacks the developers
c) Is not correct. This summary does not provide developers or managers with the necessary information and attacks the developers
d) Is correct. This summary gives a good sense of the failure and its impact

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

The complete decision table is shown below:

To achieve full coverage, test cases covering rules 2 and 3 are needed. DT4 satisfies the constraints of rule 2, while DT2 satisfies the constraints of rule 3.

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

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

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

Explanation / Rationale

The change in behavior may be either functional or non-functional you need to run change-related tests, some of which are confirmation tests and others are regression tests.

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

Explanation / Rationale

a) Is not correct. Risk is determined by considering a combination of the likelihood of problem situations and the harm that may result from them but cannot be calculated by adding these together (the probability would be in the range 0 to 1 and the harm could be in dollars)
b) Is not correct. Risk is determined by considering a combination of a likelihood and an impact. This definition only considers likelihood and chance (both forms of probability) with no consideration of the impact (or harm)
c) Is correct. See reasons from incorrect answers
d) Is not correct. Risk is determined by considering a combination of a likelihood and an impact. This definition only considers hazards and losses (a hazard is a bad event, like a risk, while loss is a form of impact) with no consideration of the likelihood (or probability)

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 following partitions can be identified:

1. <= 50, boundary value 50
2. 51 – 55 boundary values 51, 55
3. 56 – 60 boundary values 56, 60
4. >=61 boundary value 61

Boundary value according to glossary V.3.2: A minimum or maximum value of an ordered equivalence partition.

Thus:
a) Is not correct. Does not include all necessary boundary values, but it includes additional values: 0, 49, and 59, which are not boundary values in this equivalence partition
b) Is not correct. Does not include all necessary boundary values. 51 and 55 are missing
c) Is not correct. Does not include necessary boundary values but it includes additional values: 49, 62, and 54, which are not boundary values in this equivalence partition
d) Is correct. includes all necessary boundary values

Explanation / Rationale

a) Is not correct. Contradiction to principle 3: “Early testing saves time and money”
b) Is correct. This is one objective of testing
c) Is not correct. Principle #2 states that exhaustive testing is impossible, so one can never prove that all defects were identified
d) Is not correct. To make an assessment whether a defect will cause a failure or not, one must detect the defect first. Saying that no remaining defect will cause a failure implicitly means that all defects were found. This again contradicts principle #2

Explanation / Rationale

a) Is not correct. Traceability will allow existing test cases to be linked with updated and deleted requirements (although there is no support for new requirements), but it will not help with the automation of maintenance testing
b) Is correct. If all test cases are linked with requirements, then whenever a new test case (with traceability) is added, it is possible to see if any previously uncovered requirements are covered by the new test case
c) Is not correct. Traceability between the test basis and test artifacts will not provide information on which testers found high-severity defects, and, even if this information could be determined, it would be of limited value
d) Is not correct. Traceability can help with identifying test cases affected by changes, however areas impacted by side-effects would be the focus of regression testing

Explanation / Rationale

a) Is not correct. The test result is given in the short summary
b) Is correct. When testing different versions of software, identifying information is necessary
c) Is not correct. You are just writing the defect report; hence, the status is automatically open
d) Is not correct. This information is useful for the tester but does not need to be included in the defect report

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

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

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. Although the description of regression testing is largely correct, the description of confirmation testing (which should be testing a defect has been fixed) is not correct
b) Is correct. The descriptions of both confirmation and regression testing match the intent of those in the syllabus
c) Is not correct. Although the description of regression testing is largely correct, the description of confirmation testing (re-running all previously run tests to get the same results) is not correct, as the purpose of confirmation testing is to check that tests that previously failed now pass (the fix worked)
d) Is not correct. Although the description of confirmation testing is largely correct, the description of regression testing (re-running tests that previously failed) is not correct (this is a more detailed description of confirmation testing)

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. ‘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 correct. This is maintainability testing, not maintenance testing
b) Is not correct. This is a trigger for maintenance testing: Operational tests of the new environment as well as of the changed software
c) Is not correct. This is the trigger for maintenance testing: testing restore/retrieve procedures after archiving for long retention periods
d) Is not correct. This is the trigger for maintenance testing: Reactive modification of a delivered software product to correct emergency defects that have caused actual failures

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

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

The level of risk will be determined by the likelihood of an adverse event happening and the impact (the harm) from that event.

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

Explanation / Rationale

This question is looking for bad application of product risk analysis.

a) Is not correct. As we are told security flaws have a particularly high impact, their risk level will be higher, and thus we have prioritized the security testing ahead of some other testing. Thus, product risk analysis has influenced the testing properly.
b) Is correct. As less defects than expected have been found in the network module, the perceived risk in this area should be lower, and so less testing should be focused on this area, NOT additional testing. Thus, product risk analysis has NOT CORRECTLY influenced the testing in this situation
c) Is not correct. Because the users had problems with the user interface of the previous system, there is now high awareness of the risk associated with the user interface, which has resulted in additional usability testing being planned. Thus, product risk analysis has properly influenced the thoroughness and scope of testing
d) Is not correct. As the time needed to load web pages has been identified as crucial to the success of the new website, the performance of the website should be considered a risk, and the employment of an expert in performance testing helps to mitigate this risk. Thus, product risk analysis has properly influenced the testing

Explanation / Rationale

a) Is correct. For a loop construct, statement coverage only requires that all statements within the loop are executed, but decision coverage requires testing of both the conditions where the loop is executed and when it is bypassed
b) Is not correct. For a loop construct, statement coverage only requires that all statements within the loop are executed, but decision coverage requires testing of both the conditions where the loop is executed and when it is bypassed
c) Is not correct. Checklists are based on experience, defect and failure data, knowledge about what is important for the user, and an understanding of why and how software fails, none of which is likely to have led to the inclusion of such a test condition
d) Is not correct. While it is possible that someone might anticipate a developer making the mistaken assumption that there would always be at least one transaction in a month for every account, only decision testing guarantees testing of that condition