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

There are three equivalence partitions: {…, –2, –1}, {0, 1, 2}, {3, 4, …}.
For 2-value BVA all the boundary values for all the equivalence partitions must be covered.
The boundary values are –1 (for the “temperature too low” partition), 0, 2 (for the “temperature OK” partition) and 3 (for the “temperature too high” partition).

Thus:
a) Is not correct
b) Is not correct
c) Is correct. The correct option is: –1, 0, 2, 3
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

We want to run test cases according to their priorities, but we also need to consider the dependencies.
If we only consider priorities, we want to first run TC 5 and TC 7 (highest priority), then TC 1, TC 3, and TC 4, and finally TC 2 and TC 6 (lowest priority).
However, in order to run TC 7, we need to first run TC 4.
In order to run TC 5, we need to run TC 4 and TC 2, but TC 2 is blocked by TC 1, which should be run prior to TC 2.
So, in order to run priority 1 test cases as early as possible, the first five test cases should be: TC 4 - TC 7 - TC 1 - TC 2 - TC 5.
Next, we need to run TC 3, because it has higher priority than TC 6.
Thus the full schedule will be TC 4 – TC 7 – TC 1 – TC 2 – TC 5 – TC 3 – TC 6.
So, the sixth test case will be TC 3.

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

Explanation / Rationale

a) Is not correct. Acceptance criteria are the conditions used to decide whether the user story is ready. They cannot show work progress
b) Is not correct. Defect reports inform about the defects. They do not show work progress
c) Is not correct. Test completion report can be created after the iteration is finished, so it will not show the progress continuously within an iteration
d) Is correct. Burndown charts are a graphical representation of work left to do versus time remaining. They are updated daily, so they can continuously show the work progress

Explanation / Rationale

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

Explanation / Rationale

a) Is not correct. Traceability between the mitigated risks and passing test cases provides little information, because to be mitigated (by testing) the risks would need to have a corresponding passing test case. To be able to assess residual risk, traceability between all risks and test results needs to be available, so that the risks that do not have a corresponding passing test can be identified as the residual risks
b) Is correct. Traceability between user requirements and test execution results provides an indication of which user requirements have been tested and so provides a means of measuring project progress (in the context of testing) against business goals
c) Is not correct. It is not clear that failing test cases provide an indication of tester skills any more than passing test cases. It would partly depend on the test objective (e.g., building confidence or causing failures). Also, such measurement of testers based on passing and failing test cases can be counter-productive as it could cause the testers to optimize their testing based on that metric rather than the test objective
d) Is not correct. Traceability between the identified risks and written test conditions provides a means of determining which further test conditions need to be written. Determining which risks are worth testing is part of risk management, and risk mitigation in particular

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

“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 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. This is an example of a risk monitoring activity, not risk analysis
b) Is not correct. This is an example of an architectural decision, not related with testing
c) Is not correct. This is an example of performing a quantitative risk analysis and is not related to thoroughness or scope of testing
d) Is correct. This shows how risk analysis impacts the thoroughness of testing (i.e., the level of detail)

Explanation / Rationale

a) Is not correct. ‘The capability of generating test cases without access to the test basis’ is not possible. The generation of test cases by either testers or tools requires access to the test basis
b) Is not correct. ‘The achievement of increased coverage through more objective assessment’ is not a direct benefit of test automation. Test automation will provide more objective assessment of coverage, however that objective assessment will not increase the coverage. Only by using the results of the coverage to write further test cases can the coverage possibly be increased
c) Is not correct. ‘The increase in test execution times available with higher processing power’ is a contradictory statement as higher processing power would normally reduce execution times, and increased execution times are not a benefit as the testing would take longer
d) Is correct. The prevention of human errors through greater consistency and repeatability is a benefit of test automation as test automation cannot suffer from human errors. For instance, it means that tests are consistently derived from requirements, test data is created in a systematic manner, and tests are executed by a tool in the same order with the same frequency

Explanation / Rationale

a) Is not correct. Traceability is the relationship between two or more work products, not between different versions of the same work product
b) Is not correct. Maintenance testing is about testing changes; it is not related closely to versioning
c) Is correct. To support testing, configuration management may involve the version control of all test items
d) Is not correct. Requirements engineering is the elicitation, documentation, and management of requirements; it is not closely related to test script versioning

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

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. While the sentence is true, it does not provide much value for the developer
b) Is correct. From the test results it seems that the system ignores duplicates and sorts the list disregarding the repetitions. This is probably the cause of failures in TC3, TC4, TC5. Such information may help the developer to find the defect and fix it more efficiently
c) Is not correct. The system does not fail in sorting negative numbers. The problem is rather in disregarding duplicates
d) Is not correct. The test cases TC3, TC4 and TC5 fail, but we aren’t aware that the test cases have any defects

Explanation / Rationale

a) Is correct. The primary benefit of independence in testing is that testers are more likely to identify different types of failures and defects compared to developers, due to their varied backgrounds, technical viewpoints, and potential biases, including cognitive bias. However, the main disadvantage of independence in testing is that testers may become isolated from the development team, leading to communication problems, a lack of collaboration, and potentially an adversarial relationship, with testers being blamed for delays and bottlenecks in the release process
b) Is not correct. A developer’s familiarity with the code does not mean that they rarely find defects in it, instead this familiarity means they can efficiently find many defects in their own code. And, rather than developers and testers having a shared background, developers having a different background to testers is normally cited as the reason that testers and developers find different kinds of defects
c) Is not correct. Testing can be conducted at different levels of independence, ranging from no independence for the author to very high independence for testers from outside the organization. In most projects, multiple levels of independence are utilized, with developers performing component and component integration testing, the test team performing system and system integration testing, and business representatives performing acceptance testing. So, testers can be in the developer’s team and do not need to come from outside the organization. Knowledge of the application domain will change from case-to-case and is not dependent on the level of independence
d) Is not correct. Testing can be conducted at different levels of independence, ranging from no independence for the author to very high independence for testers from outside the organization, with testers from outside the developer’s team generally more independent than testers from within the team. However, there is more reason to believe that testers from outside the team are likely to be more isolated from the developers and so are more likely to be blamed for delays in product release

Explanation / Rationale

a) Is not correct. The fundamental strength of white-box test techniques is that the entire software implementation is taken into account during testing
b) Is not correct. White-box coverage measures provide an objective measure of coverage and provide the necessary information to allow additional tests to be generated to increase this coverage
c) Is not correct. White-box test techniques can be used to perform reviews (static testing)
d) Is correct. This is the weakness of the white-box test techniques. They are not able to identify the missing implementation, because they are based solely on the test object structure, not on the requirements specification

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

Explanation / Rationale

Considering:

• The test basis for acceptance testing is the user’s business needs (1D)
• Communication between components is tested during component integration testing (2B)
• Failures in logic can be found during component testing (3A)
• Business rules are the test basis for system testing (4C)

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

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

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

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. Component testing (also called unit testing) involves testing individual components in isolation and is mostly verification against a specification, rather than validation against user needs. However, this testing is not normally performed by testers, as developers usually carry out this testing in their development environment
b) Is not correct. Component integration testing involves testing the interfaces and interactions between components and is mostly verification against a specification, rather than validation against user needs. However, this testing is not normally performed by testers, as developers usually carry out this testing
c) Is not correct. System integration testing examines the interfaces with other systems and external services and is mostly verification against a specification, rather than validation against user needs. This type of testing is also most often performed by testers
d) Is correct. Acceptance testing focuses on validating that the system meets the user's business needs and is ready for deployment. Ideally, this testing is carried out by the end users

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. Test progress reports are mostly used during test monitoring and control, and test completion, not during test design
b) Is correct. A test completion report is prepared during test completion, when a project, test level, or test type is complete and when, ideally, its exit criteria have been met. This report uses information from test progress reports and other data
c) Is not correct. Test progress reports are mostly used during test monitoring and control, and test completion, not during test analysis
d) Is not correct. Test progress reports are most used during test monitoring and control, and test completion, not during test planning

Explanation / Rationale

a) Is not correct
b) Is not correct
c) Is not correct
d) Is correct. This rule holds for all SDLC models

Explanation / Rationale

a) Is not correct. DevOps generally increases the visibility of non-functional quality characteristics, such as performance and reliability
b) Is not correct. Automated processes like continuous integration/continuous delivery (CI/CD) used in DevOps facilitate stable test environments
c) Is not correct. Automated processes like CI/CD used in DevOps generally reduce the need for manual testing
d) Is correct. DevOps implementation can pose several risks and challenges, including the need to define and set up the delivery pipeline, introduce and maintain CI/CD tools, and establish and maintain test automation

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. Testers should review work products as soon as drafts are available to enable early testing as part of a shift-left approach. If they waited until the next development phase, then unnecessary development (and test) work could be started on unreviewed, flawed work products
b) Is correct. Testers should review work products as soon as drafts are available to enable early testing as part of a shift-left approach
c) Is not correct. Testers typically review work products that form the test basis as part of test analysis, not before test analysis and design
d) Is not correct. Testers should review work products as soon as drafts are available to enable early testing as part of a shift-left approach. Waiting until they are published means that any defects that could be found by tester review will be in the published document

Explanation / Rationale

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

Explanation / Rationale

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. Test monitoring involves the ongoing checking of all activities and comparison of actual progress against the test plan. Test control involves taking the actions necessary to meet the test objectives of the test plan. No test data are prepared during these activities
b) Is not correct. Test analysis includes analyzing the test basis to identify test conditions and prioritize them. Test design includes elaborating the test conditions into test cases and other testware. Test data are not prepared during these activities
c) Is correct. Test implementation includes creating or acquiring the testware necessary for test execution (e.g., test data)
d) Is not correct. Test completion activities occur at project milestones (e.g., release, end of iteration, test level completion), so it is too late for preparing test data

Explanation / Rationale

i. Is true. Having domain knowledge is an important tester skill
ii. Is false. This is a task of the business analyst together with the business representative
iii. Is true. Being a good team player is an important skill
iv. Is false. Planning and organizing the work of the team is a task of the test manager or, mostly in an Agile software development project, the whole team and not just the tester
v. Is true. Critical thinking is one of the most important skills of testers

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

Explanation / Rationale

The average development effort is $900,000 and the average test effort is $90,000 (calculated from the four projects).
The average test-to-development effort ratio is 1:10 ($90,000 : $900,000), which means that historically, on average, the test effort is 10% of the development effort.
So if the development effort is estimated to be $800,000, the estimated test effort is estimated as:

10% * $800,000 = 0.1 * $800,000 = $80,000.

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

Explanation / Rationale

Considering each of the listed test activities and their output testware:

A. Test analysis - prioritized test conditions (4) (e.g., acceptance criteria), and defect reports for defects identified in the test basis
B. Test design - prioritized test cases, test charters, coverage items (1), test data requirements, and test environment requirements
C. Test implementation - test procedures, automated test scripts, test suites, test data, test execution schedule (3), and test environment elements such as stubs, drivers, simulators, and service virtualizations
D. Test completion - test completion report, documented lessons learned, action items for improvement, and change requests (2) (as product backlog items)

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

Explanation / Rationale

a) Is not correct. The rule-oriented format includes formats like bullet point verification lists or tabulated forms of input-output mappings, explicitly showing the rules to be followed. Given/When/Then is a scenario-oriented format because it describes a scenario to be verified
b) Is correct. This is a Given/When/Then format, which is scenario-oriented
c) Is not correct. There no "product-oriented" format of acceptance criteria
d) Is not correct. There is no "process-oriented" format of acceptance criteria

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