Explanation / Rationale

a) Is not correct. Testing quadrants have nothing to do with describing the relationships between test levels
b) Is not correct. Testing quadrants cannot help in assessing any type of coverage
c) Is correct. Testing quadrants allow managers and other stakeholders to understand the relationships between test types, the activities they support (team support or product critique), and the viewpoint they are focused on (business- or technology-facing)
d) Is not correct. Testing quadrants is not a psychological model

Explanation / Rationale

a) Is not correct. This acceptance criterion describes what rules or regulations the system must adhere to (in this case, the right to be forgotten). This is an example of a rule-oriented acceptance criterion
b) Is correct. This acceptance criterion describes an example scenario that must be realizable by the system. This is an example of a scenario-oriented acceptance criterion
c) Is not correct. This sentence looks more like a line of code that implements some business rule. Acceptance criteria should be written in collaboration with business representatives, and therefore should be written in language they understand. This sentence will most likely be unintelligible to these stakeholders
d) Is not correct. This acceptance criterion describes what rules or regulations the system must adhere to and how compliance will be ensured. Therefore, this is an example of a rule-oriented acceptance criterion, not a scenario-based acceptance criterion

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

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 correct. Obtaining feedback from stakeholders early and often in the software development process can be highly beneficial. It facilitates early communication of potential quality issues, can prevent misunderstandings about requirements, and ensures that any changes in stakeholder requirements are understood and implemented sooner
b) Is not correct. The feedback is from stakeholders, and them providing feedback is unlikely to improve their understanding of their own user requirements
c) Is not correct. Obtaining feedback from stakeholders early and often in the software development process can be highly beneficial. It facilitates early communication of potential quality issues, can prevent misunderstandings about requirements, and ensures that any changes in stakeholder requirements are understood and implemented sooner. However, because changes in requirements can be understood and implemented sooner, it does not mean that unlimited changes to requirements are encouraged
d) Is not correct. The feedback is from stakeholders and does not cover communication to them. Communications to end users could include them being told about which requirements will not be implemented prior to release, but ideally this should not happen at all

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

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

Exploratory testing is useful when there are few or inadequate specifications or there is significant time pressure on the testing. Exploratory testing is also useful to complement other more formal test techniques. Exploratory testing will be more effective if the tester is experienced, has domain knowledge and has a high degree of essential skills, like analytical skills, curiosity and creativeness.

Thus:
a) Is correct. Exploratory testing is useful when there are few or inadequate specifications or there is significant time pressure on the testing
b) Is not correct. Exploratory testing is not a black-box test technique
c) Is not correct. Exploratory testing is useful when the specifications are poorly written
d) Is not correct. Programming skills have nothing to do with exploratory testing in principle
e) Is correct. Exploratory testing will be more effective if the tester is experienced, has domain knowledge and has a high degree of essential skills, like analytical skills, curiosity and creativeness

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

From the graph we have:

A(4)=6 and A(3)=8 (the last two gray boxes).

From the formula we obtain:

E(5) = (3*A(4) + A(3)) / 4 = (3*6+8) / 4 = 26 / 4 = 6.5 person-days.

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

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

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. Collaborative user story writing means that all stakeholders create the user stories collaboratively, to obtain the shared vision
b) Is correct. Collaborative user story writing means that all stakeholders create the user stories collaboratively, to obtain the shared vision
c) Is not correct. Collaborative user story writing means that all stakeholders create the user stories collaboratively, to obtain the shared vision
d) Is not correct. This is the list of properties that each user story should have, not the description of the collaboration-based approach

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 correct. For a complex configuration item (e.g., a test environment), CM records the items it consists of, their relationships, and versions
b) Is not correct. CM tools do not execute test cases and do not calculate coverage
c) Is not correct. A CM tool is not a license management tool
d) Is not correct. CM tools do not generate test data

Explanation / Rationale

a) Is correct. The client is in a different location and time zone, so it may be difficult to communicate face-to-face
b) Is not correct. Dashboards are usually available to any user at any time, so the difference in time zones will not be as much of a hindrance to communication as verbal, face-to-face communication
c) Is not correct. Although the time difference between Europe and America is several hours, and this may cause some inconvenience, it's certainly not as great as with communicating face-to-face
d) Is not correct. Video conferencing tools are a convenient means of communication. Although communication between Europe and America during working hours usually requires one party to connect in the very early or very late hours, this is not as much of an inconvenience as verbal, face-to-face communication

Explanation / Rationale

a) Is not correct. The paragraph contains information on test levels and exit criteria, which are part of the test approach
b) Is not correct. The paragraph contains information on test levels and exit criteria, which are part of the test approach
c) Is not correct. The paragraph contains information on test levels and exit criteria, which are part of the test approach
d) Is correct. The paragraph contains information on test levels and exit criteria, which are part of the test approach

Explanation / Rationale

a) Is correct. System testing examines the behavior and capabilities of the complete system and covers non-functional testing of quality characteristics, which includes security testing. This type of testing is often performed by an independent test team based on system specifications
b) Is not correct. System integration testing examines the interfaces with other systems and external services
c) Is not correct. Beta testing is a type of acceptance testing performed at an external site by roles outside the development organization
d) Is not correct. Component integration testing involves testing the (interfaces and) interactions between components of a system, such as the user interface and database

Explanation / Rationale

a) Is not correct. The feedback is from stakeholders (e.g., business representative, end user), not from developers, so this feedback is not likely to inform managers which developers are more or less productive
b) Is not correct. Early and frequent feedback from stakeholders is not used by project managers to prioritize how they interact with the different stakeholders
c) Is correct. Obtaining feedback from stakeholders early and often in the software development process can be highly beneficial as it facilitates early communication of potential quality issues, can prevent misunderstandings about requirements, and ensures that any changes in stakeholder requirements are understood and implemented sooner
d) Is not correct. Early and frequent feedback can prevent the development of a product that does not meet stakeholder needs, and results in costly rework and missed deadlines, so, ideally there should be no delay. Also, the feedback is from stakeholders (not to them), which includes the end users, so the end users providing feedback will not aid the end users’ understanding

Explanation / Rationale

a) Is not correct. Coverage is always defined as the percentage of the covered elements. Therefore, it cannot exceed 100%
b) Is correct. If the statements executed by T1 and T2 were disjoint, the coverage of the test suite {T1, T2} would be 105%, which is impossible (see answer a). Therefore, at least 5% of executable statements must have been executed by both T1 and T2
c) Is not correct. Statement coverage does not tell us anything about the number of non-executable statements in the code
d) Is not correct. Even if a test suite achieves full statement coverage, this does not imply achieving full branch coverage

Explanation / Rationale

a) Is correct. When a system is retired, this can require testing of data migration, which is a form of maintenance testing
b) Is not correct. Regression testing verifies whether a fix accidentally affected the behavior of other parts of the code, but now we are talking about data migration to a new system
c) Is not correct. Component testing focuses on individual hardware or software components, not on data migration
d) Is not correct. Integration testing focuses on interactions between components and/or systems, not on data migration

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. 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 correct. The basic concept behind error guessing is that the tester tries to guess what errors may have been made by the developer and what defects may be in the test object based on past experience (and sometimes checklists)
b) Is not correct. Although a testers who used to be a developer may use their personal experience to help them when performing error guessing, the test technique is not based on prior knowledge of development
c) Is not correct. Error guessing is not a usability technique for guessing how users may fail to interact with the test object
d) Is not correct. Duplicating the development task has several flaws that make it impractical, such as the tester having equivalent skills to the developer and the time involved to perform the development. It is not error guessing

Explanation / Rationale
a) Is not correct. Retrospectives are used to capture lessons learned and to improve the development and testing process, not to document the acceptance criteria
b) Is correct. This is the standard way to document acceptance criteria
c) Is not correct. Verbal communication does not allow to physically document the acceptance criteria as part of a user story (”card” aspect in the 3C’s model)
d) Is not correct. Acceptance criteria are related to a user story, not a test plan. Also, acceptance criteria are the conditions that have to be fulfilled to decide if the user story is complete. Risks are not such conditions

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

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 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. The detection of additional high-severity defects would be a benefit of test automation, rather than a risk
b) Is not correct. The provision of measures that are too complicated for humans to derive themselves is normally considered to be a benefit of test automation
c) Is correct. If the test automation is incompatible with the development platform, then it will not be able to integrate them, and, for instance, pass test inputs to the test object and receive test results from the test object
d) Is not correct. Substantially reduced test execution times would normally be considered a benefit that is provided by test automation

Explanation / Rationale

a) Is correct. Test-Driven Development (TDD) is a well-known example of a test-first approach to development
b) Is not correct. Coverage-Driven Development is not a correct example of a test-first approach to development
c) Is not correct. Quality-Driven Development is not a correct example of a test-first approach to development
d) Is not correct. Feature-Driven Development is not an example of a test-first approach to development, but is, instead, an agile software development methodology based around delivering features (as opposed to user stories in Scrum)

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

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. Risk monitoring is part of risk control, not risk analysis
b) Is not correct. Risk identification itself does not allow us to implement risk mitigation activities. The mitigating actions are defined during the risk control phase
c) Is correct. This is an example of how risk analysis influences the thoroughness and scope of testing
d) Is not correct. Coverage items are derived using test techniques, not through risk analysis

Explanation / Rationale

a) Is not correct. The fact that the requirement about the system’s performance comes directly from the client and that the performance is important from the business point of view (i.e., high priority) does not make these tests functional, because they do not check “what” the system does, but “how” (i.e., how fast the orders are processed)
b) Is correct. This is an example of performance testing, a type of non-functional testing
c) Is not correct. From the scenario we do not know if interacting with the user interface is a part of the test conditions. But even if we did, the main test objective of these tests is to check the performance, not the usability
d) Is not correct. We do not need to know the internal structure of the code to perform the performance testing. One can execute performance efficiency tests without structural knowledge

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

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