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

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. The management decides about performing the review
b) Is not correct. The moderator, not the review leader should ensure the effective running of review meetings
c) Is not correct. The author fixes the work product under review
d) Is not correct. The manager monitors ongoing cost-effectiveness

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. 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. Exploratory testing is not suitable to speed up tests, which are already specified. It is most useful when there are few or inappropriate specified requirements or significant time pressure on testing
b) Is not correct. The absence of a test charter, which may have been derived from the test analysis, is a poor precondition for the use of exploratory testing
c) Is correct. Exploratory tests should be performed by experienced testers with knowledge of similar applications and technologies
d) Is not correct. Explorative testing alone is not suitable to provide evidence that the test was very intensive, instead the evidence is provided in combination with other test methods

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

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 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. 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 correct. Impact analysis may be used to identify those areas of the system that will be affected by the fix, and so the extent of the impact (e.g., necessary regression testing) can be used when deciding if the change is worthwhile
b) Is not correct. Although testing migrated data is part of maintenance testing (see conversion testing), impact analysis does not identify how this is done
c) Is not correct. Impact analysis shows which parts of a system are affected by a change, so it can show the difference between different hot fixes in terms of the impact on the system, however it does not give any indication of the value of the changes to the user
d) Is not correct. Impact analysis shows which parts of a system are affected by a change; it cannot provide an indication of the effectiveness of test cases

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

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. 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. ‘Beware of the pesticide paradox’ is concerned with re-running the same tests and their fault-finding effectiveness decreasing
b) Is not correct. This testing principle is concerned with performing testing differently based on the context (e.g., games vs safety-critical)
c) Is not correct. This testing principle is concerned with the difference between a tested and fixed system and a validated system. No ‘errors’ does not mean the system is fit for use
d) Is correct. If clusters of defects are identified (areas of the system containing more defects than average), then testing effort should be focused on these areas

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

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

Considering each statement:

1. Each development activity should have a corresponding testing activity. TRUE
2. Reviewing should start as soon as final versions of documents become available. FALSE – it should start as soon as drafts are available
3. The design and implementation of tests should start during the corresponding development activity. FALSE – the analysis and design of tests should start during the corresponding development activity, not the implementation
4. Testing activities should start in the early stages of the software development lifecycle. TRUE

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

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

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

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

Glossary defines the following tests as:

• Test suite: “A set of test scripts or test procedures to be executed in a specific test run.” (1A)
• Test case: “A set of preconditions, inputs, actions (where applicable), expected results and post conditions, developed based on test conditions” (2C)
• Test script: “A sequence of instructions for the execution of a test” (3B)
• Test charter: “Documentation of test activities in session-based exploratory testing” (4D)

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

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

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

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. The metrics-based approach: estimating the testing effort based on metrics of former similar projects or based on typical values
b) Is not correct. This is expert-based approach: estimating the tasks based on estimates made by the owners of the tasks or by experts
c) Is not correct. This is expert-based approach: estimating the tasks based on estimates made by the responsible team of the tasks or by experts
d) Is not correct. This is expert-based approach: estimating the tasks based on estimates made by the owners of the tasks or by experts

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