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

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

Explanation / Rationale

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

Explanation / Rationale

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

Explanation / Rationale

a) Is not correct. 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. One of the purposes of retrospectives is to identify potential process improvements, which, if put into practice, should result in the quality of future outputs of the development process (test objects) being higher. So, this is likely to occur as a result of a retrospective
b) Is not correct. A benefit of retrospectives for testing includes increased test efficiency through process improvements. So, this is likely to occur as a result of a retrospective
c) Is correct. Participants at retrospectives typically include testers, developers, architects, product owners, and business analysts, but end users are rarely invited or attend these meetings – and they are also unlikely to receive any reports from these meetings. So, it is very unlikely that they will learn and understand more about the development and test processes through retrospectives
d) Is not correct. A benefit of retrospectives for testing includes improved quality of testware (including automated test scripts) through joint reviews with developers. So, this is likely to occur as a result of a retrospective

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. This principle means that if the same tests are repeated over and over again, eventually these tests no longer find any new defects. This is probably why the tests all passed in this release as well
b) Is not correct. This principle says about the mistaken belief that just finding and fixing a large number of defects will ensure the success of a system
c) Is not correct. This principle says that a small number of components usually contain most of the defects
d) Is not correct. This principle states that testing all combinations of inputs and preconditions is not feasible

Explanation / Rationale

TC1 achieves the highest coverage (4/7 – Req1, Req3, Req4 and Req7), so should be executed first.
Req2, Req5 and Req6 are still not covered.
The next test case that achieves the highest additional coverage of the remaining requirements is TC3, covering 2 out of these 3 requirements (Req5 and Req6). So, TC3 should be executed as the second one.
Now the only requirement still not covered is Req2, which is covered by TC4. Therefore, TC4 should be executed as the third test case.
So, the last test case executed will be TC2.

Thus:
a) Is not correct
b) Is 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. We do not accept the risk; concrete actions are proposed
b) Is not correct. No contingency plans are proposed
c) Is correct. The proposed actions are related to testing, which is a form of risk mitigation
d) Is not correct. Risk is not transferred but mitigated

Explanation / Rationale

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

Explanation / Rationale

a) Is not correct. 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. Dynamic testing does cause failures (from which defects can then be located and fixed). However, debugging is concerned with locating defects and fixing these defects. Therefore, debugging does not fix failures
b) Is not correct. Both testing and debugging contribute to improving the quality of the test object, so should really both be considered positively. Debugging is generally considered to be a positive activity as it is fixing something. Dynamic testing does involve intentionally causing the test object to fail, which is why some people consider it a negative activity, but that is a very narrow view (and not one typically held by testers). Both positive and negative test cases are possible. Positive test cases check that the test object correctly performs what it is supposed to do, while negative testing checks that the test object does not do what it is not supposed to do
c) Is correct. Testing determines that defects exist either directly through observation of the defect in reviews (or by a tool in static analysis), or indirectly by causing a failure in dynamic testing. Debugging is a separate activity from testing (normally performed by developers) and is concerned with locating defects (only for dynamic testing) and fixing the defects
d) Is not correct. The causes of defects are typically human errors. Testing finds defects either directly through static testing, or indirectly by causing failures in dynamic testing, and debugging fixes defects. So, testing does not find the cause of defects and debugging does not fix the causes of defects

Explanation / Rationale

Considering each of the listed task descriptions:

1. The quality characteristics to be evaluated and the exit criteria are selected - (Planning (C): Defining the review scope, purpose, work product to be reviewed, quality characteristics to be evaluated, areas of focus, exit criteria, supporting information such as standards, effort, and timeframes.)
2. Everyone has access to the work product - (Review initiation (B): Ensuring all participants have access to the work product and necessary resources, and clarifying their roles and responsibilities.)
3. Anomalies are identified in the work product - (Individual review (A): Evaluating the work product's quality, identifying and logging anomalies, recommendations, and questions using review techniques like checklist-based and scenario-based reviewing.)
4. Anomalies are analyzed and discussed - (Communication and analysis (D): Analyzing and discussing each anomaly, determining its status, ownership, and required actions, and making review decisions, normally in a meeting. This could include determining the need for a follow-up review.)

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

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. We want to check that Special users have the rights of Regular users, so we need to test access rights for a Special user, not for a Regular user
b) Is not correct. We want to check that Special users have the rights of Regular users, so we need to test access rights for a Special user, not for a Regular user
c) Is not correct. There is no floor 5 described in the acceptance criteria. The test cases should not extend the scope of the user story. But even if we would like to perform negative testing, this test is not directly related to AC3
d) Is correct. This way we can check if a Special user can access floors which are accessible to a Regular user

Explanation / Rationale

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

Explanation / Rationale

a) Is not correct. 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 correct. 19 covers the “no discount” partition, 20 covers the “50% discount” partition, and 30 covers the “10% discount” partition. These three values cover all three of the valid equivalence partitions
b) Is not correct. 11 and 12 cover the “no discount” partition, while 20 covers the “50% discount” partition, so covering two of the three valid equivalence partitions
c) Is not correct. 1 covers the “no discount” partition, while 10 and 50 cover the “10% discount” partition. The “50% discount” partition is not covered, so overall two of the three valid equivalence partitions are covered
d) Is not correct. 29 and 31 cover the “no discount” partition, while 10 and 30 cover the “10% discount” partition. The “50% discount” partition is not covered, so overall two of the three valid equivalence partitions are covered

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

Using the three-point estimation technique, the final estimate (E) is calculated as:

E = (a + 4*m + b) / 6,

where a is the most optimistic estimate, m is the most likely estimate, and b is the most pessimistic estimate.

Thus:
a) Is correct. In this case, the estimate for executing a single test case is:

E = (1h + 4*3h + 8h) / 6 = 3.5 hours

So, the total time needed for the tester to execute 4 test cases is:

3.5h * 4 = 14 hours

b) Is not correct
c) Is not correct
d) Is not correct

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. In most cases both black-box test techniques and experience-based test techniques can be used for the same test objects
b) Is not correct. Both black-box test techniques and experience-based test techniques can be used at all test levels
c) Is correct. Black-box test techniques (also known as specification-based techniques) are based on an analysis of the specified behavior of the test object without reference to its internal structure. So, the test basis is usually a specification. Experience-based test techniques effectively use the knowledge and experience of testers for the design and implementation of test cases. This means that the tester, when designing tests, may not use the specification at all
d) Is not correct. Experience-based test techniques can detect defects that may be missed using black-box (and white-box) test techniques. Hence, experience-based test techniques are complementary to black-box test techniques and white-box test techniques and both black-box test techniques and experience-based test techniques can be used in all SDLCs

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

Because TC1 and TC3 failed in Execution 1 (i.e., test (1) and test (3)), test (4) and test (6) are confirmation tests.
Because TC2 and TC3 failed in Execution 2 (i.e., tests (5) and (6)), test (8) and test (9) are also confirmation tests.
TC2 passed in Execution 1 (i.e., test (2)), so test (5) is a regression test.
TC1 passed in the Execution 2 (i.e., test (4)), so test (7) is also a regression test.
Thus:
a) Is not correct
b) Is correct
c) Is not correct
d) Is not 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 test pyramid emphasizes having a larger number of tests at the lower test levels
b) Is correct. It is not true that near the top of pyramid, test automation should be more formal
c) Is not correct. Usually component testing and component integration testing are automated using API-based tools
d) Is not correct. For system testing and acceptance testing, the automated tests are typically created using GUI-based tools

Explanation / Rationale

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

Explanation / Rationale

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

In the three-point estimation technique:

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

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

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

Explanation / Rationale

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

Explanation / Rationale

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

Explanation / Rationale

a) Is 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

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

Explanation / Rationale

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