ISTQB Advanced (CTAL-TM v3.0) Mock Exam #1 — Questions & Answers

Analysis, design and execution are activities the test manager plans and monitors, but the syllabus classifies them as test process work rather than as management activities.

Strategy definition sits inside planning and closure reporting inside completion, so this list splits and renames the real grouping rather than reproducing it.

These are the steps of risk management, which the syllabus treats as an input to planning and control, not as the top-level structure of the test process.

This is test monitoring and control: it happens while testing is running so that deviations can still be corrected, not after the effort is closed.

Product risk identification and treatment selection is a planning activity, performed before the risks in question have been tested.

Test readiness assessment is part of monitoring and control, gating the start of a level rather than closing the effort down.

Promoters are actively engaged as well as powerful; this stakeholder attends nothing and has expressed no view on the approach.

Defenders care about testing but cannot direct it. Here the situation is reversed: the stakeholder can cancel the programme outright.

The low-interest half fits, but budget authority and the ability to cancel the programme are exactly what distinguishes high power from low.

Meeting one criterion does not compensate for another, and deferring the record of two uncovered high risks to a report written after UAT removes the stakeholders' chance to act on it.

The test manager evaluates and reports against the criteria, but the decision to accept residual risk sits with the accountable stakeholders; taking it away turns a business trade-off into a unilateral one.

Rewriting criteria and risk levels to match the current results makes the gate unable to fail, which removes the only reason for having one.

This inverts the two lifecycles; continuous team-owned reporting is the iterative pattern, not the sequential one.

Frequency does differ, but so does the metric set: iterative teams favour velocity and burndown, sequential projects favour phase-based progress and coverage against a baselined plan.

Neither lifecycle restricts itself to a single measure; both track defects, progress and coverage, differing in formality and cadence rather than in scope.

Fix cost influences defect triage decisions but is not a factor in the risk level itself, which is assessed before the defects exist.

Achieved coverage is a measure of test progress, not a determinant of a product risk's level; the risk exists independently of how much testing has been done.

Both are real inputs to planning and to skills allocation, and defect density can inform likelihood, but neither is a defining factor of risk level.

The arithmetic on the tie-break is applied to the wrong pair: 10 is the lower exposure, so A and C are the two risks that wait rather than the two addressed first.

Treating a maximum on a single factor as decisive abandons the multiplicative definition of exposure; A scores 10 and therefore ranks below both B and D.

The syllabus does not weight likelihood above impact when effort is constrained; exposure remains the product of the two factors regardless of the deadline.

Breadth-first is the better fit when risk is evenly distributed; here it spends scarce time on four subsystems whose findings cannot stop the release.

Regulation typically constrains which techniques and evidence are required at a given integrity level, but the syllabus does not derive a breadth-first ordering from regulation as such.

This delays the findings that carry the stop-the-release consequence to the point where there is least time to act on them, which reverses the purpose of risk-based ordering.

A pass rate hides the two shallow coverages behind the same figure as the eleven thorough ones, so the steering group cannot see the difference in exposure.

These are effort and progress measures. They demonstrate that testing happened without telling the reader what risk remains.

This belongs in lessons learned during test completion; it explains why the gap exists but does not state the exposure the steering group must decide on.

The two groups are swapped: PRISMA and SST are the lightweight approaches, while FMEA and hazard analysis carry the heavier analytical overhead.

Cost of exposure is correctly placed but PRAM is a lightweight technique, and fault tree analysis is heavyweight rather than lightweight.

Risk workshops, brainstorming and checklists are techniques for identifying risks, not the assessment approaches this classification refers to.

Keen beginnings describes enthusiasm decaying within one project; here the analysis is repeated across releases but without fresh thought.

Stakeholder churn concerns changing participants; in this case the same people take part and the problem is the lack of reassessment.

That difficulty is about the assessment itself being hard; here the scores are accepted without dispute because nobody re-examines them.

Acceptance may be reasonable for low-impact risks, but a very high impact combined with an available and testable design mitigation makes doing nothing hard to defend.

The stub is worth building, but inflating the likelihood score to force effort corrupts the risk register, and testing alone leaves the financial consequence untreated.

Transfer moves the financial consequence, not the reputational and operational effects, and a transferred risk stays on the register with its residual level recorded.

That is the test policy, which sits above both strategies and expresses intent rather than approach.

That is the organizational test strategy; the project test strategy is what adapts it to a particular project.

Those details belong in test plans at the release, level or iteration layer; the strategy sets the approach that those plans then implement.

The iterative model shapes cadence and planning layers, but it does not remove any technique from the table; the missing interfaces and data do.

Team size influences how much can be done, but nothing in the scenario indicates the team is undersized relative to the module; the availability problems are stated explicitly.

The domain does raise the required rigour, but the syllabus treats all seven factors as inputs to be analysed together rather than one overriding the rest.

Confidence and thoroughness cannot be measured against a threshold, and "before the release" is not a fixed point, so the statement fails the measurable and time-bound criteria.

It is specific, measurable and time-bound, but zero remaining defects is not achievable and cannot be demonstrated, so it fails the achievable criterion.

The measure and the date are sound, but the target covers the whole application rather than the checkout flow, so the objective is not relevant to the stated goal.

The layers coexist on larger efforts; treating them as mutually exclusive alternatives misses the point of the hierarchy.

Later plans do not supersede earlier ones; a valid iteration plan operates within the level and master plans that remain in force.

Iterative programmes frequently keep a release or master plan alongside iteration plans, so the split by lifecycle does not hold.

The phase names are invented, and GQM is a measurement approach used inside analytical improvement rather than the cycle IDEAL is related to.

Two phase names are wrong, and TMMi is a model-based improvement framework, not the cycle that IDEAL corresponds to.

These phase names do not appear in the model, and retrospectives are one analytical improvement technique rather than IDEAL's counterpart cycle.

The two models are swapped: the sixteen key areas belong to TPI NEXT and the five staged levels to TMMi.

TPI NEXT deliberately produces a profile across key areas at four levels rather than one overall rating, so the difference is structural.

Both are model-based. Root cause analysis and metric analysis belong to the analytical-based category alongside GQM.

This skips the decision step; a list handed on without selection or ownership rarely produces change, which is why the syllabus makes deciding a distinct step.

Data collection precedes deriving improvements and has already happened; returning to it now stalls the session rather than advancing it.

The blame-free frame is set at the introduction and upheld throughout, but it is not a step the process returns to in place of deciding on actions.

TMMi is a model-based rather than analytical-based approach, and a maturity assessment answers a different question than why these particular defects escaped.

Retrospectives are a legitimate improvement technique in the syllabus, but they rest on participants' recollection rather than on analysing the defect data that is already available.

This is again model-based improvement; the lowest-scoring key areas may have nothing to do with the specific mechanism producing the escapes.

This classifies tools by the activity they support, which is a different taxonomy from the business-type one used for the adoption decision.

Deployment model affects cost and security considerations but is not the classification the syllabus uses for business type.

Support arrangements follow from the business type rather than defining it, and custom in-house tools do not fit any of these three labels cleanly.

Initial training is non-recurring and belongs with the 90,000, and the point of an opportunity cost is the value forgone, not the salary that is paid either way.

318,000 is the three-year total rather than the annual recurring figure, and excluding opportunity costs is precisely the omission that makes tool business cases over-optimistic.

Collapsing the categories loses the distinction the analysis depends on: selection, framework build and initial training are paid once and do not repeat in years two and three.

Piloting and roll-out are steps within acquisition and introduction, and the two roles' responsibilities are the wrong way round.

Proof of concept is a good practice during introduction rather than a lifecycle phase, evolution is missing, and the syllabus keeps the two roles distinct.

Support and maintenance is omitted, and the business case sits with the tool owner rather than with the administrator.

Licence utilisation is useful for cost control but describes procurement rather than the contribution the tool makes to testing.

This is a staffing ratio that would be the same with or without the tool, so it cannot evidence the tool's contribution.

Technical reach describes the tool's applicability, assessed before adoption, rather than a metric of the value it delivers in use.

Reporting on the headline count hides the fact that the executed total includes 130 blocked tests in the highest-risk areas, which is the deviation that matters.

Descoping tests in the highest-risk subsystems increases residual risk silently; monitoring and control exists to surface such a trade-off, not to conceal it.

Extending the schedule is one possible outcome, but issuing it before the login defect is escalated treats the symptom and may prove unnecessary once the blocker clears.

Uniformity removes the mismatch by discarding the benefit of the faster cadence, and the syllabus treats hybrid working as something to manage rather than to eliminate by decree.

Comparable reporting is a real hybrid challenge, but imposing the heavier documentation regime on iterative teams addresses the paperwork rather than the dependency that is blocking them.

This keeps the lifecycles separate but pushes a growing backlog of dependent stories into one crowded sprint, which concentrates rather than reduces the risk.

The first two examples are swapped, and headcount is a resourcing fact rather than a measure of process capability.

These are three legitimate metric groups used in reporting, but they are not the project, product and process classification the syllabus sets out.

Leading and lagging is a useful distinction for interpreting trends, but it is not the three-category classification defined in this chapter.

A blocker often is severe, but the category records that the test could not run rather than grading the severity of anything.

Blocked tests are usually not executed at all, so they do not represent consumed execution effort, and neither category is a productivity measure.

A blocked test contributes no coverage either, and requirements coverage is reported through its own metric rather than inferred from these two categories.

Closures matched the inflow exactly, so resolution is keeping pace; the flat count is the arithmetic result of equal flows, not evidence of a backlog growing.

Snapshots have a legitimate role in reporting the current position; the syllabus asks for them to be read alongside trends rather than discarded.

Premature closure is a real phenomenon, but it is evidenced by the re-opened rate, which is not reported here; age alone does not support that reading.

Budget consumption says nothing about the quality of the product; using it as the stopping signal is exactly the single-metric reasoning the syllabus warns against.

Risk-based testing deliberately allocates less effort to lower risks; requiring full coverage of every level would remove the prioritisation the approach exists to provide.

That alternative explanation is worth checking, but here it is contradicted by the coverage figures and the low severity of what remains open.

Consumed effort belongs to the costs and effort metric group; it measures spend rather than what has been exercised.

This describes defect resolution progress, which is reported under defect metrics rather than as a coverage basis.

Environment availability is a constraint tracked during monitoring and control; the syllabus does not list it as a coverage basis.

33 is the simple average of the three values. The weighted formula gives the most likely value four times the weight of the others, which yields 30.

They do not cancel: the pessimistic value lies 27 days above the most likely one while the optimistic lies only 9 below, so the weighted result is pulled upwards.

The formula weights the most likely value most heavily regardless of the type of work; no variant weights the pessimistic value above it.

Tooling and budget are considerations within the context and process groups, but this is not the five-group classification the syllabus defines.

These are the dimensions being traded off in the time-cost-quality triangle, not the factors that influence how much effort testing will take.

Each of these is a real influence, but they are individual factors drawn from several groups rather than the grouping itself.

This reverses the heuristic and substitutes external benchmarks for organisational data, which the syllabus does not treat as an equivalent basis.

Comparability is desirable but cannot be bought by applying a data-driven technique where no relevant data exists; the resulting figure for B would be false precision.

Expert-based is not inherently more accurate, and a full Delphi round is hard to reconcile with two experts available for half a day and a Friday deadline.

The syllabus does not cap the number of statuses; DEFERRED and RE-OPENED carry information that the core four cannot express.

This adds a third terminal status and would mark defects complete before the fix has been confirmed by retesting.

The good practice is the opposite: non-terminal statuses should offer more than one outgoing transition, since a report in progress may be fixed, rejected or deferred.

This describes a false-positive result: a failure is signalled where the test object is sound.

That is a rejected defect report, which is a workflow outcome rather than a property of the test result.

This describes an unreproducible anomaly; the test did detect something, so the result was not negative.

These fields are generated by the defect management tool rather than entered by the reporter, so adding them manually does not fix what is missing.

Severity and priority are separate judgements — technical consequence and business urgency — and deriving one from the other collapses that distinction.

Root cause and phase of introduction are valuable when they are used, but the syllabus advises collecting only what will be used, and most of these cannot be known at reporting time.

That would be a triage policy. A taxonomy classifies what kind of defect it is, not how urgently it should be fixed.

The sequence of statuses is the defect workflow, a separate concept described alongside the taxonomy.

That is a known-issues list produced at release; a taxonomy is a classification scheme that exists independently of any one release.

The first two are right, but debugging quality is assessed through the re-opened rate; duplicates reflect how reports are raised and searched, not how fixes are made.

Reading a containment failure as a success reverses the point of phase containment analysis, and duplicates represent rework rather than diligence.

The cluster and containment findings are attached to the wrong observations, and nothing in the data indicates that the taxonomy lacks categories.

Consistency in the data matters, but the syllabus explicitly allows in-iteration defects on work in progress to go unreported where nothing depends on the record.

The backlog does receive unresolved items, but it does not remove the cases where the syllabus says a defect report should still be raised.

Duration is not the criterion; the syllabus lists several situations, most of which concern the scope and traceability of the defect rather than how long the fix takes.

Giving one side the final word suppresses the disagreement rather than resolving it, and it conflicts with the practice of separating roles across adjacent statuses.

A taxonomy classifies the kind of defect; it does not decide whether a given report is valid or how urgently it should be addressed.

The metric makes the problem visible and is worth having, but visibility alone does not supply the forum in which the disposition is actually agreed.

The four areas are right but the attribution is not: certification builds the body of testing knowledge, which the syllabus places under professional competence.

These labels resemble the real ones but are not the four areas the syllabus cites from the competence literature it references.

Domain and tooling knowledge are elements within professional competence rather than areas in their own right in this model.

Clinical risk analysis needs domain judgement, and asking a tester with six months of experience to build the framework inverts the skill mapping entirely.

Reducing key-person dependency is a legitimate aim, but full rotation from the outset places uncertified judgement on clinical risk analysis in a safety-related context.

The first two placements are sound, but removing a third of the team from a two-week iteration for formal training ignores the on-the-job development the syllabus also lists.

Forming is the polite orientation phase the team has already passed; the open argument is the marker that it has moved on.

Norming follows storming and is characterised by settled agreements; here the agreements are precisely what is being contested.

Adjourning is the disbanding phase at the end of a team's life and has nothing to do with early conflict over approach.

Herzberg places remuneration among the hygiene factors: inadequate pay causes dissatisfaction, but improving it does not produce lasting motivation.

Personnel policy surrounds the work rather than forming part of it, which places it among the hygiene factors.

Relationships are listed as a hygiene factor: poor ones demotivate, but good ones are treated as a baseline condition rather than a motivator.

This reverses the two: the three named models are behavioural, and none of them measures technical competency.

All four are applied to individuals; the models are then used to reason about the composition of the team.

The skills matrix is maintained continuously to guide development and allocation, and the behavioural models are not appraisal instruments.

Prevention costs are incurred whether or not a given defect occurs and are not subtracted in this formula, which is why the printed version omits them.

Appraisal cost per defect is exactly the cost of finding it, so leaving it out overstates the saving that early detection produces.

Adding the categories gives the total cost of quality per defect, not the saving from finding one earlier rather than later.

Proving the point by allowing failures reaches customers first and treats external failure cost — the most expensive category — as an acceptable experiment.

The qualitative benefits are real and worth raising, but the syllabus provides explicit formulas for the quantitative side, so conceding that it cannot be measured gives away the stronger argument.

Prevention is cheaper per defect, but shifting the entire budget away from appraisal removes the detection that produced the clean releases in the first place.

The categories are right, but appraisal covers the effort of evaluating the product; the repair effort that follows is internal failure cost.

These labels describe the same idea loosely but are not the four categories the syllabus names, and the model it cites uses the prevention-appraisal-failure structure.

This is a general accounting classification rather than the cost of quality model applied in this chapter.

It leaves the capability gap open and forgoes the one chance to learn directly from the person who holds the knowledge.

Documentation is a useful supplement, but the syllabus treats competence as developed through practice and interaction; a document alone does not create an analyst.

Buying the capability is a valid commercial option, but it answers a sourcing question rather than the skill development question the matrix has raised.