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. Although it is true that the tester can implement and execute detailed test cases based on the checklist, it does not explain how this would result in increased coverage
b) Is not correct. Checklist items should not be automated. But even if they are, the automated test scripts always execute the tests in the same way, which usually does not result in increased coverage
c) Is not correct. It is true that each checklist item should be tested separately and independently. But this impacts the test execution order and does not impact the achieved coverage, and so does not result in increased coverage
d) Is correct. If the checklists are high-level, some variability in the actual testing is likely to occur, resulting in potentially greater coverage but less repeatability. If two testers follow a checklist of high-level items, each of them may use different test data, test steps, etc. This way, one tester will probably cover some areas not covered by the other tester and this will result in increased 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

“test” and “error” transitions cannot occur in one test case.
Neither can both “done” transitions.
This means we need at least three test cases to achieve transition coverage. For example:

TC1: test, done
TC2: run, error, done
TC3: run, pause, resume, pause, done

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

Explanation / Rationale

a) Is not correct. This is the task of the review leader
b) Is correct. This is the task of the management in a formal review
c) Is not correct. This is the task of the moderator
d) Is not correct. This is the task of the scribe

Explanation / Rationale

a) Is not correct. The organization’s marketing team is unlikely to perform much testing (although in some organizations they may be involved with acceptance testing), so their average level of experience (most of which would be in marketing) is not likely to impact how testing is performed for a given test object
b) Is not correct. The level of knowledge of users that a new system is being built for them is unlikely to affect how testing is performed. Any user involvement that could affect how testing is performed is more likely to be as a result of decisions made by the testers, customer and project manager
c) Is correct. The number of years’ experience of the members of the performance testing team will help to determine the capabilities and knowledge (e.g., of different tools and defect types) that the team members will apply when they are testing
d) Is not correct. The organizational structure of the different end users (who may be varied) will change between users. So, it may not even be known when the application is being tested, and the end user’s organizational structure can thus have little effect on how the testing is performed

Explanation / Rationale

a) Is not correct. Assuming that testers could check the ease of changing the currency exchange system then it would be done by maintainability testing rather than maintenance testing, so this is not a trigger for maintenance testing
b) Is correct. A system modification (such as a fix or enhancement) is an example of a trigger for maintenance testing. The removal of the refund option of the currency exchange system was a fix that would lead to maintenance testing
c) Is not correct. If the agile team has started developing a user story that adds a new customer loyalty feature to the currency exchange system, then this will result in them testing the new feature, and then they would perform regression testing. No maintenance testing is required in this situation
d) Is not correct. Reconfiguration of the currency exchange system to support both the local language and English currency transactions is not a system modification, a change to the operational environment, or a system retirement, which are the three triggers for maintenance testing

Explanation / Rationale

Considering each of the listed risks and their mitigations:

1. Long system responses (1) can be tested in performance testing (B)
2. Changes of consumers’ preferences (2) are usually out of our control, so usually we accept this risk (A)
3. Flooding of the server room (3) can cause significant loss, so we should transfer the risk, e.g., by buying an insurance policy (D)
4. That patients above a certain age receive inaccurate reports (4) suggests a potential boundary problem, which can be effectively detected with techniques like BVA (C)

Thus:
a) Is not correct
b) Is not correct
c) Is correct. The correct combinations of risk and mitigation are: 1B, 2A, 3D and 4C
d) Is not correct

Explanation / Rationale

a) Is not correct. This should be a team activity and not overruled by one team member
b) Is correct. If test estimates are not the same, but the variation in the results is small, applying rules like “accept the number with the most votes” can be applied
c) Is not correct. There is no consensus yet as some say 13, others say 8
d) Is not correct. A feature should not be removed only because the team cannot agree on the test estimates

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

a) Is not correct. Practices involved in shift-left testing are aimed at implementing more testing activities in the early phases of the development life cycle, portraying the SDLC as moving from left to right. There is no such thing as the left-hand side of the test process
b) Is correct. Shift-left emphasizes the importance of starting testing earlier in the software development lifecycle (SDLC). Implementing shift-left testing necessitates additional training, and increased effort and costs during the early stages of the SDLC, nevertheless, overall savings should be higher
c) Is not correct. Although automated component tests and component integration tests for regression testing are generally valuable, the creation of these tests is normally the responsibility of the developers, and if a continuous integration/continuous delivery (CI/CD) approach is followed, then these tests will have been submitted with the code. In some situations the tester may automate tests for regression testing, and sometimes even for component tests and component integration tests, however this is not part of a ‘shift-left’ approach which moves testing earlier in the SDLC
d) Is not correct. Training testers to perform tasks early in the SDLC would support a shift-left approach by emphasizing the importance of starting testing earlier in the SDLC. However, automating more test activities to be performed later in the SDLC is not part of a ‘shift-left’ approach

Explanation / Rationale

a) Is correct. The whole team approach promotes robust communication and collaboration between the team members
b) Is not correct. While the whole team approach prioritizes collective accountability for quality, each individual team member is still equally accountable for quality
c) Is not correct. The whole team approach is about how the team works together, with the aim of higher quality deliverables, but it does not necessarily result in faster deployment to end users
d) Is not correct. When using the whole team approach, testers work with business representatives to create acceptance tests. There is no suggestion that the approach will reduce collaboration with external business users

Explanation / Rationale

Consider:

i. Is true. Faster product release and faster time to market is an advantage of DevOps
ii. Is false. Typically, we need less effort for manual tests because of the use of test automation
iii. Is true. Constant availability of executable software is an advantage
iv. Is false. More regression tests are needed
v. Is false. Not everything is automated and setting up a test automation framework is expensive

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

Explanation / Rationale

a) Is correct. Debugging is the process of finding, analyzing, and removing the causes of failures in a component or system
b) Is not correct. Testing is the process concerned with planning, preparation and evaluation of a component or system and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects. It is not related to fixing causes of failures
c) Is not correct. Requirement elicitation is the process of gathering, capturing, and consolidating requirements from available sources. It is not related to fixing causes of failures
d) Is not correct. Defect management is the process of recognizing, recording, classifying, investigating, resolving, and disposing of defects. It is not related to fixing causes of failures

Explanation / Rationale

i. Is true. The SDLC has an influence on the test process
ii. Is false. The number of defects detected in previous projects may have some influence, but this is not as significant as i, iii and iv
iii. Is true. The identified product risks are one of the most important factors influencing the test process
iv. Is true. Regulatory requirements are important factors influencing the test process
v. Is false. The test environment has no significant influence on the test process

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

Explanation / Rationale

The ‘absence-of-defects fallacy’ is concerned with the idea that ensuring correctness in accordance with the requirements (i.e., verifying the absence of implementation defects) does not guarantee user satisfaction with the system. To address this it is also necessary to validate that the system meets users' needs and expectations, fulfills business objectives, and outperforms competing systems.
a) Is not correct. The ‘testing shows the presence, not the absence of defects’ principle explains that while testing can detect the existence of defects in the test object, it is not possible to demonstrate that there are no defects and, therefore, guarantee its correctness. Therefore, explaining that it is not possible for testing to show the absence of defects would partially address this principle, not the ‘absence-of-defects’ fallacy
b) Is correct. By supporting the end user to perform acceptance testing it should be possible to validate that the system meets users' needs and expectations
c) Is not correct. It is not possible to ensure that no implementation defects remain in the delivered system as the ‘testing shows the presence, not the absence of defects’ principle explains that while testing can detect the existence of defects in the test object, it is not possible to demonstrate that there are no defects and, therefore, guarantee its correctness
d) Is not correct. Modifying tests that cause no failures to ensure few defects remain is one way to address the ‘tests wear out’ principle. This principle is concerned with the idea that repeating identical tests on unaltered code is unlikely to uncover novel defects and therefore, modifying tests may be essential. This will not validate that the system meets users' needs and expectations

Explanation / Rationale

a) Is correct. Behavior-Driven Development (BDD) is a well-known example of a test-first approach to development
b) Is not correct. Test Level Driven Development is not a correct example of a test-first approach to development
c) Is not correct. Function-Driven Development is not a correct example of a test-first approach to development
d) Is not correct. Performance-Driven Development is not a correct example of a test-first approach to development

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. Confirmation testing to check that the updates have resulted in a correct implementation is necessary, however, it would then be sensible to perform regression testing to ensure that no defects have been introduced or uncovered in unchanged areas of the system
b) Is correct. Confirmation testing will check that the updates have resulted in a correct implementation, and then regression testing will be used to ensure that no defects have been introduced or uncovered in unchanged areas of the system
c) Is not correct. Regression testing should be used to ensure that no defects have been introduced or uncovered in unchanged areas of the system when the update was made, however it is also necessary to perform confirmation testing that will check that the updates have resulted in a correct implementation
d) Is not correct. Confirmation testing will check that the updates have resulted in a correct implementation, and regression testing will be used to ensure that no defects have been introduced or uncovered in unchanged areas of the system. However, when performed (i.e., when an update needs to be tested), confirmation testing precedes regression testing

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. Feedback can improve the test process, but if one only wants to improve future projects, the feedback does not need to come early or frequently
b) Is not correct. Feedback is not used to prioritize requirements
c) Is not correct. The quality of changes can be measured in multiple ways
d) Is correct. Early and frequent feedback allows for the early communication of potential quality problems

Explanation / Rationale

The following three transitions:

“REQUESTING -> CONFIRMED”
“WAITING LIST -> CONFIRMED”
“WAITING LIST -> END”

cannot appear in the same test case, which suggests that at least three test cases are required. All the other transitions can appear in combination with one or more of these three transitions, so we need a minimum of three test cases. In fact, only three sequences are possible:

TC1: START (Room request) → REQUESTING (Available) → CONFIRMED (Pay) → END
TC2: START (Room request) → REQUESTING (Not available) → WAITING LIST (Available) → CONFIRMED (Pay) → END
TC3: START (Room request) → REQUESTING (Not available) → WAITING LIST (Cancel) → END

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

Explanation / Rationale

Test TC 001 must come first, followed by TC 002, to satisfy dependencies. Afterwards, TC 003 to satisfy priority and then TC 004, followed by TC 005.
Thus:
a) Is correct
b) Is not correct
c) Is not correct
d) Is not correct

Explanation / Rationale

a) Is not correct. Test execution and coverage tools facilitate the automated execution of test cases and the measurement of the coverage achieved by running those test cases. However, these tools do not help with the organization of defects and configuration management
b) Is not correct. Test design and implementation tools facilitate the generation of test cases, test data and test procedures, but they do not help with the organization of defects and configuration management
c) Is not correct. Defect management tools are used to manage defects but are not testing tools and are not used to organize test cases or configuration management
d) Is correct. Test management tools increase the test process efficiency by facilitating the management of the software development lifecycle (SDLC), requirements, tests, defects, and configuration management

Explanation / Rationale

a) Is not correct. The expected result is “the application should accept the provided input and create the user”. The actual result is “The application hangs up after entering “Test input. $ä””.
b) Is not correct. There is a reference to the test case and to the related requirement and it states that the defect is rejected. Also, the defect status would not be very helpful for the developers
c) Is correct. We do not know in which test environment the anomaly was detected, and we also do not know which application (and its version) is affected
d) Is not correct. The defect report states that the anomaly is urgent, that it is a global issue (i.e., many, if not all, test administration accounts are affected) and states the impact is high for business stakeholders

Explanation / Rationale

a) Is not correct. Impediments to testing can be high level and business-related, so this is an important piece of information for business stakeholders
b) Is correct. Branch testing is a technical metric used by developers and technical testers. This information is of no interest to business representatives
c) Is not correct. Test progress is project related, so it may be useful for business representatives
d) Is not correct. Risks impact product quality, so it may be useful for business representatives

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. Testing quadrants group test levels and test types separately according to several criteria. They do not represent any combinations of test levels and test types and they are not related to any location within a software development lifecycle. Both test levels and test types are treated separately in the testing quadrants model
b) Is not correct. Testing quadrants group test levels and test types according to several criteria. They do not describe the degree of granularity of individual test types performed at each test level. Such a model, regarding the test levels, is called the test pyramid
c) Is not correct. The statement is wrong, because in general any test type can be performed at any test level
d) Is correct. The testing quadrants group test levels, test types, activities, test techniques and work products in Agile software development. In this model, tests can be business facing or technology facing. Tests can support the team (i.e., guide the development) or critique the product (i.e., measure its behavior against expectations). The combination of these two viewpoints determines the four quadrants

Explanation / Rationale

a) Is correct. Checking that the sort function puts the elements of the list or array in ascending order is evaluating the functional correctness of the sort function, which is part of functional testing
b) Is not correct. Assessing whether the sort function meets its non-functional requirement to complete within one second is part of testing its performance efficiency, which is part of non-functional testing
c) Is not correct. Evaluating the ease with which the sort function can be modified from sorting ascending to sorting descending is testing its modifiability, a form of non-functional maintainability testing, which is part of non-functional testing
d) Is not correct. Assessing that the sort function still functions correctly when moved from a 32-bit to a 64-bit architecture is testing its adaptability, a form of portability testing, which is part of non-functional testing

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. The combination (T, T, F) does not match any rule. This is an example of omission, not a contradiction
b) Is not correct. The combination (T, F, T) matches only one column, R2, so there is no contradiction
c) Is not correct. Both combinations (T, T, T) and (F, T, T) match only one column, R1, so there is no contradiction
d) Is correct. The combination (F, F, F) matches both R2 and R3, but R2 and R3 have different actions, so this shows a contradiction between R2 and R3.

Explanation / Rationale

a) Is correct. It is important that testers are involved from the beginning of the software development lifecycle (SDLC). It will increase understanding of design decisions and will detect defects early.
b) Is not correct. Both developers and testers will have more understanding of each other's work products and how to test the code
c) Is not correct. End users will not help the testers in increasing the quality of defect reports; also, users usually do not participate in low-level testing levels like integration testing
d) Is not correct. Being certified does not automatically mean that the tester will be better in test design

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

In the three-point estimation technique:

E = (optimistic + 4*most likely + pessimistic)/6

E = (2+(4*11)+14)/6 = 10

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

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

The five listed descriptions and the corresponding review process activities are:

1. This describes part of the ‘communication and analysis’ activity
2. This describes part of the ‘fixing and reporting’ activity
3. This describes part of the ‘individual review’ activity
4. This describes part of the ‘planning’ activity
5. This describes part of the ‘review initiation’ activity

The generic review process from ISO/IEC 20246, which is outlined in the syllabus, comprises the following activities in this logical order:

• Planning (4)
• Review initiation (5)
• Individual review (3)
• Communication and analysis (1)
• Fixing and reporting (2)

Thus:
a) Is not correct
b) Is correct. The correct sequence of activities is: 4 – 5 – 3 – 1 – 2
c) Is not correct
d) Is not correct

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

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

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