ISTQB Foundation (CTFL v4.0) Mock Exam #9 — 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 developer writes code that calculates a delivery date. The developer mistyped a '+' as a '-' in a formula. As a result, when a customer orders on a Friday, the system shows a delivery date in the past, and the customer complains. Map these three observations to the ISTQB terms error, defect and failure.
Error = the developer's mistyping; defect = the wrong operator in the code; failure = the past delivery date shown to the customer.
Correct mapping: the human mistake is the error, the flawed code is the defect, the observed wrong output is the failure.
Error = the past delivery date; defect = the customer complaint; failure = the mistyping.
Reversed: the date and complaint are consequences (failure), not the error; the mistyping is the error, not the failure.
Error = the wrong operator in the code; defect = the mistyping; failure = the customer complaint.
The wrong operator is the defect, not the error; the mistyping is the error.
All three terms describe the same single event and are interchangeable.
ISTQB deliberately separates the human action, the static flaw and the dynamic manifestation — they are not interchangeable.
An error is a human action that produces an incorrect result; the defect is the resulting flaw in the code; the failure is the externally observed wrong behaviour.
Which statement best describes a key reason why testing is necessary in software development?
Testing reduces the risk of failures occurring in operation and provides information about quality.
A core justification: testing lowers operational risk and informs stakeholders about quality.
Testing guarantees that the software is completely free of defects.
Testing can never prove the absence of defects; this is a well-known fallacy.
Testing replaces the need for requirements and design.
Testing complements, not replaces, requirements and design activities.
Testing is only needed when the customer reports a problem.
Waiting for customer reports defeats the purpose of early defect detection.
Testing reduces the risk of failures in operation and helps verify that requirements are met.
Which statement correctly reflects the testing principle known as the 'pesticide paradox'?
If the same tests are repeated many times, they eventually stop finding new defects, so test cases need to be revised regularly.
Exactly the pesticide paradox: static test sets lose effectiveness and must be updated.
Defects tend to cluster in a small number of modules.
That describes 'defects cluster together', a different principle.
Exhaustive testing of all inputs is achievable with enough resources.
This contradicts 'exhaustive testing is impossible'.
Early testing saves time and money.
True, but that is the 'early testing' principle, not the pesticide paradox.
Repeating the same tests stops finding new defects; tests must be reviewed and revised over time.
Which TWO of the following are valid objectives of testing according to the ISTQB syllabus? (Choose two.)
Evaluating quality and building confidence in the level of quality.
A recognised testing objective in the syllabus.
Finding defects and failures, thereby reducing risk.
Detecting defects to reduce the risk of inadequate quality is a core objective.
Proving that the software contains no defects.
Impossible — testing cannot demonstrate the absence of defects.
Fixing the defects that are found.
Fixing defects is debugging/development work, not a testing objective.
Testing both finds defects and builds confidence in the level of quality; it cannot prove the absence of defects.
During the test process, the team transforms general test objectives into tangible test conditions and then into test cases. Which test activity is concerned primarily with identifying WHAT to test (the test conditions) by analysing the test basis?
Test analysis
Test analysis examines the test basis to determine testable features and define test conditions (what to test).
Test design
Test design elaborates test conditions into concrete test cases (the how), after analysis has defined what.
Test implementation
Implementation organises test cases into procedures/suites and prepares the environment, after design.
Test execution
Execution runs the tests and compares actual with expected results — much later in the process.
Test analysis identifies what to test (test conditions); test design then determines how, producing test cases.
Why is a certain degree of independence often useful when testing software?
Independent testers tend to recognise different defects than the author due to different cognitive biases and assumptions.
Independence reduces author bias and surfaces defects the author may overlook.
Authors are not allowed to test their own code under any circumstances.
Authors can and do test their own work (e.g. unit tests); independence is a matter of degree, not an absolute ban.
Independent testers always find more defects than developers.
Not guaranteed — independence helps but does not always yield more defects.
Independence removes the need for the developers to test at all.
Developer testing remains valuable; independence supplements it, not replaces it.
Independent testers are more likely to recognise different kinds of defects because of different assumptions and biases.
A project manager states: 'We ran all the planned tests and almost all passed, so the system is ready to release and the users will be satisfied.' Which testing principle warns against this reasoning?
The absence-of-errors fallacy.
Finding and fixing defects does not help if the system is unusable or does not meet user needs.
Testing shows the presence of defects, not their absence.
A real principle, but it addresses what passing tests prove, not the fitness-for-use gap raised here.
Defects cluster together.
Concerns the distribution of defects across modules, unrelated to user satisfaction.
Testing is context dependent.
True in general, but it does not specifically warn about equating few defects with user satisfaction.
The absence-of-errors fallacy: a system can be defect-light yet still fail to meet user needs and expectations.
A tester takes several related test cases, puts them into the order in which they must be run, adds the preparation steps that are needed before the first of them starts, and stores the result. In ISTQB terminology, what has the tester created?
A test procedure
Correct — a test procedure is a sequence of test cases in execution order together with the preconditions and preparatory actions they need.
A test case
A single test case specifies preconditions, inputs, expected results and postconditions for one test. Here several existing test cases were sequenced, so something above the level of a test case was produced.
A test suite
A test suite is a set of test cases or test procedures selected to be run together, for example for one test cycle. It groups tests but does not prescribe the internal order and preparation steps that define a procedure.
A test condition
A test condition states what should be tested, such as a feature or quality characteristic. It contains no execution steps and no ordering at all.
A test procedure specifies a sequence of actions for the execution of a test, including the test cases in their execution order and any preconditions or preparatory steps. It is created during test implementation.
A team adopts a 'shift-left' approach. Which of the following BEST illustrates shift-left testing in practice?
Testers review the requirements and define acceptance tests during the analysis phase, before any code is written.
Early review and test design is the essence of shift-left — defects are caught before they propagate.
All testing is postponed until a dedicated test phase after development finishes.
That is the opposite of shift-left — it pushes testing to the right (later).
Testing is performed only in production using monitoring.
Production monitoring is 'shift-right'; it does not move testing earlier.
The number of testers is reduced and developers do less unit testing.
Reducing early testing contradicts shift-left, which increases early test effort.
Shift-left moves test-related activities earlier, e.g. reviewing requirements and writing tests before code is complete.
What is the primary purpose of integration testing as a test level?
To test the interfaces and interactions between integrated components or systems.
Component integration testing targets defects in the interfaces and interactions between components.
To test each individual component in isolation.
That is component (unit) testing, a different level.
To validate the complete system against business requirements with end users.
That describes acceptance testing, not integration testing.
To verify the behaviour of the whole, end-to-end integrated system.
Testing the whole system end-to-end is system testing, the next level up.
Integration testing focuses on interactions and interfaces between components or systems.
A test team measures how quickly the application responds under a load of 500 concurrent users. Which kind of testing is this, and why?
Non-functional testing, because it evaluates a quality characteristic (performance efficiency) rather than a function.
Response time under load is a performance-efficiency (non-functional) quality characteristic.
Functional testing, because the application is performing its calculations.
The focus is on how fast, not on whether the calculation result is correct — that makes it non-functional.
White-box testing, because it relies on the internal code structure.
Measuring response time does not require knowledge of internal structure.
Confirmation testing, because it re-runs a previous test.
Confirmation testing re-tests a fixed defect; this is a fresh performance measurement.
Measuring response time under load is non-functional (performance/efficiency) testing — it tests how well the system behaves, not what it does.
An application that has been in operation for two years must be updated because the operating system it runs on is being upgraded. The functionality is not changing. What type of testing is primarily triggered, and what is the trigger called?
Maintenance testing, triggered by an environmental change (operating system upgrade).
Modifications to the operational environment are a recognised trigger for maintenance testing.
Acceptance testing, triggered by a new business requirement.
There is no new business requirement; functionality is unchanged.
Component testing, triggered by new code being written from scratch.
No new feature code is being written; the system is being migrated.
Smoke testing, triggered by the daily build.
A daily build is not the trigger here; the OS upgrade (a maintenance trigger) is.
This is maintenance testing triggered by a change to the environment (an operational/migration trigger).
Which TWO statements correctly distinguish confirmation testing from regression testing? (Choose two.)
Confirmation testing re-executes the test(s) that previously failed, to verify the fix.
Correct — confirmation testing verifies the original defect is resolved.
Regression testing checks that the change has not introduced or uncovered defects in unchanged parts.
Correct — regression testing looks for unintended side effects of a change.
Confirmation testing is always fully automated, regression testing never is.
Either can be manual or automated; automation is not what distinguishes them.
Regression testing is only done after the software is released to production.
Regression testing is done whenever the software or environment changes, at any level.
Confirmation testing checks that a specific fixed defect is gone; regression testing checks that the change has not broken anything else.
In a DevOps environment with continuous integration (CI), what is a key benefit for testing?
Automated tests run on every integration, giving rapid feedback and enabling early defect detection.
Fast, automated feedback on each commit is a primary testing benefit of CI/DevOps.
CI removes the need for any automated regression tests.
CI relies heavily on automated regression tests; it does not remove them.
CI guarantees that no defects ever reach production.
CI reduces risk but cannot guarantee defect-free releases.
CI means testing is only performed manually at the end of the sprint.
CI emphasises continuous automated testing, not end-of-sprint manual testing.
CI gives fast feedback through automated build-and-test pipelines, so defects are detected soon after code is committed.
Which statement correctly contrasts static testing with dynamic testing?
Static testing finds defects without running the code, while dynamic testing requires executing the software.
Correct — this is the fundamental distinction between the two.
Static testing requires executing the code, dynamic testing does not.
This reverses the definitions.
Both static and dynamic testing always require running the software.
Static testing specifically does not run the software.
Neither static nor dynamic testing can find defects.
Both find defects; they differ in how.
Static testing finds defects directly in work products without executing code; dynamic testing executes the software and observes failures.
Which of the following is a benefit that static testing provides that dynamic testing typically cannot?
Detecting defects directly in requirements or design before any code is executed.
Static testing examines work products without execution, so it finds defects earlier and at their source.
Measuring the actual response time of the running system.
Measuring runtime behaviour requires execution — that is dynamic testing.
Observing failures caused by memory leaks during execution.
Observing runtime failures needs execution and is dynamic testing.
Confirming that a fixed defect no longer causes a failure at runtime.
That is confirmation testing, which requires executing the software.
Static testing can find defects in work products without executing code, e.g. directly in requirements, even before code exists.
A team needs a review type that is the most formal, follows a defined process with documented entry/exit criteria, uses metrics, and is led by a trained moderator. Which review type fits best?
Inspection
Inspection is the most formal review: defined process, trained moderator, roles, metrics and exit criteria.
Walkthrough
A walkthrough is led by the author and is less formal, often without strict entry/exit criteria or metrics.
Informal review
An informal review has no defined process and produces little or no documentation.
Technical review
A technical review is formal-ish and peer-led, but the inspection is the most formal of the listed types.
An inspection is the most formal review type, with a defined process, roles, entry/exit criteria and metrics.
During a formal review meeting, which role is responsible for recording the defects, decisions and new issues raised during the discussion?
The scribe (recorder).
The scribe collates and documents the anomalies, decisions and new findings during the meeting.
The moderator (facilitator).
The moderator leads and facilitates the meeting; recording is the scribe's job.
The author.
The author created the work product and answers questions, but does not record the review.
The review leader / manager.
The manager may decide on execution of reviews, but recording during the meeting is the scribe's role.
The scribe (recorder) documents the defects, decisions and issues raised during the review.
A web form accepts a 'quantity' field for an online order. The specification says: an order quantity must be an integer between 1 and 50 inclusive. Quantities of 0 or less are rejected as 'invalid quantity'; quantities of 51 or more are rejected as 'exceeds maximum'. Using equivalence partitioning, how many equivalence partitions exist for the quantity field, and what is the minimum number of test cases to cover each partition once?
3 partitions; 3 test cases.
Valid 1–50, invalid ≤0, invalid ≥51 = three partitions; each covered once needs three test cases.
2 partitions; 2 test cases.
This ignores that there are two distinct invalid partitions with different handling.
4 partitions; 4 test cases.
There is only one valid partition (1–50), not two; the total is three, not four.
50 partitions; 50 test cases.
Equivalence partitioning groups values that are treated the same; it does not test every integer.
There are three partitions (one valid: 1–50; two invalid: ≤0 and ≥51), needing a minimum of three test cases.
For the same 'quantity' field (valid integer range 1 to 50 inclusive), you apply the 2-value boundary value analysis (BVA) approach. The 2-value approach tests, at each boundary, the boundary value and its nearest neighbour on the other side. Which set of values exactly represents the 2-value BVA test values for this field?
0, 1, 50, 51
Lower boundary 1 with neighbour 0; upper boundary 50 with neighbour 51 — four values.
1, 50
These are only the boundaries themselves; the 2-value approach also needs the neighbours 0 and 51.
0, 1, 2, 49, 50, 51
That is the 3-value approach (boundary plus both neighbours), not the 2-value approach.
1, 25, 50
25 is a midpoint (a typical EP value), not a boundary value for BVA, and 0/51 are missing.
The boundaries are 1 and 50; the 2-value approach uses {0, 1, 50, 51}.
A discount engine assigns a loyalty tier based on annual spend S (a whole number of euros): Bronze for 0–999, Silver for 1000–4999, Gold for 5000 and above. Using the 3-value boundary value analysis approach (each boundary tested with the value before, the value at, and the value after the boundary), how many distinct test values are required to cover all the internal boundaries between the tiers? Consider only the two internal boundaries (Bronze/Silver and Silver/Gold).
6 distinct test values.
Each internal boundary contributes three values; the two sets {999,1000,1001} and {4999,5000,5001} do not overlap, giving 6.
4 distinct test values.
That would be the 2-value approach (two values per boundary), not the 3-value approach.
3 distinct test values.
Three values cover only one boundary; there are two internal boundaries here.
9 distinct test values.
Nine would assume three boundaries; only two internal boundaries are considered.
Boundary 1000 → {999,1000,1001}; boundary 5000 → {4999,5000,5001}; no overlap, so 6 distinct values.
The decision table below specifies the discount and free-shipping rules at an online shop's checkout. 'Member (loyalty)' means the customer has a loyalty account, 'Cart total ≥ 100' means the order is 100 euros or more, and 'Coupon valid' means a valid coupon code was entered. '–' means 'don't care'.
A loyalty member places an order of 120 euros and does NOT enter a coupon. According to the table, which rule applies and what are the resulting actions?
Rule R6: 10% discount and free shipping.
Member T, cart ≥ 100 T, coupon F is exactly R6, giving 10% and free shipping.
Rule R7: 20% discount and free shipping.
R7 requires a valid coupon (Coupon=T); here no coupon was entered.
Rule R4: 5% discount and no free shipping.
R4 requires Cart ≥ 100 = F; here the cart is 120 (≥100 = T).
Rule R1: 0% discount and no free shipping.
R1 is for non-members with a cart under 100; this customer is a member with a 120 cart.
Member=T, Cart≥100=T, Coupon=F matches R6 → 10% discount, free shipping = Yes.
Look again at the discount decision table for the online shop checkout.
Why does rule R1 use a 'don't care' (–) value for the 'Coupon valid' condition, and what is the practical effect on the number of columns?
Because the result is identical whether or not the coupon is valid, the two corresponding columns are merged into the single rule R1, reducing the table size.
A 'don't care' collapses combinations that produce the same actions, shrinking the table without losing coverage.
Because the coupon condition is invalid input that should never be tested.
The coupon condition is valid and tested elsewhere; '–' only signals it is irrelevant for this rule.
Because a missing value means the rule is infeasible and can be deleted.
R1 is a valid, feasible rule; '–' is a deliberate 'don't care', not a missing or infeasible value.
Because it doubles the number of columns to be tested.
A 'don't care' reduces, not increases, the number of columns/rules.
When a non-member has a cart under 100, the outcome is the same regardless of the coupon, so two columns collapse into one (R1).
The state transition diagram below models a simple vending machine. The machine starts in 'Idle'. Inserting a coin moves it to 'HasCredit'; further coins add credit (self-transition). From 'HasCredit', selecting a product when there is enough credit goes to 'Dispensing'; selecting with insufficient credit goes to 'Refunding'. After dispensing or refunding, the machine returns to 'Idle'. 'cancel' from 'HasCredit' refunds and returns to 'Idle'.
Which of the following event sequences is a VALID path through the diagram (i.e. every transition exists)?
insertCoin, insertCoin, select [credit ≥ price], dispensed.
Idle→HasCredit, self-loop on second coin, →Dispensing on sufficient credit, →Idle on dispensed. All transitions exist.
select [credit ≥ price], insertCoin, dispensed.
From Idle there is no 'select' transition; the first event is invalid.
insertCoin, dispensed.
There is no 'dispensed' transition directly from HasCredit; dispensing must occur first.
insertCoin, select [credit < price], dispensed.
Insufficient credit goes to Refunding, from which 'dispensed' does not occur (it 'refunded').
insertCoin → insertCoin → select(enough) → dispensed is valid: Idle→HasCredit→HasCredit→Dispensing→Idle.
Which statement best describes when a decision table is an especially suitable test design technique?
When different combinations of input conditions lead to different system actions or outputs.
Decision tables systematically capture combinations of conditions and their resulting actions.
When the system has a single numeric input range and nothing else.
A single range is better handled by equivalence partitioning and boundary value analysis.
When behaviour depends on the sequence of events over time.
Sequence-dependent behaviour is modelled with state transition testing, not decision tables.
When the internal code structure must be exercised for coverage.
Code structure coverage is white-box testing; decision tables are a black-box technique.
Decision tables are well suited when system behaviour depends on combinations of conditions producing different actions.
Consider this routine (line numbers shown). Line 1: read x. Line 2: if x > 0 then. Line 3: y = x * 2. Line 4: end if. Line 5: if x > 100 then. Line 6: y = 100. Line 7: end if. Line 8: print y. The executable statements are lines 1, 2, 3, 5, 6, 8. A single test runs with x = 50.
What statement coverage does the single test x = 50 achieve?
About 83% (5 of the 6 statements).
x=50 satisfies x>0 (lines 3 runs) but not x>100 (line 6 skipped): 5/6 ≈ 83%.
100%.
Line 6 (y = 100) is never reached with x = 50, so coverage cannot be 100%.
50%.
Far more than half of the statements execute; only one of six is missed.
67%.
67% would mean 4 of 6 statements; here 5 of 6 execute.
With x=50, lines 1,2,3,5,8 execute (5 of 6 statements); line 6 is skipped → ~83%.
A function contains a single decision: if (a AND b) then doX() else doY(). 'a' and 'b' are independent Boolean inputs. You want to achieve 100% branch (decision) coverage — both the true and the false outcome of the decision must be exercised.
What is the minimum number of test cases required for 100% branch coverage of this decision?
2 test cases.
One case makes (a AND b) true (a=T,b=T → doX), one makes it false (e.g. a=F → doY); both branches covered.
1 test case.
One case exercises only one outcome of the decision; branch coverage needs both.
3 test cases.
Three are not required for simple branch coverage of one decision; two suffice.
4 test cases.
Four would cover all input combinations of a and b, which is more than branch coverage requires.
Branch coverage needs the decision to be both true and false → 2 test cases (e.g. a=T,b=T and a=F).
Which TWO of the following are characteristics of black-box (specification-based) test techniques? (Choose two.)
Test cases are derived from the specification or other external description of behaviour.
Black-box techniques use external descriptions, not the code's internal structure.
Equivalence partitioning and boundary value analysis are examples.
Both are classic black-box (specification-based) techniques.
They measure statement and branch coverage of the source code.
Coverage of code structure is a white-box characteristic.
They require access to and analysis of the internal source code.
Needing the internal code is white-box, not black-box.
Black-box techniques derive tests from specifications without reference to internal code structure; examples include EP, BVA and decision tables.
An experienced tester, without using a formal technique, lists inputs likely to cause problems (empty fields, zero, negative numbers, very long strings, special characters) based on past defects. Which experience-based technique is this?
Error guessing.
Error guessing uses the tester's experience to anticipate likely defects and design tests for them.
Boundary value analysis.
BVA is a formal specification-based technique, not an experience-based one.
Statement testing.
Statement testing is a white-box, structure-based technique.
Checklist-based testing.
Checklist-based testing follows a documented checklist; here the tester improvises from experience without one.
Anticipating likely errors from experience is error guessing.
A team uses risk-based testing. Each product risk is scored as risk level = likelihood × impact, where likelihood and impact are each rated 1 (low) to 5 (high). Four risks are assessed: R1 likelihood 2, impact 5; R2 likelihood 4, impact 4; R3 likelihood 5, impact 2; R4 likelihood 3, impact 3. The team will test the risk with the HIGHEST risk level first. Which risk should be tested first, and what is its risk level?
R2, with a risk level of 16.
2×5=10, 4×4=16, 5×2=10, 3×3=9 → R2 (16) is highest and is tested first.
R1, with a risk level of 10.
R1 scores 10, which is not the highest; R2 scores 16.
R3, because it has the highest likelihood.
Highest likelihood alone does not maximise risk level; R3 scores only 10.
R1, because it has the highest impact.
Highest impact alone does not maximise risk level; R1 scores 10, below R2's 16.
R1=10, R2=16, R3=10, R4=9; the highest is R2 with 16.
Which TWO of the following are examples of PRODUCT risks (rather than project risks)? (Choose two.)
The software may miscalculate interest, giving customers wrong account balances.
A defect in the delivered software affecting quality is a product risk.
Under heavy load the system may respond too slowly for users.
Poor performance of the product is a quality-related product risk.
Key testers may leave the team before the test phase is complete.
Staffing/availability is a project risk, not a product risk.
The test environment may not be delivered by the supplier on time.
Delays from a supplier affecting the schedule are a project risk.
Product risks relate to the quality of the product itself; project risks relate to managing the project (schedule, staffing, etc.).
A test lead estimates the effort to execute a test suite using the three-point (PERT) technique, where Estimate = (Optimistic + 4 × Most likely + Pessimistic) / 6. The optimistic estimate is 4 days, the most likely is 7 days, and the pessimistic is 16 days. What is the three-point estimate?
8 days.
(4 + 28 + 16) / 6 = 48 / 6 = 8 days.
9 days.
9 would result from arithmetic error; the correct weighted mean is 8.
7 days.
7 is the most-likely value alone, not the weighted three-point estimate.
9.5 days.
9.5 is the simple average of 4, 7 and 16 ((27/3)=9) miscomputed; the PERT formula weights the most likely by 4.
(4 + 4×7 + 16) / 6 = (4 + 28 + 16) / 6 = 48 / 6 = 8 days.
What is the main purpose of test monitoring and test control during test execution?
To gather information about test progress and use it to guide corrective actions toward the test objectives.
Monitoring collects metrics; control acts on them — together they keep testing on track.
To write the source code that fixes the defects found.
Fixing code is development/debugging, not test monitoring and control.
To guarantee that the project will finish on the planned date.
Monitoring informs decisions but cannot guarantee schedule outcomes.
To replace the need for a test plan.
Monitoring and control complement the test plan; they do not replace it.
Monitoring gathers information on progress; control uses it to take corrective actions to meet objectives.
Which TWO of the following would typically be documented in a test plan? (Choose two.)
The test objectives, scope and the test approach to be used.
Scope, objectives and approach are core contents of a test plan.
Entry and exit criteria for the test activities.
Entry/exit criteria are standard elements of a test plan.
The full source code of the application under test.
Source code is not part of the test plan.
The detailed step-by-step description of each defect found.
Individual defect reports are separate work products, not the test plan.
A test plan documents scope, objectives, approach, schedule, resources and entry/exit criteria — not the actual defect reports or source code.
In an Agile team, the 'definition of done' for a user story includes 'all acceptance tests pass and no high-severity defects remain open'. Which test-management concept does the definition of done MOST directly correspond to?
Exit criteria.
The definition of done specifies the conditions that must be satisfied to consider the work complete — i.e. exit criteria.
Entry criteria.
Entry criteria (definition of ready) decide when work may start, not when it is finished.
Test data.
Test data are inputs used to run tests, unrelated to completion conditions.
A test charter.
A test charter guides an exploratory session; it is not the completion criteria for a story.
A definition of done acts as exit criteria — conditions to be met before work is considered complete.
Which TWO pieces of information are essential in a good defect report to make it actionable? (Choose two.)
Clear steps to reproduce the problem.
Reproduction steps let developers observe and diagnose the failure.
The expected result and the actual (observed) result.
Expected vs actual results define precisely what is wrong.
The name of the developer who is to blame for the defect.
Assigning blame is counterproductive and not part of a quality defect report.
The tester's guess at the exact line of code causing the defect.
Pinpointing the code line is the developer's diagnosis, not a required reporting field.
A useful defect report includes steps to reproduce and the expected vs actual results; blame and guessed root cause are not essential.
How does configuration management support the testing activities?
It uniquely identifies and version-controls test items and testware so that tests are reproducible and traceable.
Knowing exactly which versions were tested makes results reliable and reproducible.
It automatically writes the test cases from the requirements.
Configuration management controls versions; it does not generate test cases.
It guarantees that the software has no configuration defects.
It manages versions but cannot guarantee the absence of defects.
It removes the need to track which build a defect was found in.
On the contrary, it is precisely what enables tracking the build/version of each defect.
Configuration management ensures testware and test objects are identified, version-controlled and traceable so results are reproducible.
A test manager decides how testing will be carried out: which techniques, levels and types to use, how much to automate, and how to allocate effort against risks. What is this overall set of decisions called?
The test approach.
The test approach defines how testing is tailored and implemented for the project's context and risks.
The test condition.
A test condition is a specific item to be tested, not the overall approach.
The test case.
A test case is a single set of inputs/expected results, not the strategy.
The test log.
A test log records what happened during execution, not how testing is planned.
This is the test approach (test strategy) — how testing is implemented for the context and risks.
Which TWO of the following are examples of tools that support test execution and logging? (Choose two.)
A test execution tool that replays scripted tests and records pass/fail results.
Test execution tools run automated scripts and log the outcomes.
A unit test framework that runs developer tests and reports results.
Unit test frameworks execute tests and capture/report logs of the results.
A requirements management tool used to store and trace requirements.
Requirements management supports test management/traceability, not execution and logging.
A static analysis tool that inspects source code without executing it.
Static analysis supports static testing, not dynamic execution and logging.
Test execution and logging is supported by tools that run scripted tests and capture results, e.g. test execution tools and unit test frameworks.
Which statement describes a realistic benefit AND a realistic risk of test automation, taken together?
Benefit: less repetitive manual effort and faster feedback; Risk: scripts require ongoing maintenance and expectations may be set too high.
Automation saves repetitive effort but adds maintenance cost and risk of over-reliance — a balanced, realistic view.
Benefit: it finds more defect types than any human; Risk: none, once set up.
Automation does not inherently find more defect types, and it always carries maintenance and other risks.
Benefit: it removes the need for any test design; Risk: it is slower than manual testing.
Automation still needs good test design, and it is usually faster, not slower, for repetitive runs.
Benefit: it guarantees a defect-free release; Risk: it is too cheap to be worthwhile.
No technique guarantees a defect-free release, and low cost is not a risk.
Automation can reduce repetitive manual effort (benefit) but incurs ongoing maintenance cost and can be over-relied upon (risk).