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 is error guessing
b) Is not correct. This is black-box test technique
c) Is correct. See reasons from incorrect answers
d) Is not correct. This is exploratory testing

Explanation / Rationale

a) Is correct. Exploratory testing is a form of experience-based testing, which benefits from the skills and experience of the tester
b) b) Is not correct. Exploratory testing is useful to complement formal testing techniques
c) Is not correct. In session-based test management, exploratory testing is conducted within a defined time-box, and the tester uses a test charter containing test objectives to guide the testing
d) Is not correct. Exploratory testing can incorporate the use of other black-box, white-box, and experience-based techniques referenced in this syllabus

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

a) Is not correct. Statement testing exercises the executable statements in the code, which might result in the absence of certain greetings not being tested
b) Is not correct. Unless the test charter specifically mentioned testing both the presence and the absence of each type of greeting, coverage can be difficult to assess for an exploratory test
c) Is not correct. State transition testing is useful for situations where the test object responds differently to an input depending on current conditions or previous history, but in this case the test object must decide whether the current date matches a particular milestone and thus whether to display the relevant greeting
d) Is correct. Decision testing involves test cases that follow the control flows that occur from a decision point, which in this case would be deciding whether a greeting should or should not be given

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 correct. The facilitator or moderator runs the review meetings
b) Is not correct. This is not a role name for a formal review participant
c) Is not correct. The facilitator or moderator runs the review meetings
d) Is not correct. The facilitator or moderator runs the review meetings

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. While the given statement is true, the explanation is not. The relationship between statement and decision coverage is misrepresented
b) Is correct. Since any test case will cause the outcome of the “if” statement to be either TRUE or FALSE, by definition we achieved 50% decision coverage
c) Is not correct. A single test case can give more than 25% decision coverage, this means according to the statement above always 50 % decision coverage
d) Is not correct. The statement is specific and always true, because each test case achieves 50 % decision coverage

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

a) Is not correct. The benefits are not when creating regressions tests, more in executing them
b) Is not correct. This is done by configuration management tools
c) Is not correct. This needs specialized tools
d) Is correct. Reduction in repetitive manual work (e.g., running regression tests, environment set up/tear down tasks, re-entering the same test data, and checking against coding standards), thus saving time

Explanation / Rationale

a) Is not correct. Regression testing does not check successful implementation of corrections and confirmation testing does not check for side effects
b) Is not correct. The statement about confirmation testing should be about regression testing
c) Is correct. See reasons from incorrect answers
d) Is not correct. Testing new functionality is not 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 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 not correct. This is the Glossary definition of condition coverage
b) Is not correct. Decision coverage is a higher level of coverage and the two terms are not defined as synonyms in the Glossary
c) Is not correct. This is the Glossary definition of statement coverage
d) Is correct. This is the Glossary definition of coverage as applied to decisions

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

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

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

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 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 correct pairings of test activities and test tools are:

1. Performance measurement and dynamic analysis – (b) Dynamic analysis tools
2. Test execution and logging – (a) Code coverage tools
3. Management of testing and testware – (d) Defect management tools
4. Test design – (c) Test data preparation tools

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

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. This is a white-box test technique
b) Is not correct. This is a white-box test technique
c) Is not correct. This is an experience-based test technique
d) Is correct. Black-box test techniques are based on an analysis of the appropriate test basis (e.g., formal requirements documents, specifications, use cases, user stories)

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

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. 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. 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. A crash is clearly noticeable by the user
b) Is not correct. This is a defect, not a failure since there is something wrong in the code. It may not result in a visible or noticeable failure, for example if the changes in the source code file are only in comments
c) Is not correct. The use of wrong input variables may not result in a visible or noticeable failure, for example if nobody uses this particular algorithm; or if the wrong input variable has a similar value to the correct input variable; or if the FALSE result of the algorithm is not used
d) Is not correct. This type of fault will not necessarily lead to a failure; for example, if no one uses this special algorithm

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

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

The following valid equivalence partitions can be identified:

1. Up to 1000 - Couch Potato!
2. Above 1000, up to 2000 - Lazy Bones!
3. Above 2000, up to 4000 - Getting There!
4. Above 4000, up to 6000 - Not Bad!
5. Above 6000 - Way to Go!

The sets of test inputs therefore cover the following partitions:
a) Is not correct. 0 (1), 1000 (1), 2000 (2), 3000 (3), 4000 (3) – 3 partitions (out of 5)
b) Is not correct. 1000 (1), 2001 (3), 4000 (3), 4001 (4), 6000 (4) – 3 partitions (out of 5)
c) Is not correct. 123 (1), 2345 (3), 3456 (3), 4567 (4), 5678 (4) – 3 partitions (out of 5)
d) Is correct. 666 (1), 999 (1), 2222 (3), 5555 (4), 6666 (5) – 4 partitions (out of 5)

Explanation / Rationale

a) Is not correct. Static testing does not involve execution of the test object
b) Is not correct. Some static tests involve the use of a tool, especially static analysis, but reviews (such as the activity described here) do not necessarily involve the use of a tool
c) Is not correct. The review activity described here is part of a static test, but defects found in static tests are usually cheaper than those found in dynamic testing
d) Is correct. Static testing does not involve execution of the test object

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

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