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

Corrective: the review and static analysis are carried out to find and repair defects that have already been introduced into the implemented locking logic.

Mitigating: the review and static analysis are carried out to reduce the business impact of a double-booking that has already reached ticket buyers, rather than to stop it occurring.

Accepting: the review and static analysis are recorded as evidence that the risk is tolerated, with production incidents monitored instead of any further treatment being planned.

Both are test analysis activities: readiness and completeness are established by deriving test conditions from the test basis and evaluating the coverage those conditions give.

Test readiness is a test planning activity and approval against exit criteria is a test completion activity, so neither belongs to test monitoring and control, whose scope is progress reporting.

Both are test implementation activities: the test manager assembles the testware and confirms that the test environment is ready before and after the agreed execution window.

Hybrid models arise from a transition to Agile, and the sequential parts are expected to be converted to Scrum before the next release; coordination during that transition is handled by a scrum-of-scrums.

Hybrid models are defined by combining the test levels of a sequential lifecycle with the test types of an Agile lifecycle, and coordination between the two parts is handled in the joint release retrospective.

Hybrid models require that testing for every part is planned in a single iteration-independent test plan, and the scrum-of-scrums is the forum in which the product owner formally approves that combined plan before each release begins.

In the sequential model, estimation is re-done by the whole team at the start of every phase and testware is deliberately kept lightweight; in the iterative model, estimation is fixed for the whole release and testware is maintained as formal specifications.

In both models estimation is performed once per release by the test manager alone; the only difference is that sequential testware is reusable across later projects while iterative testware is discarded at the end of each iteration once the increment has been accepted at the review.

In the sequential model, estimation is based on story points agreed in planning poker and testware is held in the product backlog; in the iterative model, estimation is based on a work breakdown structure and testware is filed with the master test plan.

Rating the likelihood and the impact of each identified item as low, medium or high in an agreed risk matrix.

Selecting mitigation actions and allocating the available test effort to the highest-rated risk items first.

Reporting the residual risk level of each product area to stakeholders in the weekly test progress report.

It produces a numeric risk score for each item that can be summed into a single overall project risk figure, but it depends on historical defect and cost data that most projects do not have available in the quality needed for the figure to be trusted.

It records the agreed owner and the planned mitigation action for every risk item, but it cannot show the relative priority of one risk against another until test execution has started and defect data is available.

It classifies each item as either a project risk or a product risk, but it gives no indication of impact, so the impact of each item has to be established separately in a quantitative cost-based model before test effort is allocated.

Key risks are being missed: too narrow a group contributed to the analysis. A wider range of stakeholders should be involved and more than one identification technique should be applied in each analysis session so that blind spots are covered.

The analysis was carried out by people without sufficient payroll domain knowledge. Risk identification should be handed over to the business stakeholders who own the payroll rules and repeated at the start of each major release.

This is a test monitoring shortcoming rather than a risk analysis difficulty. The risk register should be replaced by product risk coverage metrics that are published in each sprint test progress report and reviewed by the team.

Testing is the primary risk-mitigation measure and is selected for each identified risk without further analysis; a contingency plan is the schedule buffer added to the test plan so that slipped test cycles can still finish; transfer means moving the affected feature to a later release; and acceptance is the sign-off the board gives to the completed risk analysis.

A contingency plan is the primary risk-mitigation measure and is prepared for each high-priority risk; testing is selected only where a risk is rated low and the cost of a contingency plan would not be justified; transfer means reassigning the risk to a different test level in the same project; and acceptance is the decision to stop testing once exit criteria are met.

Transfer is the primary risk-mitigation measure and is applied by delegating the affected functionality to the supplier that built it; testing is the contingency plan invoked where transfer is not possible; a contingency plan covers risks the supplier declines; and acceptance is the state a risk reaches once its tests have passed.

A measure is the scale and the method used to take a measurement, a metric is the single value that results from applying that scale, and an indicator is the target value the result is compared against; good indicators are objective, repeatable and independently auditable.

A measure is a raw value collected from the test process, a metric is the trend that value follows over successive iterations, and an indicator is the control action triggered whenever the trend deviates; good indicators are timely, visible and inexpensive to collect.

Measure and metric are interchangeable terms for any value that has been collected during testing, while an indicator is any chart or dashboard included in the test progress report; good indicators are effective, efficient and predictable.

It is the archive index recording where the testware, the test data and the test environment configurations have been stored, so that the maintenance team can retrieve and reuse them during the next release of the smart-parking platform.

It documents the scope, the approach, the resources and the schedule of the testing that is still to be performed, so that stakeholders can approve the planned effort and its budget before test execution begins.

It lists every executed test case with its individual pass or fail outcome and the defect reports raised against it, so that the developers can reproduce and correct each remaining failure before the test level is closed.

Assess the organization's maturity and needs, purchase enterprise licences for all five sites at once, then run a pilot project in parallel with the rollout so that its lessons can be applied while adoption is under way.

Shortlist the candidate tools on functionality and licence cost alone, deploy the chosen tool to all five sites simultaneously so that everyone learns it together, and run a proof of concept afterwards to confirm the choice.

Run a proof of concept on the tool the sites already use, migrate the existing testware into the new tool straight away, and then let each site decide independently whether to adopt it once migration is finished.

The defect detection percentage that the test team achieved on the two most recent releases of the freight shipping platform.

The number of test cases that are currently maintained in spreadsheets rather than in any dedicated test management tool.

The test levels and the test types at which the previously purchased tool happened to be used by the shipping teams.

The parties who fund the test effort and hold the budget for it, such as the programme sponsor and the finance function; identifying them early lets the test manager secure the funding and the specialist staffing that are needed before the master test plan can be baselined.

The members of the test team together with their line management and the test architects supporting them; identifying them early lets the test manager assign roles and responsibilities inside the team before test analysis and test design work begins.

The parties who formally approve the entry and exit criteria for each test level, such as the product owner and the release manager; identifying them early lets the test manager schedule the approval gates in the test plan and the test schedule.

It is the long-term, organization-wide document describing the generic testing principles, the test process and the standards applied across all of the projects, and it is revised only when the company's quality policy itself changes.

It is the part of the test plan that lists the test tasks and their dependencies, the effort estimate for each task, and the assignment of named testers to each of the test levels planned for the current terminal release.

It is the set of measurements collected while testing is running, such as the coverage achieved, the defect density and the residual risk, which are used to report test progress against the criteria agreed in advance.

EC1 fails the Measurable attribute, because it does not state what percentage of the high-priority test cases must be run; it should be restated to require that at least 95 per cent of the high-priority test cases have been executed and their results recorded in the tool by the planned exit date of 14 November.

EC3 fails the Time-bound attribute, because it fixes a fixed calendar date instead of a project milestone; it should be restated so that the severity-1 and severity-2 defect counts are taken from the defect management tool at the end of the system test level, whenever that level actually completes.

EC4 fails the Specific attribute, because it does not name the test level to which the regression suite applies; it should be restated to require that all 4,000 planned regression test cases pass at every test level, from component testing through to acceptance testing, before the release.

Open the session by restating the working agreement with all three sites, confirming once more that the session is blame-free, that everything said within it stays inside the group, and that the outcome is owned collectively by the programme, so that the participants at the two smaller sites feel safe enough to speak openly about the increment.

Work through the observations with the group in order to establish the root causes of the two largest deviations seen in the increment, so that the discussion moves from the symptoms that the teams noticed during test execution to the underlying weaknesses in the test process itself, and record the causes agreed.

Ask each of the three sites to propose the two process changes that it believes would most improve the next increment, then have the whole group vote on the combined list of proposals so that the two changes with the highest expected benefit are carried forward as improvement actions for the increment.

Alarm escalation 26 person-days and Historian archiving 16 person-days, because the five risk levels add up to a total of 31 and the whole of the available effort is shared out in proportion to each feature's combined rating.

Alarm escalation 28 person-days and Historian archiving 17 person-days, because the five impact ratings come to a total of 18 and the effort should follow the potential damage rather than the probability.

Alarm escalation 20 person-days and Historian archiving 20 person-days, because the five features each take an equal baseline share of 20 and the risk level is used only to sequence the execution order.

Add two further testers to the execution team for the remaining three weeks and extend the daily test window, so that the shortfall of 290 test cases is recovered by raising the execution rate well above the original plan, and report the revised burn-up each week until the plan is back on track and the trend is visible to the sponsor.

Increase test progress reporting from weekly to daily and add environment downtime, result reclassification rate and re-run count to the report, so that stakeholders can see the trend well before the planned end date of the test level and can decide for themselves what corrective action is warranted.

Relax the exit criteria for the system test level, reducing the required execution coverage in line with the rate actually achieved so far and limiting the biometric enrolment regression pack to a single run, so that the planned end date of the test level can still be met without changing the way of working.

In scope: only the components the operator's own supplier builds, because the organization has no contractual right to test any third-party software. The interfaces are covered by each supplier's own acceptance testing and by the monthly test reports published by the appointment service provider, so they can be treated as already verified and left out of scope, with the certified customs sandbox used only if spare capacity happens to be available late in the programme.

In scope: everything the end-to-end business process touches, including the internal logic of the crane firmware and of the customs gateway, because the terminal operator is accountable for the whole service to its customers and cannot delegate that accountability to its suppliers. The contractual restrictions are recorded as an obstacle for the procurement function to resolve, while test design proceeds on the assumption that the access will be granted in time.

In scope before release: only the components the team owns, with the end-to-end flows across all four systems moved into post-release monitoring in production, because integration behaviour between independently operated systems can realistically only be observed once every supplier is connected in the live environment. A staged rollback plan and enhanced production alerting are documented in the test plan as the compensating measures for the deferred checks.

Split the environment evenly by alternating weeks between the two programmes, because they are funded from the same budget line and an even split is the allocation that can be defended to both sponsors without reopening the risk analysis. Any resulting schedule impact is then borne symmetrically, is visible in each programme's own plan, and needs no separate escalation to the steering committee at this stage.

Give Programme B the environment first because its release is smaller and can be cleared in a few weeks, which then frees continuous uninterrupted access for Programme A from August onwards. Completing the shorter piece of work first minimises the total waiting time across the two programmes and removes the contention before the regulatory milestone approaches in the autumn.

Operate the environment on a first-come, first-served booking basis run by the environment team, because prioritising between two independently sponsored programmes is a governance decision rather than a test management one. Contention that cannot be resolved between the two test leads is then escalated to the steering committee when it arises, with the booking log as evidence.

SIL 3 governs the documentation and record keeping rather than the technical work: the choice of test techniques stays at the test manager's discretion exactly as before, and the plan changes only by adding a formal test summary report for each test level, a signed traceability matrix covering the safety requirements, and long-term archiving of all test results and defect records so that the assessor can reconstruct what was done, by whom and in what order at any point in the project.

SIL 3 applies uniformly to the whole product, requiring full statement coverage of every line of code including the telemetry and shift reporting function, so the plan should size the test effort from the size of the code base rather than from the risk analysis, since any function shipped inside a safety-related product is itself safety-related and must carry the same evidence and the same degree of verification independence when presented to the assessor.

SIL 3 requires the safety function to be verified solely by an accredited external certification body, so the plan should exclude that function from the project's own component and integration test levels and reference the certification body's schedule, scope and techniques as the coverage for it instead, with the internal team concentrating its remaining effort on the telemetry function and on system integration once the certificate has been issued.

It is a product risk, because switching to a substitute controller would change the system's timing and interrupt behaviour. The correct mitigation is therefore to extend hardware compatibility and timing testing across every candidate board now, which reduces the likelihood that the supplier situation affects the quality of the release and gives the programme a tested fallback some weeks before the current lead time expires.

It is a project risk, and the correct treatment is mitigation by testing earlier: pulling the integration test level forward and running it against simulated controller inputs reduces the impact of the delay, because the defects will already have been found by the time the boards arrive and only a short confirmation run on the real hardware will remain before the release can be approved by the programme board.

It is a project risk that should be accepted and then closed in the register, because a risk that the test organization cannot influence through any test activity falls outside test management and belongs to the procurement function to handle under its own supplier governance process, with the test team simply informed of the revised delivery date once procurement has confirmed a new supply date.

Grant the programme a full exemption from the organizational strategy and let it define its own standalone test strategy for its duration, because a project that cannot comply with two central rules cannot meaningfully claim to follow the strategy at all. The exemption is approved once by the quality board and recorded in the programme charter, and the organizational strategy is then applied unchanged to the next project that starts, so that the exemption stays an isolated case rather than a precedent.

Adapt the project to the strategy rather than the strategy to the project: batch the continuous releases into a monthly system test phase and apply to the gambling regulator for an exemption allowing a masked production copy to be loaded into the shared environment, because deviating from an approved strategy undermines the consistency and comparability of test results across the organization and weakens the audit position at licence review and at future audits.

Raise a deviation only for the test data rule, since that constraint is externally imposed by the licence conditions and cannot be argued with, and leave the lifecycle rule untouched, because the delivery cadence is a development concern rather than a testing one; the system test level can stay documented exactly as written and simply be executed once each quarter against the changes accumulated in the shared environment since the previous run.

Test resources and the SDLC model dominate: the regulatory documentation burden is fixed and cannot be negotiated, so the only variables the test manager can genuinely plan around are the staffing available, the tooling budget and the delivery cadence chosen for the increments. The strategy is therefore built from the team's capacity and its two-week rhythm, with the regulated obligations treated as a constant background condition that the site quality function discharges in parallel.

The project goals and the project type dominate, because a test strategy is tailored to the individual project and to the objectives set for it. The regulated domain is an organizational-level constraint that the company's existing quality management system already satisfies through its standard operating procedures, so it need not shape this project's own test strategy beyond a reference to those procedures in the project test plan and its approval record.

The availability of test data and the interfaces with other systems dominate, because validation evidence in this domain is generated from data-driven runs across the connected plant equipment, which makes access to realistic batch data and to the still-unspecified plant interfaces the binding practical constraints on the entire test strategy and on the sequence in which the required evidence can be produced and submitted to the regulator.

The case is sound in principle, since an open source licence genuinely removes the acquisition cost from the calculation, but it should be strengthened before submission by benchmarking two further open source frameworks against it on interface coverage and reporting capability, and by extending the evaluation horizon from one year to five years, so that the 20 person-day setup is amortised over a longer period and the committee sees a cumulative saving rather than a first-month payback figure that it is likely to treat as optimistic.

The main flaw is the unit of measurement: expressing the saving in person-days rather than in currency prevents the steering committee from comparing this proposal against the other investments competing for the same capital budget in the same period. Converting the 400 person-days at the loaded engineer rate, adding a 20 per cent contingency to absorb estimation error, and restating the payback in budget months would make the case acceptable in the format the committee already uses for tooling proposals.

The main flaw is that no pilot has been run: the decision should be deferred until a proof of concept on one subsystem has demonstrated that the framework drives the flow management interfaces reliably and produces usable defect reports. Once technical fit has been established in that way, the same cost and saving figures can be carried into the final business case unchanged, because a successful pilot confirms the assumptions on which they rest.

At least 90 per cent of the test cases planned for this increment have been executed by the gate date, irrespective of their outcome, because execution progress is the most objective and readily available indicator at the point when the gate is assessed.

The test effort consumed by the increment is within the estimated number of person-days and the team has recorded no overtime during the increment, demonstrating that the testing was performed in a controlled and sustainable manner.

Test progress reports are produced only when an exit criterion has been missed and report the status of testing against the defect database, because reporting at fixed intervals would spend tester effort on information that stakeholders have not asked the test team to produce.

Test progress reports are produced once per test level after execution has finished and report the status of testing against the number of defects still open, because a status statement is meaningful only when every planned test case has been run.

Test progress reports are produced at regular intervals but report progress against the development team's build schedule, because their purpose is to tell stakeholders which build reached the test environment rather than how testing itself is advancing.

Grouping defects by status supports the decision on which additional test level to introduce in the next release, because the status of a defect report records the lifecycle phase in which the defect was originally introduced.

Grouping defects by test level supports the decision on the order in which the open defect reports are triaged, because the test level in which a defect was found determines how urgently the fix has to be delivered.

Grouping defects by severity supports the forecast of how much regression testing effort each developer will need, because the severity rating is a direct expression of the size of the code change required for the fix.

Estimation produces only a duration in calendar days, since effort and cost follow mechanically from the duration once the team size is fixed, and quality sits outside the triangle because it is owned by the development team.

Estimation produces effort in person hours for sequential projects and in story points for Agile projects, but the time-cost-quality triangle applies only where effort is measured in person hours, because story points already contain a quality allowance.

Estimation produces the cost of the test environment and of the test tools, while effort and time are planning inputs supplied by the project manager, and the triangle is used to decide which test techniques to select.

The estimate must cover test execution alone, because test planning, analysis and design are management overhead already carried by the overall project estimate, while the test environment and the test data are delivered ready for use by the operations team.

The estimate must cover the whole project, because a test estimate that leaves out development effort, requirements work and deployment cannot be compared with the budget that the project manager holds for the release as a whole, and the test manager is accountable for that comparison.

The estimate must cover the test activities but leave out test environment setup and test data preparation, because those are one-off infrastructure tasks whose cost belongs to the environment budget rather than to the estimated effort of the testing activities.

REJECTED means the fix was delivered but failed confirmation testing, DEFERRED means the report is waiting for a test environment, RE-OPENED means a duplicate was merged into an existing report, and CLARIFICATION means the severity rating is still under discussion in the triage meeting.

REJECTED and DEFERRED are both terminal statuses in which no further action on the report is possible, while RE-OPENED and CLARIFICATION are informal annotations that a tester adds to the description rather than genuine statuses that the defect workflow recognises.

REJECTED means the defect was found outside the agreed test scope, DEFERRED means the defect has low severity, RE-OPENED means the same defect was reported again in a later release, and CLARIFICATION means the root cause analysis of the report is still running.

The committee is made up of test managers only so that its decisions stay independent of the development organisation, the triage meeting decides the technical root cause of each report, and the defect manager assigns the developer who will implement each fix in the next sprint.

The committee reviews the severity ratings entered by testers and corrects them, the triage meeting is held once at the end of each test level to close the remaining reports, and the defect manager acts as the deputy of the test manager during test execution.

The committee is responsible for the test completion report, the triage meeting is a discussion between the tester and the developer who received the report, and the defect manager maintains the defect management tool configuration for the tool administrator.

As many fields as the tool supports should be made mandatory from the start, because data that is not captured at the moment of discovery can no longer be reconstructed later, and unused fields cost the team nothing once the template has been configured in the defect management tool.

Severity and priority should be left out of the tester's part of the template and derived by the tool from the test case that failed, so that the two ratings stay objective and the tester only has to describe the behaviour that was actually observed in the session.

Steps to reproduce and the software version should be optional fields so that reports can be raised quickly during exploratory sessions, and the missing details can then be added by the developer who picks the report up at the next triage meeting of the committee.

Move the report to REJECTED because eleven unsuccessful reproduction attempts on the same build and environment establish that the reported behaviour is not a defect in the product but an observation error by the tester.

Move the report to DEFERRED so that it stays in the backlog for the next release, because the duplicated audit entry has no direct effect on the rates offered to guests and can be investigated when the team has more capacity.

Move the report to RE-OPENED and assign it to a second developer, because a report that one developer could not reproduce has to be independently confirmed by another before any further status change is allowed.

Low severity and low priority, because the failure has been observed only twice in three years and none of the three pilot depots can currently produce the concurrent-editing condition, so the impact on the delivery is negligible.

High severity and equally high priority, because a defect that causes unrecoverable data loss has to be fixed before a contractual delivery whatever the operational context of the pilot depots and their shift patterns turns out to be.

Low severity but high priority, because the technical fault is only a small locking omission in one save routine, while the reputational exposure at a contractual pilot delivery makes an immediate fix commercially urgent.

Categories for the affected architectural component, such as importer, parser, storage service and viewer, because knowing which component carries the most defects lets the team target its refactoring and its additional test effort where the risk is highest.

Categories for the severity band of the failure, such as study rejected, study degraded and cosmetic display fault, because grouping by operational impact shows which of the import defects justify immediate effort and which can be deferred to a later release.

Categories for the originating vendor system that produced the study, because tracing the reports back to the individual sending devices identifies the vendors whose conformance to the interface contract should be challenged before the next release of the archive is accepted into service.

120 working days, because 720 test cases at an average of 6.0 test cases per day is 120 days of work, and the variation between releases can simply be absorbed by the contingency already held in the project budget.

27 working days, obtained from the lowest observed throughput of 4.5 test cases per tester-day, since a metric-based estimate is only defensible when it is built on the worst measurement in the data set, after which the spread needs no further analysis.

16 working days, using the 7.5 test cases per tester-day achieved in the most recent release, because the newest measurement reflects the current tooling and team composition best and the two older releases should be dropped from the data set.

Both audiences should continue to receive the identical dashboard, because two different metric sets create two competing versions of the truth, and the steering group needs the component-level detail in order to challenge the development lead's judgement.

The steering group should receive only the raw counts of planned, executed, passed and failed test cases, because absolute counts are neutral facts whereas coverage and residual risk figures embed test-manager judgement that could bias the budget decision.

Quality is improving as expected late in a test level, because the defects found earlier have now been fixed and fewer failures occur, so the test manager should confirm that the exit criteria are within reach and support bringing the release date forward by one week.

Test execution productivity has fallen because the remaining test cases are longer and more complex, which also explains why they pass more often, so the test manager should report a revised throughput assumption and request two additional testers for the remaining weeks of the test level.

The blocked count is an environment and test data problem that sits outside the quality signal, so the test manager should report the rising pass rate trend unchanged and track the blocked cases separately in the impediment log until the environment lets them be run.

Wideband Delphi, because its facilitated discussion rounds are the mechanism by which modeling knowledge is transferred to a team that lacks it, so the additional calendar time it consumes should be accepted as an investment in the team's estimation maturity.

Wideband Delphi, because a sprint commitment requires an absolute effort figure in person-hours which only Wideband Delphi produces, and the extra calendar days that its separated rounds need can be recovered by shortening the sprint review and the retrospective.

Planning poker, because it is a metric-based technique that computes the estimate from the team's recorded velocity over its eleven completed sprints, whereas Wideband Delphi is expert-based and would need historical modeling data that this team has not collected.

The Test results group is affected, since a change of technology is recorded there, and the re-estimate can therefore be produced by scaling the current defect count by the relative size of the newly introduced component.

The Test context group is affected, since both the team change and the technology change alter the organisational context of the project, and the revised estimate should therefore be produced by the project manager rather than by the test manager.

In norming the test manager must still lead directively because the working rules have not yet been accepted by the members; in adjourning the same team is deliberately re-formed for the coming release so that the productivity it has built up is not lost again.

In norming the team reaches its highest productivity and works largely autonomously, so the manager can withdraw entirely; in adjourning the roles inside the team are renegotiated after individual members have left, and the manager rebuilds the working agreements from the beginning.

In norming the members still work as separate specialists while the test manager defines the whole test process alone; in adjourning the team stops raising new defect reports and performs only confirmation testing until the release is finally handed over.

Both approaches use four categories with identical content, and Feigenbaum simply names the second category appraisal cost where Boehm names it cost of detection, so the difference between the two syllabi is purely terminological and has no practical effect.

Feigenbaum splits quality costs by the organisational unit that carries them, such as test, development and support, while Boehm splits exactly the same costs by defect severity, so that critical defects are costed separately from minor ones.

The Feigenbaum categories cover only the costs arising after release while the Boehm approach covers only the costs arising before it, so a test manager applies the one during the project and the other during the warranty period that follows.

Qualitative benefits are the ones the test team measures for itself and quantitative benefits are the ones the finance department measures, so the manager reports the quantitative figures upward to the steering committee and keeps the qualitative observations inside the team as input to its own process improvement work at the end of the release.

Quantitative benefits are the defect counts and coverage figures produced during execution while qualitative benefits are the opinions gathered in retrospectives, and because opinions cannot be audited by the steering committee only the quantitative side can legitimately carry a cost-benefit argument.

Qualitative benefits are the benefits expected before the project starts and quantitative benefits are the ones actually measured after it has ended, so the manager needs both kinds in order to compare what was planned against the outcome that was finally achieved and to justify the next test budget.

The dominant demotivator is that testers have too much freedom in selecting their test techniques, which leaves them uncertain about what is actually expected of them; the manager restores motivation by prescribing one mandatory technique for each test level and reviewing its use in every status report.

The main demotivator is the defect management tool, because it makes each tester's individual output visible and comparable with that of colleagues; the manager should therefore stop reporting defect metrics to anyone outside the team and discuss them only in the team's own weekly meeting, where they cannot be compared between individuals.

Demotivation in test teams stems from the inherently repetitive nature of test execution tasks; the manager addresses it by rotating every team member through automation work in turn, so that manual execution no longer forms part of anyone's regular assignment during the release.

Training on the job is the primary route to methodological competence because the methods are applied directly on the real project, while self-study is the primary route to social competence because working alone develops the self-discipline and resilience a tester needs when defending findings under pressure.

Mentoring and coaching address professional and technical competence only, while training and education cover all four competence areas equally well, which is why formal classroom courses should be the default development measure for a test team whatever the competence gap identified in the skills matrix.

Peer learning develops methodological competence and formal training develops social competence, because a course is attended together with other participants from several organisations whereas peer learning is no more than a one-to-one exchange of method knowledge between two colleagues who already sit together on the same test team and share the same background.

EUR 206,000 in total; external failure costs are borne by the service and support budget after handover and are therefore reported outside the cost of quality, so the remaining split of EUR 138,000 against EUR 68,000 shows conformance costs dominating.

EUR 138,000 in total; cost of quality means only the money deliberately invested in order to attain quality, so prevention and appraisal are counted while the EUR 222,000 of failure figures is reported separately as the cost of poor quality.

EUR 222,000 in total; prevention and appraisal are planned project effort that would be spent on any release, so the cost of quality figure consists only of the internal and external failure costs of EUR 68,000 and EUR 154,000 that were actually caused by defects in the released system.

At most EUR 3,100 per defect, because that is the point at which the average external failure cost is fully offset by the appraisal and internal failure costs together, and the investment stops paying for itself only above EUR 4,200, the full external failure cost of a defect.

At most EUR 3,300 per defect, because the required saving of EUR 900 is deducted from the average external failure cost of EUR 4,200, and the investment stops paying for itself at EUR 4,200 per defect, where appraisal costs as much as a defect reaching production does.

At most EUR 6,200 per defect, because the external failure cost, the internal failure cost and the required saving are added together to give the amount the appraisal activity may consume, and the investment stops paying for itself only above that combined figure.

Test design, because reviews that break down mean the specifications the testers work from stay unreliable; the remedy is an advanced course in specification-based and experience-based techniques so that the team can derive test cases without depending on agreement with the developers and compensate by broader coverage.

Test planning, because a team that avoids raising concerns with the product owner will accept schedules it cannot meet; the remedy is training in test estimation techniques such as three-point and expert-based estimation, so that the plan is defensible on its own figures and can be presented to the stakeholders without any negotiation being required.

Test monitoring and control, because status reports from a team that argues with the developers will be distrusted by the stakeholders; the remedy is a tooling course on dashboards and automated status reporting so that the figures speak for themselves and are no longer coloured by the relationship.

Domain competence first and in full before any testing begins, since the test conditions are derived from the domain and the traceability regulation is unforgiving; technology and lifecycle competence can be picked up during execution once the first iterations are running, and the matrix afterwards records one nominated domain expert per subject area, so that the training effort is not duplicated across the team and each expert can be scheduled where the knowledge is needed.

Only the technology competence has to be acquired, because responsibility for the iterative lifecycle lies with the Scrum Master and the application domain is described in sufficient detail in the user stories themselves; the skills matrix is then replaced by a list of tool and platform certificates showing who holds which qualification and when it has to be renewed, which is easier to keep current than a competence assessment.

All three competences in parallel through a single combined classroom course covering cloud architecture, agile working and the traceability regulation, after which the skills matrix records every team member at the same target level, since a uniform competence level keeps iteration planning free of scheduling constraints and lets the test manager treat any team member as interchangeable with any other.