Explanation / Rationale

Considering:

• Usability testing is in Q3 (1 – C)
• Component testing is in Q1 (2 – A)
• Functional testing is in Q2 (3 – B)
• Reliability testing is in Q4 (4 – D)

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

Explanation / Rationale

Branch testing is a white-box test technique in which the coverage items are branches. A branch is a transfer of control between two nodes in the control flow graph, which shows the possible sequences in which source code statements are executed in the test object. Each transfer of control can be either unconditional (i.e., straight-line code) or conditional (i.e., a decision outcome). Coverage is measured as the number of branches exercised by the test cases divided by the total number of branches, and is expressed as a percentage.
Thus:
a) Is not correct. A decision outcome is a conditional branch. For branch testing, X counts not only conditional, but also unconditional branches
b) Is not correct. Branch coverage counts not only conditional, but also unconditional branches
c) Is correct. Branch coverage is measured as the number of branches exercised by the test cases divided by the total number of branches, and is expressed as a percentage
d) Is not correct. Both X and Y count only conditional branches and do not take into account the unconditional branches

Explanation / Rationale

a) Is not correct. Most work products can be examined using some form of static testing, and a contract must be interpretable by humans and so could be reviewed, which is a form of static testing
b) Is not correct. Most work products can be examined using some form of static testing, and a test plan must be interpretable by humans and so could be reviewed, which is a form of static testing
c) Is correct. Most work products can be examined using some form of static testing; however it is not suitable for work products that are too complex for human interpretation and should not be analyzed by tools, and encrypted code is too complex for humans and if it is properly encrypted it will not be analyzable by most tools
d) Is not correct. Most work products can be examined using some form of static testing, and a test charter must be interpretable by humans and so could be reviewed, which is a form of static testing

Explanation / Rationale

The ‘exhaustive testing is impossible’ principle is concerned with the fact that it is not feasible to test every possible variation of test inputs in all different circumstances, except in trivial cases. Instead, testing utilizes test techniques, test case prioritization, and risk-based testing to sample from the set of possibilities and focus testing efforts.
a) Is not correct. The principle states that it is not feasible to test everything except in trivial cases. Testing everything would require testing every possible variation of test inputs in all different circumstances, which is generally infeasible as there will be a practically infinite number. Testing every possible specified output will not address this problem as the relationship between inputs and specified outputs can be different for each test object. Sometimes there may be a practically infinite number of possible specified outputs (e.g., when there are several variables representing real numbers), whereas at other times there may be just two specified outputs, such as with a single variable that can be either true or false
b) Is not correct. The principle states that it is not feasible to test every possible variation of test inputs in all different circumstances. This is because for non-trivial systems there is a practically infinite number. Therefore, in practice, documenting all possible test input variations would be impractical as it would take an infinite length of time
c) Is not correct. Starting testing as early as possible with reviews and other static testing approaches will not address the problem of there being too many possible test cases. The ‘early testing saves time and money’ principle is concerned with fixing defects early on to prevent the occurrence of subsequent defects in derived work products, thereby reducing costs and the likelihood of failures
d) Is correct. The use of equivalence partitioning and boundary value analysis to generate test cases is one way to address the principle as these test techniques provide a systematic way to derive a finite subset of all possible test cases

Explanation / Rationale

a) Is not correct. In agile software development, deliverables are produced in each iteration, and the frequent delivery of increments necessitates extensive regression testing. Although some (or all) of this regression testing may be automated, the regression testing (automated or not) cannot be replaced by system test automation
b) Is correct. If a sequential development model is used, then early in the lifecycle no code is available for execution, and so during this time static testing (e.g., reviews) is performed. Later in the lifecycle, when code is available for execution, dynamic testing is possible. Note, however, that preparation for dynamic testing will often occur early in any software development lifecycle
c) Is not correct. If an iterative development model, like agile software development, is used, then component tests may well be used for regression testing for each iteration. In which case, there is a strong argument for automating these component tests, which will have to be run frequently, and there is unlikely to be a strong argument for developers performing these component tests manually
d) Is not correct. In most incremental development models, deliverables are produced in each increment, requiring both static and dynamic testing at all test levels for each increment delivered

Explanation / Rationale

a) Is not correct. Test automation does not introduce unknown regressions in production
b) Is correct. Wrong allocation of effort to maintain testware is a risk
c) Is not correct. Test tools must be selected so that they and their testware can be relied upon
d) Is not correct. The primary goal of test automation is to reduce manual testing. So, this is a benefit, not a risk

Explanation / Rationale

a) Is not correct. Priorities for user stories are determined by the business representative together with the development team
b) Is not correct. Testers focus on both functional and non-functional aspects of the system to be tested
c) Is correct. According to the syllabus, this is one of the ways testers add value to iteration and release planning
d) Is not correct. Early test design is not part of release planning. Early test design does not automatically guarantee the release of quality software

Explanation / Rationale

a) Is not correct. It is more often used in behavior-driven development (BDD)
b) Is not correct. It is the description of test-driven development (TDD)
c) Is correct. In acceptance test-driven development (ATDD) tests are written from acceptance criteria as part of the design process
d) Is not correct. It is used in BDD

Explanation / Rationale

a) Is not correct. To ensure successful reviews, it's important to secure management's support for the review process, however that does not mean that they should participate as reviewers
b) Is correct. To ensure successful reviews, it's important to break the work product into parts that are small enough to be reviewed in a reasonable timescale to prevent reviewers from losing focus during individual review or review meetings
c) Is not correct. To ensure successful reviews, it's important to clearly define objectives and measurable exit criteria, without evaluating participants
d) Is not correct. To ensure successful reviews, it's important to break down the review into smaller chunks to prevent reviewers from losing focus during individual review or review meetings. So you should not plan to cover one document per review

Explanation / Rationale

a) Is correct. This test case is related to acceptance criteria 2 and 3, because we check if we can set price range (acceptance criterion 2) and if the results update dynamically after adjusting the price range filter (acceptance criterion 3)
b) Is not correct. This test case is not related to any of the acceptance criteria. It checks if the filter dynamically sets the default minimum and maximum price range, and not that a customer can do it
c) Is not correct. This test case is not related to any of the acceptance criteria. It checks the currency exchange feature, which is not discussed in this user story
d) Is not correct. This test case is not related to any of the acceptance criteria. It checks the application’s compatibility with different browsers, which is not discussed in this user story

Explanation / Rationale

a) Is not correct. This is a new product. You probably do not have a checklist yet and test conditions might not be known due to missing requirements
b) Is not correct. This is a new product. You probably do not have enough information to make correct error guesses
c) Is correct. Exploratory testing is most useful when there are few known specifications and/or there is a pressing timeline for testing
d) Is not correct. Branch testing is time-consuming, and your management is asking about some test results now. Also, branch testing does not involve domain knowledge

Explanation / Rationale

a) Is not correct. A line with a defect, when executed, does not have to cause a failure. For example, a line x := y / z will cause a failure only when z equals 0
b) Is not correct. 100% statement coverage does not guarantee 100% branch coverage. For example, a test case with x=0 for the code

1. IF (x=0) THEN
2. A;
3. ENDIF

achieves 100% statement coverage but does not cover the branch from 1 to 3
c) Is correct. 100% statement coverage means that each executable statement was executed at least once
d) Is not correct. The removed test case may provide coverage of some statements that are not covered by either of the other two test cases, in which case the remaining two test cases together will not achieve 100% statement coverage

Explanation / Rationale

a) Is not correct. In the whole-team approach, testers play a vital role by sharing their testing expertise with the team and guiding product development. They collaborate with other team members to achieve the desired quality levels and work with business representatives to create acceptance tests. Testers also partner with developers to determine the optimal test strategy and automation approaches
b) Is correct. By leveraging the diverse skill sets of each team member most effectively, the whole-team approach fosters superior team dynamics, promotes robust communication and collaboration, and generates a synergistic effect that benefits the entire project
c) Is not correct. The whole-team approach allows any team member with the requisite skills and knowledge to undertake any task, thus specialist team members are not an advantage of this approach
d) Is not correct. There is no specific guidance on the optimum size of teams using the whole-team approach, and there is no suggestion that larger teams are better

Explanation / Rationale

Risk assessment can use a quantitative or qualitative approach, or a mix of them. In the quantitative approach the risk level is calculated as the multiplication of risk likelihood and risk impact. So, Risk level = Risk likelihood * Risk impact
Then, Risk impact = Risk level / Risk likelihood.
In our case, Risk impact = $1,000 / 50% = $1,000 / 0.5 = $2,000.
Thus:
a) Is not correct
b) Is correct
c) Is not correct
d) Is not correct

Explanation / Rationale

a) Is not correct. A member without a missed deadline can get a discount and a gift T-Shirt after 15 bicycle rentals
b) Is not correct. A member without a missed deadline can get a discount but no gift T-Shirt until they rented a bicycle 15 times
c) Is not correct. Non-members cannot get a discount, even if they did not miss a deadline yet
d) Is correct. No discount as a non-member that has also missed a deadline, but only members can receive a gift T-Shirt. Hence, the action is not correct

Explanation / Rationale

a) Is not correct. The whole-team approach allows any team member with the requisite skills and knowledge to undertake any task, however that does not mean that team members can take on any role at any time. Typically, they only take on roles in which they are competent, and there is no suggestion that every team member can do every role
b) Is not correct. The whole-team approach applies to how a single team (typically in Agile software development) works; it does not cover how multiple teams are supposed to work on larger projects, and it does not suggest that only one ‘whole’ team is needed for a complete project
c) Is not correct. The whole-team approach does not expect every team member to be involved in every important decision. For instance, there is no need for the business representative (i.e. the Product Owner) to be involved in every technical decision that does not affect the business outcome and implementing such an approach would unnecessarily slow down the team’s progress
d) Is correct. By leveraging the diverse skill sets of each team member most effectively, the whole-team approach fosters superior team dynamics, promotes robust communication and collaboration, and generates a team synergy that benefits the entire project

Explanation / Rationale

a) Is not correct. Performing the impact analysis will not give information about completeness of tests. Analyzing the impact analysis of changes will help to select the right test cases for execution
b) Is not correct. Traceability does not give information about the estimated level of residual risk if the test cases are not traced back to risks
c) Is correct. Performing the impact analysis of the changes helps in selecting the test cases for the regression test
d) Is not correct. Analyzing the traceability between the test basis, test objects and test cases does not help in selecting test data to achieve the assumed coverage of the test object. Selecting test data is more related to test analysis and test implementation, not traceability

Explanation / Rationale

a) Is not correct. Tracking test progress and identifying areas that require further attention is an example of supporting the ongoing control of testing. This is one of the purposes of test reports
b) Is not correct. Providing information on the tests executed, their results, and any issues or defects found is an example of summarizing the test activities performed at a given test level. This is one of the purposes of test reports
c) Is correct. Providing information about defects is the purpose of a defect report, not a test report
d) Is not correct. Providing information on testing planned for the next period is one of the purposes of test reports

Explanation / Rationale

a) Is not correct. This sequence of five events covers 4 different valid transitions (both “NotAvailable” events correspond to the same transition between S1 and S3). This test case covers 4 out of 7 valid transitions
b) Is correct. This sequence of five events covers 5 different transitions (the first “Available” event corresponds to a transition between S1 and S2, and the second “Available” event corresponds to a transition between S3 and S2, so two different transitions are covered). This test case covers 5 out of 7 valid transitions and achieves the highest valid transitions coverage
c) Is not correct. This sequence of five events covers 3 different transitions (both “Available” events correspond to the same transition from S1 to S2; both “ChangeRoom” events correspond to the same transition from S2 to S1). This test case covers 3 out of 7 valid transitions
d) Is not correct. This sequence of five events does not represent a feasible test case, because after “Cancel” the system ends up in the End state and no further valid transitions can be executed

Explanation / Rationale

a) Is not correct. The test pyramid model does not provide information about test priorities
b) Is correct. The test pyramid model shows that different tests have different levels of granularity
c) Is not correct. The test pyramid model is independent of coverage criteria
d) Is not correct. Test pyramid model does not show any relations between different tests

Explanation / Rationale

a) Is correct. Defect management is no less expensive. Finding and fixing defects later in SDLC is more costly
b) Is not correct. This is a benefit of static testing
c) Is not correct. This is a benefit of static testing
d) Is not correct. This is a benefit of static testing

Explanation / Rationale

a) Is not correct. Strong communication skills, active listening, and teamwork abilities enable a tester to interact effectively with all stakeholders, however a deep knowledge of a variety of computer games that allowed them to get on well with one developer is not an example of a generic skill useful to testers
b) Is correct. Domain knowledge that can be used to understand and communicate with end-users and business representatives is one of the generic skills required by testers. A tester with experience as a pilot would make them better able to appreciate the acceptance criteria for the helicopter control system
c) Is not correct. Although programming skills could be considered as technical knowledge which can increase efficiency when utilizing some test tools, it is unlikely that these skills would improve their communication with business analysts
d) Is not correct. Although thoroughness, attention to detail, curiosity, and a methodical approach to identifying hard-to-find defects are all useful generic skills for testers, it is doubtful they would be generating test cases prior to starting exploratory testing. This is because one of the main tenets of exploratory testing is that the test cases are generated during the testing, not scripted in advance

Explanation / Rationale

a) Is not correct. A lack of usability provided through the user interface can be detected through a review using a suitable checklist, but the lack of usability can also be identified by getting several typical users to dynamically test the user interface and provide feedback on its usability
b) Is correct. A code review can detect code that cannot be reached by any path, however dynamic tests can only exercise reachable code and cannot determine that code cannot be reached without running every possible combination of inputs and input states, which is impractical for real code
c) Is not correct. Poor response times for most of the expected users are difficult to determine without executing the code (i.e., by static testing), so in this situation dynamic testing could find a defect, but static testing is unlikely to find it
d) Is not correct. A review of the code by someone who is aware of the required features could detect that the required features had not been implemented in the code, and dynamic testing could also be used to determine that these required features had not been implemented

Explanation / Rationale

a) Is not correct. It is often possible to use dynamic testing to cause a test object to fail in ways that could never be achieved by the users, such as by using fault injection. However, if the failure can never occur with real end users, then identifying it is not especially valuable as testing is ultimately aimed at improving the work product for the end users. Spending time testing for failures that cannot occur with real users is not an efficient use of a tester’s time
b) Is not correct. Static testing in the form of static analysis is used by developers to identify defects in their program code earlier than can be achieved through dynamic testing. Note, however, that static testing (and static analysis) is used to detect defects, not failures, which are found by dynamic testing. Thus it is the use of the term ‘failures’ that makes this an incorrect option
c) Is not correct. Static analysis directly detects anomalies in code, which may be defects, and this is normally for the developer, not the customer. The provision of evidence for release by the use of static analysis of elements that provide no output is nonsense
d) Is correct. Reviews are a form of static testing that can be applied from the very start of the software development lifecycle and are used to find defects that can be removed before subsequent development activities waste effort on faulty requirements. If the defects are not detected and removed early on, then when the defect is found derived work products, such as the design and code, will need to be changed as they were based on faulty requirements

Explanation / Rationale

a) Is not correct. Exploratory testing uses test charters, not a list of possible defects/failures. Although exploratory testing can incorporate the use of other test techniques, in this case fault attack is the most likely option
b) Is correct. This is a list of possible failures. Fault attacks are a methodical approach to the implementation of error guessing and require the tester to create or acquire a list of possible errors, defects and failures, and to design tests that will identify defects associated with the errors, expose the defects, or cause the failures
c) Is not correct. The tester is using a checklist of items to support their testing. Both error guessing and checklist-based testing use such lists, however, the list here is of possible failures, not test conditions, and so the MOST PROBABLE test technique is fault attack, which focuses on errors, defects and failures
d) Is not correct. BVA is based on an analysis of boundary values of equivalence partitions. The above list does not mention equivalence partitions or their boundaries

Explanation / Rationale

a) Is correct. Value “1” covers “length incorrect” and covers “number of different digits incorrect”, however the system would not validate against this partition when hitting the first incorrect partition. Value “1111” covers “length correct” and “number of different digits incorrect. Value “1234” again covers “length correct” and also “number of different digits correct”
b) Is not correct. These three values achieve full coverage of the equivalence partitions, but full coverage can be achieved with two values
c) Is not correct. These two values only cover “number of different digits
d) Is not correct. These two values does not cover “number of different digits incorrect” equivalence partition

Explanation / Rationale

Error guessing is about anticipating the errors, defects and failures based on the tester’s knowledge.
a) Is not correct. This is an example of anticipating the developer’s error
b) Is not correct. This is an example of anticipating the defect
c) Is correct. This is an example of a potential root cause of a defect, which is neither an error, defect nor failure, and difficult for the tester to anticipate
d) Is not correct. This is an example of anticipating a failure, perhaps based on experience of previous systems in this application domain

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 to be checked
c) Is correct. The list of user interface best practices is the list of test conditions to be systematically checked
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 correct. The number of defects found is related to the test object quality
b) Is not correct. This is the measure of the test efficiency not the test object quality
c) Is not correct. The number of test cases executed does not tell us anything about the quality; test results might do
d) Is correct. defect density is related to the test object quality
e) Is not correct. Time to repair is a process metric. It does not tell us anything about the product quality

Explanation / Rationale

a) Is not correct. DevOps enhances testing in several ways, such as by providing fast feedback on code quality, automated regression testing that minimizes regression risk, and promoting a shift-left approach with high-quality code submission and component tests. This is largely provided through continuous integration, where the developers submit component (unit) tests with their new code, which must pass for the code to be admitted to the build. Therefore, developers do need to complete component testin
b) Is correct. DevOps enhances testing in several ways, such as by providing fast feedback on code quality, automated regression testing that minimizes regression risk, and promoting a shift-left approach with high-quality code submission and component tests
c) Is not correct. DevOps enhances testing in several ways, such as by providing fast feedback on code quality, automated regression testing that minimizes regression risk, and promoting a shift-left approach with high-quality code submission and component tests. Testers do not attempt to treat developers and operations equally by spending more time on release testing, although a shift-right approach to testing (testing in production) may well be used
d) Is not correct. Automated processes like continuous integration/continuous delivery (CI/CD) in DevOps facilitate stable test environments and reduce the need for manual testing, however, there is a risk of overlooking the importance of manual testing, especially from a user's perspective

Explanation / Rationale

There are three equivalence partitions: {..., 10, 11}, {12}, and {13, 14, ...}.
The boundary values are 11, 12 and 13. In the three-point boundary value analysis for each boundary, we need to test the boundary and both its neighbors, so:

• for 11 we test 10, 11, 12

• for 12 we test 11, 12, 13

• for 13 we test 12, 13, 14

Altogether we need to test 10, 11, 12, 13, and 14

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

Explanation / Rationale

Considering each of the listed roles:

1. Scribe (or Recorder) - responsible for gathering feedback from reviewers and documenting review information, such as decisions made, and any new anomalies identified during the review meeting. (Records review information, such as decisions and new anomalies found during the review meeting - B)
2. Review Leader - responsible for overseeing the review process, such as selecting the review team members, scheduling review meetings, and ensuring that the review is completed successfully.
(Takes overall responsibility for the review such as organizing when and where the review will take place - D)
3. Facilitator (or Moderator) - responsible for ensuring that the review meetings run effectively, including managing time, mediating discussions, and creating a safe environment where everyone can voice their opinions freely. (Ensures the effective running of review meetings and the setting up of a safe review environment - A)
4. Manager - responsible for deciding what needs to be reviewed and allocating resources, such as staff and time, for the review. (Decides what is to be reviewed and provides resources, such as staff and time for the review - C)

Thus:
a) Is not correct
b) Is not correct
c) Is correct. The correct match is: 1B, 2D, 3A, 4C
d) Is not correc

Explanation / Rationale

a) Is not correct. In this case one test case is still needed since there is at least one (unconditional) branch to be covered
b) Is not correct. Covering only unconditional branches does not imply covering all conditional branches
c) Is not correct. 100% branch coverage implies 100% statement coverage, not otherwise. For example, for an IF decision without the ELSE, one test is enough to achieve 100% statement coverage, but it only achieves 50% branch coverage
d) Is correct. Each decision outcome corresponds to a conditional branch, so 100% branch coverage implies 100% decision coverage

Explanation / Rationale

a) Is correct. Test design involves using test conditions to create test cases and other necessary testware, such as test data requirements and test charters for exploratory testing. Test environment requirements are also specified, including the necessary infrastructure and tools
b) Is not correct. Test execution involves executing test cases (as part of test procedures), however it does not directly cover the other testware mentioned in the question, such as test data requirements, test environment requirements and test conditions
c) Is not correct. Test analysis is used to identify the features that require testing. The test basis is analyzed and defined as test conditions, which are then prioritized along with related risks. While this activity involves working with test conditions, it does not cover the other testware mentioned in the question, such as test data requirements, test environment requirements and test cases
d) Is not correct. Test implementation includes the generation of test procedures, such as manual and automated test scripts, which are created from test cases and may be assembled into test suites. Test procedures are prioritized and arranged in a test execution schedule. Test data is created, and the test environment built, and its set up verified. While this activity involves explicitly working with test cases, and may use test data requirements and test environment requirements to create test data and the test environment, it does not cover test conditions

Explanation / Rationale

a) Is not correct. Risk impact and risk likelihood are independent
b) Is not correct. Risk impact and risk likelihood are independent
c) Is correct. Risk impact and risk likelihood are independent
d) Is not correct. We need both factors to calculate risk level

Explanation / Rationale

a) Is not correct. Decision table testing is a black-box test technique, so it is specification-based, not structure-based – the test cases are not based on the decisions in the source code. In branch testing, the test cases are derived from knowledge of the control flow of the test object
b) Is not correct. Anticipation of potential defects is used in error guessing (an experience-based test technique), not in branch testing (a structure-based technique). In decision table testing, the test cases are derived from the specification that describes the business logic
c) Is not correct. If a test case is based on the knowledge of the control flow of the test object, it is a white-box test technique. Decision table testing is typically based on an analysis of business logic, so it is a black-box test technique. In branch testing, test cases are not derived from the specification – this would make it a black-box test technique. Branch testing is a white-box test technique, where test cases are derived based on the source code structure
d) Is correct. Decision table testing is a black-box test technique, so it is based on an analysis of the specified behavior of the test object without reference to its internal structure. Therefore, the test cases are independent of how the software is implemented. Branch testing is a white-box test technique, so test cases are based on an analysis of the test object’s internal structure and processing. As the test cases are dependent on how the software is designed and coded, they can only be created after the design or implementation of the test object

Explanation / Rationale

Only third-party executable code cannot be reviewed.
Thus:
a) Is not correct
b) Is not correct
c) It is correct
d) Is not correct

Explanation / Rationale

a) Is correct. Performing only black-box testing does not provide a measure of actual code coverage. White-box coverage measures provide an objective measurement of coverage and provide the necessary information to allow additional tests to be generated to increase this coverage, and subsequently increase confidence in the code
b) Is not correct. This statement is correct, but it has nothing to do with black-box testing
c) Is not correct. In general there are no subsumes relationships between white-box and black-box techniques
d) Is not correct. White-box techniques are used to design tests based on the test object itself, while black-box techniques are used to design tests based on the specification. Therefore, there is no relation between coverage items derived from these two types of techniques

Explanation / Rationale

a) Is not correct. In all types of reviews there is more than one role, even in informal ones
b) Is correct. There are several activities during the formal review process
c) Is not correct. Documentation to be reviewed should be distributed as early as possible
d) Is not correct. Defects found during the review should be reported

Explanation / Rationale

a) Is not correct. The approval of the budget is an example of an entry criterion. It would make no sense to approve the budget for some activity that has already been done
b) Is correct. Running out of budget can be viewed as a valid exit criterion
c) Is not correct. Availability of resources is an example of an entry criterion for testing
d) Correct. Coverage is a measure of thoroughness, so it is a typical exit criterion
e) Is not correct. This is an example of an entry criterion, checked before the project starts