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 correct. Since 100% statement coverage is achieved, every statement, including the ones with defects, must have been executed and evaluated at least once
b) Is not correct. Coverage depends on what is tested, not on the number of test cases. For example, for code “if (x==0) y=1”, one test case (x=0) achieves 100% statement coverage, but two test cases (x=1) and (x=2) together achieve only 50% statement coverage
c) Is not correct. If there is a loop in the code there may be an infinite number of possible paths, so it is not possible to execute all the possible paths in the code
d) Is not correct. Exhaustive testing is not possible (see the seven testing principles section in the syllabus). For example, for code “input x; print x” any single test with arbitrary x achieves 100% statement coverage, but covers one input value

Explanation / Rationale

a) Is not correct. This is a common characteristic of white-box test techniques. Test conditions, test cases, and test data are derived from a test basis that may include code, software architecture, detailed design, or any other source of information regarding the structure of the software.
b) Is not correct. This is a common characteristic of white-box test techniques. Coverage is measured based on the items tested within a selected structure and the technique applied to the test basis
c) Is correct. This is a common characteristic of experience-based test techniques. This knowledge and experience include expected use of the software, its environment, likely defects, and the distribution of those defects is used to define tests
d) Is not correct. This is a common characteristic of black-box test techniques. Test cases may be used to detect gaps within requirements and the implementation of the requirements, as well as deviations from the requirements

Explanation / Rationale

a) Is not correct. The manager is responsible for deciding what needs to be reviewed and allocating resources, such as staff and time, for the review
b) Is correct. The moderator (or facilitator) is 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
c) Is not correct. The chairperson is not a recognized role in reviews
d) Is not correct. The review leader is responsible for overseeing the review process, such as selecting the review team members, scheduling review meetings, and ensuring that the review is completed successfully

Explanation / Rationale

Considering each of the listed example defects:

i. Two different parts of the design specification disagree due to the complexity of the design – this is an example of a specification defect, which includes inconsistencies, ambiguities, contradictions, omissions, inaccuracies, and duplications, which can most easily be found by static testing
ii. A response time is too long and so makes users lose patience – this is an example of a response time defect, which can only be detected in practice by executing the program and measuring the response time, which can most easily be found by dynamic testing
iii. A path in the code cannot be reached during execution - this is an example of a coding defect, which includes variables with undefined values, undeclared variables, duplicated or unreachable code, and excessive code complexity, which can most easily be found by static testing
iv. A variable is declared but never subsequently used in the program - this is an example of a coding defect, which includes variables with undefined values, undeclared variables, duplicated or unreachable code, and excessive code complexity, which can most easily be found by static testing
v. The amount of memory needed by the program to generate a report is too high – this is an example of a performance defect, which can only be detected in practice by executing the program and measuring the memory used, which can most easily be found by dynamic testing

Thus:
a) Is not correct
b) Is not correct
c) Is not correct
d) Is correct. The correct match for static testing is i, iii, and iv

Explanation / Rationale

a) Is not correct. Test environment readiness is a resource availability criterion; hence it belongs to the entry criteria
b) Is not correct. This is a resource availability criterion; hence it belongs to the entry criteria
c) Is correct. Estimated defect density is a measure of diligence; hence it belongs to the exit criteria.
d) Is not correct. Requirements translated into a given format result in testable requirements; hence it belongs to the entry criteria
e) Is correct. Automation of regression tests is a completion criterion; hence it belongs to the exit criteria

Explanation / Rationale

a) Is not correct. The root cause is the distraction that the programmer experienced while programming
b) Is not correct. Accepting invalid inputs is a failure
c) Is not correct. The error is the mistaken thinking that resulted in putting the defect in the code
d) Is correct. The problem in the code is a defect

Explanation / Rationale

a) Is not correct. The miscalculation of bonuses is a failure by the system, not a defect
b) Is not correct. The system not suitably supporting disabled users is a failure which eventually results in a fine, but the fine itself is not a failure (it appears to be the correct functioning of the regulatory system)
c) Is correct. The error is made by the programmer and this mistake is caused by them working under severe time pressure, which is the root cause of the subsequent defect
d) Is not correct. The poor design of the user interface, which does not suitably address disabled users, is a design defect caused by the designer error. Thus the design of the user interface includes a design defect not a designer error

Explanation / Rationale

Considering the attributes:

• Specified for walkthroughs, technical reviews, and inspections; thus, the reviews being performed cannot be informal reviews
• The purpose of evaluating quality is one of the most important objectives of a walkthrough
• This is not allowed for inspections and is typically not done in technical reviews. A moderator is needed in walkthroughs and is allowed for informal reviews
• All types of reviews can include individual preparation (even informal reviews)
• All types of reviews can produce a review report, although informal reviews do not require documentation

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

Explanation / Rationale

In branch testing the coverage items are branches, which are represented by the edges of a control flow graph. There are 8 edges in the control flow graph.
Thus:
a) Is not correct
b) Is not correct
c) Is correct
d) Is not correct

Explanation / Rationale

The testware under consideration is a test charter

Test charters are the output from test design
Thus:
a) Is not correct
b) Is not correct
c) Is not correct
d) Is correct

Explanation / Rationale

a) Is correct. Test automation can provide measures that are too complicated for humans to derive, such as white-box test coverage measures for all but the most trivial code
b) Is not correct. By using test tools the responsibility for the testing is NOT shared with the tool vendor as the vendor is not involved in the testing, and it is the tester’s responsibility. The only possible responsibility that could be assigned to the tool vendor is if the tool fails to work as expected and provides incorrect test results
c) Is not correct. Testers still need to perform critical thinking when analyzing anomalies in the test results to determine their likely cause
d) Is not correct. Neither testers nor tools can generate test cases simply from an analysis of the program code as the code is the implementation and provides no information on the expected results, which will need to come from another part of the test basis, such as the design specification

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

Test cases TC1, TC2, TC3 and TC4 cover, respectively, rules R2, R3, R7 and R6 in the decision table.
a) Is correct. The conditions “66-year-old”, “unregistered” and “no experience” match rule R4, which is not covered by the existing test cases, so after adding this test case, the decision table coverage will increase
b) Is not correct. The conditions “55-year-old”, “unregistered” and “2 years of experience” match rule R2, already covered by TC1. So adding this test case will not increase the coverage
c) Is not correct. The conditions “19-year-old”, “registered” and “5 years of experience” match rule R6, already covered by TC4. So adding this test case will not increase the coverage
d) Is not correct. The existing test cases cover only 4 out of 7 columns of the decision table. The coverage can be increased by adding test cases that cover yet uncovered columns, that is, R1, R4 and R5

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

a) Is not correct. Planning poker can estimate effort for a user story that is already written. It does not help in understanding what should be delivered
b) Is not correct. Reviews are not a collaborative user story writing practice
c) Is not correct. Iteration planning is a project-related practice, used to plan the work, not to understand what needs to be delivered
d) Is correct. Conversation explains how the software will be used and often allows the team to define meaningful acceptance criteria, thus obtaining a shared vision of what should be delivered

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

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 correct. The ‘tests wear out’ 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. By using high-level test conditions to generate new tests each time, the tests will not be identical and should not ‘wear out’
b) Is not correct. The ‘absence-of-defects fallacy’ principle is concerned with ensuring that users’ needs are fulfilled even if lots of testing is done and no defects are found (i.e., validation is also necessary). The use of high-level test conditions to generate test cases and execute tests does not directly address this concern
c) Is not correct. 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. This is typically addressed by starting testing (both static and dynamic) as early as possible, but this is not addressed by using high-level test conditions to generate test cases and execute tests
d) Is not correct. The ‘Defects cluster together’ principle is concerned with the distribution of defects in a system, which typically follows a Pareto distribution. The use of high-level test conditions to generate test cases and execute tests does not address this concern, which is typically addressed by risk-based testing

Explanation / Rationale

a) Is not correct. Adequate time for individuals is a success factor
b) Is not correct. Splitting work products into small adequate parts is a success factor
c) Is not correct. Avoiding behaviors that might indicate boredom, exasperation, etc. is a success factor
d) Is correct. During reviews one can find defects, not failures

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

Consider:

i. It is a Project risk
ii. It is a Product risk
iii. It is a Product risk
iv. It is a Project risk
v. It is a Product risk

Thus:
a) Is correct
b) Is not correct
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

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 correct. Product quality metrics measure quality characteristics. Mean time to failure measures maturity, so it is a product quality metric
b) Is not correct. This is an example of a defect metric, not a product quality metric
c) Is not correct. This is an example of a coverage metric, not a product quality metric
d) Is not correct. This is an example of a defect metric, not a product quality metric

Explanation / Rationale

a) Is correct. This test covers two acceptance criteria: one about editing the document and one about saving changes
b) Is not correct. Acceptance criteria cover the editor activities, not the content owner activities
c) Is not correct. Scheduling the edited content for publication may be a nice feature, but it is not covered by the acceptance criteria
d) Is not correct. Acceptance criteria state about reassigning from an editor to the content owner, not to another editor

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. Quality should be the responsibility of everyone working on the project and not the sole responsibility of the test team
b) Is not correct. First, it is not a benefit if an external test team does not meet delivery deadlines, and second, there is no reason to believe that external test teams will feel they do not have to meet strict delivery deadlines
c) Is not correct. It is bad practice for the test team to work in complete isolation, and we would expect an external test team to be concerned with changing project requirements and communicating well with developers
d) Is correct. Specifications are never perfect, meaning that assumptions will have to be made by the developer. An independent tester is useful in that they can challenge and verify the assumptions and subsequent interpretation made by the developer

Explanation / Rationale

Considering each of the listed tool categories:

i. Collaboration tools – facilitate communication. Communication does not include the facilitation of test execution
ii. DevOps tools - support the DevOps delivery pipeline, workflow tracking, automated build process(es) and CI/CD. The delivery pipeline and CI/CD both include the facilitation of test execution, such as component testing for CI
iii. Management tools – increase the test process efficiency by facilitating management of the SDLC, requirements, tests, defects and configuration. The management of these items does not include the facilitation of test execution
iv. Non-functional testing tools – allow the tester to perform non-functional testing that is difficult or impossible to perform manually. Non-functional testing can include both static testing and dynamic testing, including test execution
v. Test design and implementation tools – facilitate generation of test cases, test data and test procedures. The generation of this testware does not include the facilitation of test execution

Thus:
a) Is not correct
b) Is correct. Both DevOps tools (ii) and Non-functional testing tools (iv) facilitate test execution
c) Is not correct
d) Is not correct

Explanation / Rationale

a) Is not correct. The test case is related to viewing previous orders in the order history
b) Is not correct. The test case is related to viewing previous orders
c) Is not correct. The test case is related to viewing previous orders in the order history
d) Is correct. The test case is related to the registration process, which is not discussed in the user story. The user story is about viewing previous orders

Explanation / Rationale

a) Is not correct. Retrospectives are more useful for identifying improvement opportunities and have little importance for clients
b) Is not correct. Business representatives are not giving feedback about the product itself. Therefore, there is no financial gain to the organization
c) Is correct. Regularly conducted retrospectives, when appropriate follow up activities occur, are critical to continual improvement of development and testing
d) Is not correct. Courage and respect are values of Extreme Programming and are not closely related to retrospectives

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. Risk management consists of risk analysis and risk control. Neither of these activities supports the reassembly of the files that made up the release, because these activities deal with risks, not with configuration items
b) Is not correct. Test monitoring is concerned with gathering information about testing. This information is used to assess test progress and to measure whether the test exit criteria or the test tasks associated with the exit criteria are satisfied, such as meeting the targets for coverage of product risks, requirements, or other acceptance criteria. Test control uses the information from test monitoring to provide, in the form of control directives, guidance and the necessary corrective actions to achieve the most effective and efficient testing. None of these activities deal with the management of configuration items
c) Is not correct. The whole-team approach builds on the tester’s skill to work effectively in a team context and to contribute positively to the team goals. So, it focuses on team-related issues, not on configuration items
d) Is correct. Configuration management provides a discipline for identifying, controlling, and tracking work products. Configuration management keeps a record of changed configuration items when a new baseline is created. Using configuration management, it is possible to revert to a previous baseline in order to reproduce previous test results

Explanation / Rationale

a) Is correct. This is something that can (and should) be checked before the code is submitted to version control
b) Is not correct. This is something that can be checked after step (2) is performed, because merge conflict reporting can be done after the code is submitted and merged
c) Is not correct. This fits better as the entry criterion for step (3)
d) Is not correct. This fits better as the exit criterion for step (3)

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 not correct. Checklists should contain test conditions to be verified. This is an example of an error, not a test condition; even if the tester was able to deduce some potential test conditions from the examples of errors, this error description is too general
b) Is not correct. Checklists should not contain items that are better suited as exit criteria. This is an example of an exit criterion
c) Is not correct. Checklists should not contain items that are too general. This is a very general item, which practically describes the goal of testing
d) Is correct. This is an example of a test condition that can be checked by a human

Explanation / Rationale

a) Is not correct. Usability testing is business facing testing that critiques the product (Q3)
b) Is not correct. Functional testing is business facing testing (Q2)
c) Is not correct. User acceptance testing is business facing testing that critiques the product (Q3)
d) Is correct. Component integration testing is technology facing testing that supports the team (guides the development) (Q1)

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. Early review is an example of the shift left approach
b) Is not correct. TDD is an example of the shift left approach
c) Is not correct. Early non-functional testing is an example of the shift left approach
d) Is correct. Test scripts should be subject to configuration management, so it makes no sense to create the test scripts before this process is set up

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