ISTQB Foundation (CTFL v4.0) Mock Exam #7 — Questions & Answers
Every question in this mock exam, with the correct answer marked and a written rationale behind each option below — for reading and review, not a timed run.
A test team reports: "All planned tests passed." A manager concludes the software has no defects. Which testing principle shows this conclusion is flawed?
Testing shows the presence of defects, not their absence.
Correct — passing tests cannot prove the absence of all defects.
Exhaustive testing is impossible.
True as a principle, but it addresses test effort, not the false 'no defects' conclusion.
Tests wear out (the pesticide paradox).
This concerns repeating the same tests, not proving absence of defects.
Defects cluster together.
Describes uneven defect distribution, not the limits of passing tests.
Testing can show that defects are present but cannot prove their absence; passing tests reduce risk but do not guarantee a defect-free product.
A developer misreads a requirement and writes the wrong discount formula. The code ships; a user later sees an incorrect total on screen. In ISTQB terms, what is the incorrect total the user sees?
A failure.
Correct — a failure is the manifestation of a defect during execution.
An error.
The error was the developer misreading the requirement, not the on-screen result.
A defect.
The defect is the wrong formula in the code; the visible wrong total is its effect.
A root cause.
The root cause is the underlying reason for the error, not the visible result.
The mistake (misreading) is an error; the wrong formula in the code is a defect; the visible wrong total during execution is a failure.
Which of the following is a typical objective of testing?
Providing information to stakeholders to support decisions.
Correct — a core objective of testing is to inform decisions about quality and risk.
Guaranteeing the product is completely defect-free.
Impossible — testing cannot prove the absence of defects.
Replacing the need for requirements reviews.
Dynamic testing complements but does not replace static reviews.
Assigning blame for defects to developers.
Testing is not about blame; psychology of testing favours constructive communication.
Typical objectives include preventing defects, finding defects, building confidence, providing information for decisions, and verifying/validating against requirements.
During a project, 80% of the defects are found in two of the ten modules. The test manager decides to focus extra testing on those two modules. Which testing principle supports this decision?
Defects cluster together.
Correct — most defects are concentrated in a few modules.
Early testing saves time and money.
True principle, but it is about timing, not where defects concentrate.
Testing is context dependent.
Relevant in general, but does not explain focusing on high-defect modules.
The absence-of-defects fallacy.
This warns that a defect-free system may still fail to meet needs; not about clustering.
Defect clustering: a small number of modules usually contains most of the defects, so focusing effort there is effective.
Which TWO of the following are part of the test process activity 'test analysis'? (Select TWO.)
Analysing the test basis to identify testable features.
Correct — a core part of test analysis.
Defining and prioritising test conditions.
Correct — test conditions are an output of test analysis.
Designing and prioritising concrete test cases.
That belongs to test design, not test analysis.
Executing test cases and logging results.
That is test execution, a later activity.
Setting up the test environment and test data.
That is part of test implementation.
Test analysis determines 'what to test' by analysing the test basis to identify testable features and define/prioritise test conditions.
Which statement BEST describes the difference between testing and quality assurance (QA)?
QA is process-oriented (preventing defects); testing is product-oriented (finding defects).
Correct — this captures the standard distinction.
Testing and QA are synonyms used interchangeably.
They are related but distinct disciplines.
Testing is process-oriented; QA only finds defects in code.
This reverses the correct definitions.
QA is performed only after release; testing only before release.
Both QA and testing occur throughout the lifecycle.
QA is process-oriented and focuses on preventing defects by improving processes; testing is product-oriented and focuses on finding defects in work products.
A tester and a developer disagree about whether a reported behaviour is a defect. Applying the psychology of testing, what is the MOST constructive approach?
Communicate findings neutrally and objectively, focusing on facts and the expected vs actual result.
Correct — neutral, fact-based communication reduces conflict.
Escalate immediately to management to assign responsibility.
Premature escalation harms collaboration; discuss facts first.
Close the report as 'not a defect' to avoid conflict.
Suppressing valid information harms product quality.
Insist the developer is wrong because testers own quality.
Quality is a shared responsibility; an adversarial stance is counterproductive.
Defect information should be communicated neutrally and factually to avoid friction and keep the focus on improving the product, not blaming people.
A team tests release 3.2 of a payment component, and uses the requirements specification to derive the tests. In ISTQB terminology, which term names the release 3.2 payment component itself?
The test object
Correct — the test object is the component, system or other work product that is being tested.
The test basis
The test basis is the body of knowledge used as the basis for test analysis and design. In this scenario that role is played by the requirements specification, not by the component.
The test condition
A test condition is a testable aspect of the test object derived from the test basis, for example 'rejects a negative payment amount'. It describes an aspect, not the object.
The test environment
The test environment is the hardware, software, configuration and data in which the test object is executed. It surrounds the object rather than being it.
The test object is the work product to be tested — here the release 3.2 payment component. The requirements specification is the test basis used to derive the tests.
A team follows a sequential (V-model) lifecycle. According to the principle of early testing, what should happen to the acceptance tests for a requirement?
They can be designed as soon as the requirements are available.
Correct — early test design helps find requirement defects sooner.
They must wait until all code is integrated.
Waiting contradicts early testing; design can start with the requirements.
They are unnecessary in a V-model.
Acceptance testing is an explicit level in the V-model.
They should be written only by developers.
Acceptance tests typically involve users/business, not only developers.
In the V-model, each development level has a corresponding test level; test design (e.g. acceptance test design) starts as soon as the corresponding basis (requirements) is available.
A change is made to the tax calculation module. The team re-runs the existing tax tests that previously passed, to ensure the change did not break them. What type of testing is this?
Regression testing.
Correct — re-running passing tests after a change to detect side effects is regression testing.
Confirmation testing.
Confirmation testing verifies a specific defect fix, not unchanged areas.
Smoke testing.
Smoke testing is a broad shallow check of basic functionality, not targeted regression.
Acceptance testing.
Acceptance testing validates fitness for use by users, not re-running unit-level tax tests.
Regression testing re-runs previously passing tests after a change to detect unintended side effects; confirmation (re-)testing checks that a specific fixed defect is gone.
Which test level focuses on the interfaces and interactions between integrated components or systems?
Integration testing.
Correct — it targets interfaces and interactions between integrated parts.
Component testing.
Component (unit) testing checks a single component in isolation.
System testing.
System testing evaluates the behaviour of the whole system, not specifically interfaces.
Acceptance testing.
Acceptance testing establishes confidence and readiness for use, not interface focus.
Integration testing focuses on interfaces and interactions; component integration tests interactions between components, system integration tests interactions between systems.
Which TWO of the following are common forms of acceptance testing? (Select TWO.)
Operational acceptance testing (OAT).
Correct — OAT checks operational aspects such as backup/restore and maintenance.
Beta testing.
Correct — beta testing is a form of acceptance testing performed by real users in their environment.
Branch coverage testing.
Branch coverage is a white-box coverage measure, not a form of acceptance testing.
Component integration testing.
That is an integration test level, not acceptance testing.
Statement coverage testing.
Statement coverage is a structural measure, not an acceptance form.
Common forms of acceptance testing include user acceptance testing (UAT), operational acceptance testing (OAT), contractual/regulatory acceptance testing, and alpha/beta testing.
A bank adds a new 'instant payment' feature and must verify it complies with national payment regulations before release. Which test type is MOST directly addressed?
Functional testing.
Correct — verifying the feature does what regulations require is functional testing.
Performance efficiency testing.
That is a non-functional characteristic about speed/resources, not regulatory correctness.
Portability testing.
Portability concerns moving software between environments, unrelated here.
Maintainability testing.
Maintainability is about ease of modification, not regulatory behaviour.
Functional testing checks 'what' the system does against functional requirements; compliance with regulations about what the feature must do is verified through functional (and possibly compliance-specific) testing.
In a shift-left approach, which action BEST illustrates the concept?
Reviewing requirements and writing tests before the code is developed.
Correct — moving testing activities earlier is the essence of shift left.
Running all tests only after the system is fully built.
That is the opposite of shift left.
Adding more testers to the final acceptance phase.
Adding effort late does not move activities earlier.
Deferring test design until after deployment.
Deferring testing is a shift-right/late activity, not shift left.
Shift left means performing testing activities earlier, e.g. reviewing requirements, writing tests before code (TDD), and involving testers from the start.
Which of the following is a key benefit of static testing compared with dynamic testing?
It can find defects earlier and in work products that cannot be executed.
Correct — static testing detects defects in requirements/design before code exists.
It measures actual performance under load.
Performance under load requires dynamic execution.
It confirms the system behaves correctly at runtime.
Runtime behaviour can only be observed via dynamic testing.
It always replaces the need for dynamic testing.
Static and dynamic testing are complementary, not substitutes.
Static testing examines work products without executing code, so it can find defects (including in requirements/design) earlier and in artifacts that cannot be executed.
During a review, the moderator schedules and runs the meeting, while another participant focuses on detecting defects using checklists. Which role is the second participant playing?
Reviewer.
Correct — reviewers examine the work product and identify defects.
Scribe.
The scribe records the defects/issues raised; they do not primarily find them.
Author.
The author created the work product under review.
Facilitator (moderator).
That is the first participant, who runs the meeting.
In a formal review, the author owns the work product, the facilitator/moderator runs the review, the scribe records issues, the reviewers find defects, and the review leader/manager takes overall responsibility.
Which TWO of the following are typically found MORE effectively by static testing than by dynamic testing? (Select TWO.)
Ambiguities and contradictions in requirements.
Correct — reviews catch requirement defects before any code exists.
Unreachable (dead) code.
Correct — static analysis detects code that can never be executed.
Response time degradation under heavy load.
Performance under load requires dynamic execution.
Memory leaks that appear only at runtime.
Runtime memory behaviour is observed via dynamic testing.
Incorrect results produced by a calculation at runtime.
Observing wrong calculated output requires executing the code.
Static testing is effective at finding requirement defects, design defects, deviations from standards, maintainability issues, and dead/unreachable code that dynamic testing may miss.
Which review type is characterised by being the MOST formal, led by a trained moderator, using defined entry/exit criteria, individual preparation and metrics?
Inspection.
Correct — inspection is the most formal review type.
Informal review.
An informal review has no formal process or documented results.
Walkthrough.
A walkthrough is led by the author and is less formal than an inspection.
Technical review.
A technical review is formal but typically less rigorous and metric-driven than an inspection.
An inspection is the most formal review type, with a trained moderator, formal process, entry/exit criteria, defined roles, individual preparation and collection of metrics.
For the support-ticket state machine below, how many test cases are required for 0-switch coverage (every valid single transition exactly once)?
6
New->Open, Open->InProgress, InProgress->Resolved, Resolved->Closed, Resolved->InProgress, Closed->Open.
4
Misses the reject/reopen and Closed->Open transitions.
5
Undercounts by one transition.
7
Over-counts; there are exactly six transitions.
There are six transitions: triage, assign, resolve, close, reject/reopen (Resolved->InProgress), reopen (Closed->Open).
An input field 'age' accepts integer values from 18 to 65 inclusive as valid; values outside this range are invalid. Using equivalence partitioning, which set of values represents one valid and the two invalid partitions with a single representative each?
10, 40, 80
Correct — 10 (invalid low), 40 (valid), 80 (invalid high): one per partition.
20, 40, 60
All three lie inside the valid partition, so the invalid partitions are not covered.
17, 18, 65
These are boundary values (BVA), not single representatives of three partitions.
5, 12, 16
All three are in the invalid-low partition; valid and invalid-high are missing.
Equivalence partitioning groups inputs into valid (18–65) and invalid (≤17 and ≥66) partitions; one representative per partition is enough.
A loyalty system awards points based on the annual spend of a customer. The rules are: spend from 0 up to 999 earns Bronze; spend from 1000 up to 4999 earns Silver; spend of 5000 or more earns Gold. Spend is a whole number of euros. Using two-value boundary value analysis (BVA) on the spend input, how many distinct boundary values must be tested to cover the boundaries between all three tiers?
4 (999, 1000, 4999, 5000)
Correct — two internal tier boundaries, each tested with two values.
2 (1000, 5000)
Two-value BVA also tests the value just below each boundary (999 and 4999).
6 (0, 999, 1000, 4999, 5000, 9999)
0 and an arbitrary high value are not internal boundaries between the three tiers.
3 (999, 1000, 5000)
This omits 4999, the lower side of the second boundary.
Two-value BVA tests each boundary and the value just on the other side. Boundaries between tiers are at 999/1000 and 4999/5000. That gives the values 999, 1000, 4999, 5000 — four distinct boundary values (the outer edges 0 and the open upper end are not internal tier boundaries).
A car insurer applies discount rules per the decision table below. A 40-year-old driver who has had no claims in the last 5 years holds only one policy with the insurer (i.e. multi-policy = False). Which rule applies, and what is the resulting action?
R7 — apply the 10% discount.
Correct — T, T, F matches R7, whose action is the 10% discount.
R8 — apply the 10% discount.
R8 requires multi-policy = T; here multi-policy is F.
R5 — apply the premium tier.
R5 requires no claims = F; here the driver has no claims (T).
R3 — apply the premium tier.
R3 requires Age>=25 = F; here the driver is 40 (T).
Age 40 → Age>=25 = T; no claims in 5 years = T; single policy → Multi-policy = F. The column with T, T, F is R7, whose action is '10% discount' (Premium tier is not applied).
The state machine below models a login screen. After 3 invalid attempts the account is Locked; it returns to Idle only after a 30-minute reset. Using the diagram, what is the minimum number of test cases needed to achieve 100% valid transition coverage (0-switch), where each test case is a path that starts at the start state?
2
Correct — two start-rooted paths cover all five valid transitions.
1
A single path cannot include both 'valid login' (ends in LoggedIn) and 'reset' (needs Locked).
4
Four is more than the minimum; two well-chosen paths already cover all transitions.
5
Five equals the transition count, but a single test case covers several transitions in one path.
There are 5 transitions: enterCredentials, the invalid self-loop, 3rd invalid, valid login, and reset. One path (Idle→Entering, invalid, invalid, 3rd invalid→Locked, reset→Idle) covers four of them; a second path (Idle→Entering, valid login→LoggedIn) covers the valid-login transition. So 2 test cases suffice.
What is the difference between 0-switch (all transitions) coverage and 1-switch coverage in state transition testing?
0-switch covers single transitions; 1-switch covers every valid sequence of two consecutive transitions.
Correct — 1-switch covers transition pairs, increasing thoroughness.
0-switch covers only valid states; 1-switch covers only invalid states.
Switch coverage is about transitions/sequences, not valid vs invalid states.
0-switch covers all states once; 1-switch covers all states twice.
Switch coverage counts transitions, not how many times states are visited.
There is no difference; the terms are synonyms.
They define different coverage levels.
0-switch coverage exercises every single valid transition once; 1-switch coverage exercises every valid pair of consecutive transitions (sequences of two transitions).
Which TWO statements about decision table testing are correct? (Select TWO.)
Full decision table coverage requires at least one test case for each achievable rule (column).
Correct — each feasible rule should be exercised at least once.
Decision tables are especially useful when several conditions combine to determine an outcome.
Correct — they systematically capture interacting conditions and actions.
A decision table can only contain a single condition.
Decision tables are designed to handle multiple conditions.
Decision table testing guarantees 100% code branch coverage.
It is a black-box technique and does not guarantee structural code coverage.
Decision tables are a white-box technique based on the code structure.
They are a black-box technique based on specifications, not code.
Decision tables model combinations of conditions and their resulting actions; full coverage requires at least one test case per achievable rule (column). They are well-suited to business rules with interacting conditions.
A team wants to verify that an experienced user can complete a complex workflow using their own knowledge and intuition, without predefined test cases, exploring the application and learning as they go. Which approach is being described?
Exploratory testing.
Correct — design, execution and learning happen together, without predefined scripts.
Boundary value analysis.
BVA is a specification-based technique using predefined boundary values.
Statement testing.
Statement testing is a white-box technique based on code coverage.
Checklist-based testing.
Checklist-based testing follows a predefined list of checks, unlike free exploration.
Exploratory testing is an experience-based approach where the tester simultaneously designs, executes and learns, often without predefined scripts.
Consider this pseudocode: line 1 read x; line 2 if x > 0 then line 3 y = x * 2; line 4 end if; line 5 print y. A single test with x = 5 is executed. What statement coverage does this one test achieve (counting executable statements on lines 1, 3 and 5, plus the decision on line 2)?
100% statement coverage (but only 50% branch coverage).
Correct — all statements run, but only the true branch is exercised.
50% statement coverage.
All three executable statements are executed, so statement coverage is 100%, not 50%.
100% statement and 100% branch coverage.
The false branch (x ≤ 0) is never taken, so branch coverage is not 100%.
75% statement coverage.
There is no partial statement here; every executable statement runs, giving 100%.
With x = 5 the decision is true, so all executable statements (read x, y = x*2, print y) are executed. That is 100% statement coverage. However, the false branch of the decision is not taken, so branch/decision coverage is only 50%.
Which statement about the relationship between statement coverage and branch (decision) coverage is correct?
100% branch coverage implies 100% statement coverage, but not the reverse.
Correct — branch coverage subsumes statement coverage.
100% statement coverage implies 100% branch coverage.
Statements can all run without exercising every branch outcome.
They are always equal for any program.
They differ whenever a decision has an untaken outcome.
Neither implies the other.
Branch coverage does imply statement coverage; the relationship is one-directional.
Achieving 100% branch coverage guarantees 100% statement coverage, but not vice versa; branch coverage is stronger because it also requires every decision outcome to be exercised.
A function contains exactly two independent simple decisions (two separate if statements, each with a true and a false outcome, and no nesting). What is the minimum number of test cases required to achieve 100% branch (decision) coverage?
2
Correct — (T,T) and (F,F) cover both outcomes of both decisions.
4
Four would be needed only for full combination (e.g. condition/multiple condition coverage), not basic branch coverage.
1
One test cannot take both the true and false outcome of a decision.
3
Three is more than necessary; two runs already cover all four outcomes.
Each simple decision needs both its true and false outcomes covered. Two independent decisions can be combined within the same test runs: test 1 takes (true, true) and test 2 takes (false, false), covering all four outcomes. So 2 test cases suffice.
Which of the following is typically documented in a test plan?
The test scope, objectives, approach, schedule and entry/exit criteria.
Correct — these are core contents of a test plan.
The full source code of the system under test.
Source code belongs in the codebase, not the test plan.
The marketing budget for the product launch.
Marketing budgets are unrelated to test planning.
The personal performance reviews of the developers.
Personnel appraisals are not part of a test plan.
A test plan describes the scope, objectives, approach, resources, schedule, and entry/exit criteria for testing; it is the bridge between the test strategy and the work to be done.
A test lead estimates the effort to test a feature using the three-point (PERT) technique. The optimistic estimate is 4 days, the most likely estimate is 10 days, and the pessimistic estimate is 22 days. Using the formula E = (a + 4m + b) / 6, what is the estimated effort?
11 days
Correct — (4 + 40 + 22) / 6 = 66 / 6 = 11.
12 days
This is the simple average of 4, 10 and 22; PERT weights the most likely value by 4.
10 days
10 is only the most likely value, not the weighted PERT estimate.
13 days
Recompute: (4 + 40 + 22)/6 = 11, not 13.
E = (4 + 4*10 + 22) / 6 = (4 + 40 + 22) / 6 = 66 / 6 = 11 days.
A project manager is concerned that a key test environment may not be delivered by the vendor on time. In risk-based testing terms, how is this risk classified?
A project risk.
Correct — delayed environment delivery is about project control, a project risk.
A product risk.
Product risk concerns the product failing to meet needs, not vendor delays.
A residual defect.
A residual defect is a known defect remaining after testing, not a risk about delivery.
A failure.
A failure is an observed incorrect behaviour during execution, not a planning risk.
A project risk relates to the management and control of the project (e.g. resources, environments, schedules, suppliers). A product risk relates to the possibility that the product fails to satisfy needs.
Which TWO of the following are examples of PROJECT risks? (Select TWO.)
A shortage of testers with the required skills.
Correct — staffing/skills issues are project risks.
A delay in the supplier delivering a critical component.
Correct — supplier delays threaten project delivery, a project risk.
The payment module may calculate totals incorrectly.
This is a product risk — it concerns the product's correctness.
The application may respond too slowly under peak load.
This is a product risk about performance, not a project risk.
Sensitive data may be exposed due to a security flaw.
This is a product (quality) risk about security, not a project risk.
Project risks affect the project's ability to deliver: staffing/skills shortages, organisational issues, supplier delays, environment availability. Product risks are about the product itself (e.g. wrong calculations, poor performance, security holes).
A team has four product risks with the following risk levels (likelihood × impact): R1 = low × high, R2 = high × high, R3 = high × low, R4 = low × low. There is only time to test thoroughly two of these areas first. According to risk-based testing, which two areas should receive the deepest, earliest testing?
R2 and R3 (the two with a 'high' factor and the highest overall risk), before R1 and R4.
Correct — R2 is highest; R3 (high×low) combined risk is selected next, with R4 (low×low) clearly last.
R1 and R4, because they are simpler to test.
Ease of testing is not the basis of risk-based prioritisation; R4 is the lowest risk.
R3 and R4, because both have high likelihood.
R4 has low likelihood and low impact — it is the lowest risk, not a priority.
All four equally, ignoring the risk levels.
Treating all risks equally contradicts the purpose of risk-based testing.
Risk-based testing prioritises the highest combined risk (likelihood × impact). R2 (high × high) is clearly highest. Between the remaining, R1 (low × high) and R3 (high × low) outrank R4 (low × low); a single high-impact factor usually warrants earlier, deeper testing than two low factors, so R2 plus the next-highest are chosen first — here R2 and either R1 or R3 over R4. The pair that must come first is the two with the greatest risk: R2 and R3/R1; R4 is clearly last.
Which of the following is the BEST example of an exit criterion (criterion for stopping testing) for a test level?
All planned tests have been executed and no high-priority defects remain open.
Correct — this defines when testing can be considered complete.
The test environment is set up and the build is installed.
That is an entry criterion (precondition to start), not an exit criterion.
The requirements have been reviewed and approved.
This is a typical entry criterion, not a stopping criterion.
Test data is available to begin execution.
Availability of test data is an entry condition for starting tests.
Exit (completion) criteria define when a test activity can stop, e.g. coverage targets reached, no open high-priority defects, planned tests executed. Entry criteria define preconditions to start.
Which of the following information is ESSENTIAL in a good defect report to make it reproducible?
Clear steps to reproduce, with expected and actual results.
Correct — reproduction steps plus expected vs actual are essential for reproducibility.
The name of the developer to blame for the defect.
Assigning blame is counterproductive and not part of a good defect report.
The total number of test cases in the project.
Project-wide counts do not help reproduce a specific defect.
The marketing release date of the product.
Release dates are unrelated to reproducing a defect.
A useful defect report includes steps to reproduce, expected vs actual results, environment/configuration, and severity/priority — enough for someone else to reproduce and assess the defect.
Test progress is behind schedule. Which TWO of the following are appropriate test control actions? (Select TWO.)
Re-prioritise the remaining tests so the highest-risk areas are covered first.
Correct — re-prioritising by risk is a standard control action.
Reallocate resources or adjust the schedule and report the impact to stakeholders.
Correct — adjusting resources/schedule and informing stakeholders is valid control.
Stop logging defects so the metrics look better.
Suppressing defect data is dishonest and harms quality decisions.
Mark all open defects as 'fixed' without verification.
Falsifying defect status is unethical and undermines test integrity.
Stop reporting status to management until testing is finished.
Withholding status removes the visibility needed for control decisions.
Test control re-directs testing to meet objectives, e.g. re-prioritising tests by risk, reallocating resources, adjusting the schedule, or tightening/relaxing entry-exit criteria. Hiding defects or skipping all reporting are not valid control actions.
Why is configuration management important for testing?
It ensures test items and testware are uniquely identified and version-controlled, so results are reproducible.
Correct — traceable, versioned items make test results reproducible and trustworthy.
It guarantees the software contains no defects.
Configuration management controls versions; it does not remove defects.
It replaces the need for a test plan.
Configuration management complements, but does not replace, planning.
It automatically executes all the regression tests.
Test execution is done by people or test-execution tools, not configuration management.
Configuration management ensures that all test items (testware, software versions, environments, data) are uniquely identified, version-controlled and traceable, so test results are reproducible and refer to known versions.
A team plans to introduce a test automation tool. Which of the following is a realistic RISK (rather than a benefit) of adopting such a tool?
The effort to maintain the automated test scripts may be underestimated.
Correct — maintenance effort is a well-known risk of test automation.
Repetitive manual work can be reduced.
That is a benefit of tool support, not a risk.
More objective assessment (e.g. coverage measurement) becomes possible.
That is a benefit, not a risk.
Easier access to information about tests and testing.
Improved access to information is a benefit of tool support.
Risks of tool adoption include unrealistic expectations, underestimating effort to maintain test scripts, over-reliance on the tool, and the cost of introducing and maintaining it. Benefits include reduced repetitive work and more objective assessment.
Which TWO of the following are examples of tools that support test execution and logging or test management? (Select TWO.)
A unit-test/automation framework that runs tests and records pass/fail results.
Correct — this is a test execution and logging tool.
A test management tool that stores test cases, runs and traceability to requirements.
Correct — a test management tool supports organising and tracking testing.
A general-purpose word processor.
A word processor is not a dedicated test tool.
A language compiler used to build the application.
A compiler builds software; it is not a test tool.
A spreadsheet used for personal budgeting.
A personal budgeting spreadsheet has no role in test execution or management.
Tool categories include test management tools, static analysis tools, test execution tools (e.g. unit-test/automation frameworks), performance testing tools, and defect management tools. A compiler and a word processor are general-purpose tools, not test tools.