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

Issuing a control directive to re-sequence the remaining test execution after a slipped delivery date has pushed the highest-risk module to the end of the schedule

Archiving the testware and handing it over to the maintenance organisation after the release is accepted, together with restoring the test environment to its baseline state

It replaces the six project test plans, because maintaining plans on two levels would duplicate estimation, monitoring and reporting effort and create the risk of inconsistent exit criteria between the levels

It is the organizational test strategy, because any planning document that spans more than one project by definition sets the generic approach for the organisation rather than for a single piece of work

It is a master test plan for the first project (the card switch), which the other five project test managers copy and adapt for their own scope once their requirements are stable enough to plan against

The final list of closed defects, because the new project can reuse the defect count and severity profile directly as its expected defect volume when estimating retest effort

The restored test environment, because the new project can reuse the same hardware, configuration and access rights without new setup effort and therefore start execution earlier

The archived regression test cases, because the new project can execute them unchanged as its first test cycle and use the results as an early baseline of product quality

Run all four activities in parallel on all three environments from week 1 so that no environment is ever idle and every activity gets the maximum calendar time; resolve environment conflicts week by week in the daily stand-up, giving precedence to whichever activity is furthest behind its planned execution rate at that moment

Postpone performance testing to a post-go-live hardening phase because the external specialists are the most expensive resource and the month-end peak is still eight weeks away; use their two weeks of ENV-A time for additional exploratory functional testing by the internal team, which can start immediately without a frozen build

Give ENV-A to UAT for the whole six weeks because the 40 accountants are the paying customer and need a stable, production-like system with real-looking data; run performance testing and security penetration testing on ENV-B and ENV-C respectively in their booked weeks, and squeeze functional regression into the night shifts on whichever environment is idle

Apathetic: low influence and low interest, so she needs to be monitored and informed when something changes, without being drawn into decisions

Latent: high influence but low interest, so the test manager should keep her satisfied with concise summary reports and avoid overloading her with detail

Defender: high interest but low influence, so she should be kept informed in detail about progress and risks but not be involved in decisions

All test levels must use identical planning templates, metrics, tooling and exit criteria so that results can be aggregated in one report without transformation; any difference between levels would make the figures incomparable and would prevent the test manager from presenting a single consolidated view of quality to the steering group

Component testing needs the most formal planning, entry and exit criteria and reporting because it is the level where the majority of defects are introduced and found, whereas system testing can be managed informally by the test manager once all components have passed their own exit criteria, since its purpose is essentially confirmation

Test management activities apply at the system and acceptance levels; component and integration testing are development activities outside the test manager's scope, so they are neither planned nor monitored by the test manager and their results do not need to appear in the test plan or in the status reports to the project stakeholders

Usability and security testing are handed to the business acceptance testers, because they represent the end user and know how the marketplace will be used in practice, whereas the test team lacks the domain view needed to judge whether a screen is usable or whether an access rule is appropriate

Each test type is planned with the same resources and the same environment, because keeping one set of conditions makes results across the types directly comparable and avoids the cost and coordination effort of maintaining several environments and specialist tool sets in parallel

Non-functional test types are planned after functional testing has finished, because their results are meaningful once the functionality is completely stable; planning them earlier risks measuring performance and security of code that will change again and having to repeat the expensive test runs

The roles are the same in both models and the syllabus lists them as an aspect of comparison for completeness; in practice the vocabulary changes, with 'test lead' used instead of 'test manager' and 'sprint' instead of 'test phase', while the responsibilities and reporting lines remain as in a sequential project

In Scrum the developers take over all testing within the sprint and the test manager role is limited to organising acceptance testing arranged with the customer at release time, so the test manager is no longer involved in test planning, monitoring or defect management during the iterations

In Scrum a dedicated test manager per team replaces the independent test team, and each team's test manager plans the sprint's testing, tracks defects and reports test status directly to the product owner at the sprint review, so the number of test managers grows with the number of teams

Pass the gate, because the agreed criteria were defined against the March baseline and the report meets them exactly as written; note in the minutes that the 38 May requirements will be covered in acceptance testing and raise the question of re-baselining formally for the next release so that the gate criteria and the traceability matrix stay aligned

Postpone the gate meeting by two weeks until the coverage reaches 95 % against the new baseline and the four severity-2 defects are fixed, informing the steering group that testing is 'still in progress' without going into the baseline change, since presenting a failed gate would damage confidence in the test team and the delay is short

Pass the gate but formally reclassify the 38 new requirements as out of scope for this release, since they arrived after the plan was approved and could not reasonably be expected to be covered; add them to the backlog of the next release and mention the reclassification in the coverage section of the report so that the figures stay consistent

Risk-based testing transfers responsibility for undiscovered defects from the test team to the business stakeholders who rated the risks, since any defect in an item they rated low was accepted by them in advance, which protects the test organisation from blame after go-live

Risk-based testing reduces the total number of test cases needed to reach complete requirement coverage, so the same coverage is achieved with less effort and the saved budget can be spent on automation or on additional test cycles in later phases of the project

Risk-based testing makes a test plan acceptable to auditors and regulators, because standards and contractual frameworks expect a documented risk register as evidence that testing was planned systematically; without it the tolling system would not pass its compliance review

Checklist-based identification using the organisation's standard risk list

Risk workshop with the project team

Expert interview with the domain specialist

Random order chosen by the testers each morning from the open backlog, because the risks are distributed fairly evenly across the features and a fixed order would add planning overhead without benefit; the regulator's requirement will be met naturally by the time the pilot starts, and the data feed dependency resolves itself in week 3

Low risks first, because they are the most numerous and finishing 60 items early makes the progress report look best for the week-4 decision; the medium and high risks are then handled in the final week when the data feed is available and the team has already gained familiarity with the application

Depth-first: test the disruption-message feature exhaustively in weeks 1-3 using simulated feed data until the real feed arrives, then use the remaining time for a single pass over the other 14 features, since the six high risks are concentrated in one place and the syllabus says the highest risks should be tested first and most intensively

Test Risk C first because it is by far the most likely to occur, and a 40 % probability means the delayed confirmation e-mail will almost certainly be experienced by customers in the first weeks, whereas A and B are rare events that can be handled later

Test Risk A first because its exposure of 100,000 is the highest of the three and its test cases (commission calculations against a rate table) are the most easily reproducible, so the first cycle will produce the most reliable evidence for the money spent

Split the first cycle equally across the three risks because the probability estimates are too uncertain to justify ranking them; an even split protects the test manager against a wrong ranking and still gives some coverage of every risk before the second cycle

The number of risk workshops held during the project compared with the number planned in the test plan, which shows how consistently the risk-based process was followed

The total number of test cases executed across the project compared with the original plan, which shows how thorough the testing was overall and how well the effort was used

The percentage of regression test cases that were automated by the end of system testing, which shows how efficiently the test team applied its resources over the project

The test policy is the schedule and resource allocation for testing across all current projects, updated each quarter by the PMO to show which testers, environments and budgets are assigned to which project and where conflicts between projects are expected in the coming months

The test policy is the section of each project test plan that records which product risks the project has decided to accept without testing, together with the rationale and the stakeholder who approved the acceptance, so that the residual risk at release is documented for the steering group

The test policy is the detailed list of test levels, test design techniques, tools and entry and exit criteria that every project in the organisation must apply without deviation, so that projects are comparable and auditable across the portfolio and no project test manager has to make these decisions again

Make the platform fast enough during the busiest on-sale events of the season that customers do not complain on social media, measured by the perception of the customer service team after the first three major on-sale events following the go-live on 14 November

Ensure that no performance defect of any kind is present in production after go-live, verified by the absence of performance-related incidents in the operations log during the first full year of operation, and report the result to the steering group at the annual review

Run as many load tests as the pre-production environment allows between now and 14 November, using the maximum user count the load tool can generate, and record all results in the test management tool so that they can be analysed after go-live if problems occur

Test the card-data handling functions thoroughly during system test, using every applicable test design technique and the most experienced testers, so that PCI DSS problems are unlikely to reach the assessor and the compliance officer can prepare the evidence pack with confidence before the master deadline

By 30 June, obtain the external assessor's written acceptance of the PCI DSS evidence for card-data handling, with the system test team responsible for collecting the evidence during execution, so that the level plan and the master plan share the same measurable target and the same deadline

Complete all system test cases planned for the release by 31 May with at least a 90 % pass rate across the whole application and no severity-1 defects open, and hand the overall test summary report to the compliance officer as the input for the PCI DSS evidence pack that the assessor will review in June

Ask the product team to move to a two-week release cadence so that the sequential strategy with its four levels and weekly reporting fits without modification, since the strategy has been approved by senior management and a deviation would require a formal exception process that takes longer than changing the cadence

Apply the organizational strategy unchanged, because an approved strategy is binding for all projects and the pipeline can be configured to pause at the level boundaries until the weekly approval meeting has confirmed the exit criteria; the deployment frequency will fall, but the organisation's agreed quality process is preserved and the audit trail remains as it was designed

Discard the organizational strategy for this team, because continuous delivery has no separate test levels and therefore none of the strategy's content about levels, criteria and reporting is applicable; instead write a fresh project test strategy from scratch based on the team's pipeline and submit it to management as a proposal for a second, Agile organizational strategy

Extend the schedule by four months so that the two testers can fully implement the organizational strategy as written, including exhaustive scripted tests for all rule combinations, since a strategy approved at organisational level should not be tailored by an individual project; present the extension to the ministry as the cost of following the organisation's own quality standards for a rule-based system

Follow the organizational strategy and script every eligibility rule combination as it requires, because the domain factor (yearly changing rules with legal consequences) outweighs the resource factor; the two testers can cover the volume by working overtime during the last two months, and any incomplete scripts are finished by the ministry experts during their weekly half day, which keeps the strategy intact and the audit trail complete

Replace testing by the test team with acceptance testing by the ministry experts, since they know the eligibility rules better than anyone and the test team is too small to matter; the two testers then concentrate on environment preparation, test data and defect administration, and the deviation from the organizational strategy is justified by the fact that the domain knowledge sits entirely with the ministry rather than with the project

The process areas, which define for each maturity level the specific and generic goals an organisation must satisfy and thereby determine which practices are introduced first

The IDEAL cycle embedded in TPI NEXT, which prescribes that all key areas are diagnosed together and then improved simultaneously in each Acting phase before the next Learning phase

The five staged maturity levels, because each level lists the key areas that must be completed before the next level can be attempted, so an organisation improves in the order of the levels

Start from the metrics that the defect tracker, the test management tool and the pipeline already produce (defect counts by severity, requirement coverage, execution rates, build failures), formulate the questions that this data can answer about escaped defects, and then derive a goal that fits the answers, so that no new data collection has to be set up and the measurement programme can start immediately

Define a fixed set of metrics for the whole organisation covering defects, coverage and effort, ask each project the same set of questions in its monthly report, and set the goal for escaped defects as the average of all projects, so that every project is measured on the same basis and the payment module can be compared objectively with the other modules

Interview the business stakeholders for their questions about quality, publish the answers as measurable goals for the test team, and let each team pick whichever metric it finds convenient to demonstrate progress towards those goals, so that the measurement stays close to what the business actually asked and the teams retain ownership of their own metrics

Ask each person named on the timeline to explain their slip in turn, in the order of the milestones, so that the causes are heard directly from the people involved and the rest of the team can ask clarifying questions; collect the explanations on a flip chart and use them as the data set from which the improvement actions are derived

Present the delivery manager's timeline as requested at the start, since accurate data is the basis of the Collect data step and the names make the data concrete; ask the team to correct any dates they disagree with, and move on to deriving improvements once the timeline has been agreed by everyone present, keeping strictly to the one-hour timebox

Skip the introduction because the team members already know each other and the purpose of a retrospective is obvious after eight iterations; go straight to deriving improvements from the delivery manager's timeline so that the session stays within its one-hour timebox and produces concrete actions before people lose interest in another analysis of the delay

Introduction: the facilitator did not explain the purpose of the retrospective and the ground rules clearly enough, so the team did not take the outcome seriously and treated the agreed improvements as suggestions; the next retrospective should start with a longer introduction stressing that the actions are binding for everyone

Collect data: the team had too little quantitative data about the problems (no measurement of the data-refresh failures or of the rejected defect reports), so the next retrospective should start with a full metrics review from the tools before anything is decided, and improvements should be agreed for the problems that the data confirms

Derive improvements: three improvements were too many for a team of this size to absorb in one iteration, so the next retrospective should limit itself to a single improvement, vote on which one it will be, and defer the remaining two to later retrospectives so that attention is not split across several changes at once

The tool does not pay back within a meaningful planning horizon, because the licence is a recurring cost that continues for as long as the tool is used while the saving of 3 tester-days per week is a one-off estimate made before the automation exists; recurring costs against a non-recurring benefit make the case negative in every year after the first

The tool pays back in about 10 months, because the 50,000 implementation cost divided by the weekly saving of 1,200 (3 days × 400) is about 42 weeks; the licence fee is covered separately from the saving and does not need to be included in the payback calculation, which by convention compares the investment with the gross benefit

The tool pays back within the first year, because the annual saving of 3 × 400 × 52 = 62,400 exceeds the annual licence of 30,000 by 32,400; the 50,000 implementation cost is a capital investment that is depreciated over the tool's lifetime and therefore does not affect the first-year operating result

Custom tools turn out more expensive than commercial ones over their lifetime because of maintenance, documentation and knowledge transfer, so the commercial product must be chosen; the syllabus lists commercial, open-source and custom tools in that order of preference, and a custom build should be considered when no commercial or open-source product exists for the purpose

The proposal ignores that a custom tool cannot be retired without losing all the test data it has generated, so the organisation would be locked into maintaining it permanently; the syllabus tool lifecycle (acquisition, support and maintenance, evolution, retirement) applies to commercial tools, whose vendors provide migration paths, and a custom tool falls outside it

The proposal ignores that commercial tools come with training material, a support contract and a user community, so the custom tool would make the whole test organisation dependent on its two authors; if either of them leaves, the tool becomes unmaintainable, and the syllabus names this dependency as the main risk of the custom business type

Average time between a defect being reported and being fixed (defect lead time), measured per severity category

Number of test cases executed per hour on the automated regression environment, tracked per pipeline stage

Percentage of requirements with at least one linked test case, reported at each quality gate

Product metrics should not be used to assess processes or people, because defect counts describe the quality of the product under test and not the performance of the testers; the ranking mixed the categories of project, product and process metrics that the syllabus keeps apart, which is why the results are meaningless

Snapshot metrics are misleading and trend metrics should be reported instead, so a monthly ranking published as a single snapshot should be replaced by a weekly trend chart per tester; the trend would have shown the rise in rejected reports early enough for the test manager to intervene before triage became overloaded

Metrics must be collected automatically by a tool rather than by hand, because manual counting of defect reports is error-prone and testers may report their own figures optimistically; an automated count from the defect tracker would have shown the duplicates immediately and the ranking would have corrected itself

It is a data error in the test management tool, because the implemented and executed counts should be equal once system testing has started, since a test case is implemented precisely by running it for the first time; the test manager should reconcile the two figures before the report is distributed

It shows that 230 test cases were deliberately skipped because their risk was rated too low to justify execution in this release, which is the correct application of risk-based testing and should be reported as a conscious decision rather than as a shortfall against the plan

It means that 230 test cases have failed at least once and been removed from the active plan pending defect fixes, so the real pass rate is considerably lower than the 322 out of 380 that the report suggests and the programme manager should treat the reported figure with caution

Reporting two metrics halves the chance that a tool reporting error goes unnoticed, because a discrepancy between them immediately reveals which extraction is wrong, which is the main reason the syllabus recommends metric combinations

Steering groups are contractually entitled to at least two independent metrics per report under the programme governance framework, so a second metric is required for compliance with the reporting standard regardless of its content

Risk coverage is easier and cheaper to measure than execution progress because it is derived from the risk register rather than from the test management tool, and should therefore replace execution progress as the primary progress measure

Report the statement coverage of 45 % as the single completion figure, since it is the lowest of the three and therefore the most conservative statement of test completeness that the test manager can defend; presenting three different numbers to the product owner would invite cherry-picking and the gate decision should rest on one unambiguous measure

Agree with the product owner: requirement coverage is the primary measure in a requirements-driven project and 100 % with passed tests is the strongest possible statement of completeness; the code and risk figures describe implementation and planning detail that the business need not see at an acceptance gate, and reporting them at this stage would cause confusion about what 'complete' means, delaying the acceptance decision without changing it

Discard the requirement coverage figure because a value of exactly 100 % is suspicious and probably results from tests being linked to requirements without actually exercising them; re-run all 412 tests under supervision, recalculate the coverage, and postpone the gate until the recalculated figure has been confirmed by an independent reviewer from another project

Daily execution counts for every day of system testing, so that the vendor can reconstruct the test schedule and see how execution capacity was distributed over the phases of the project

The individual productivity of each tester in test cases per day, so that the vendor can benchmark its own staff against the client's team when it plans its maintenance test cycles

The list of test cases that passed at their first execution, so that the vendor knows which areas of the system were stable from the start and can exclude them from future regression

Person-hours are valid in sequential projects and story points in Agile projects, so a team must switch units when it changes lifecycle model; using hours in a Scrum team would undermine the relative estimation that the framework relies on, and the syllabus therefore treats the two units as belonging to two different estimation approaches

Story points measure the time an estimate takes to produce in a planning session, while person-hours measure the effort of the work being estimated; the two are therefore reported separately, story points as an indicator of estimation efficiency and person-hours as the actual test effort that appears in the project budget

Story points and person-hours are interchangeable units; a story point corresponds to a fixed number of hours agreed at project start (commonly one ideal day), so the test manager can convert her previous estimates directly and continue using the same estimation technique as before without recalibration

Product factors, because the defect count reflects the complexity and the quality of the product under test, which the original estimate underestimated and which must now be re-assessed

People factors, because a defect rate three times higher than assumed indicates that the developers are less skilled or less experienced with the technology than the estimate presumed

Test context factors, because the tools used during the cycle reported the defects and the test environment in which they were found is part of the context that the estimate must reflect

Decline to estimate until the new platform has been in production for at least one release, so that metric-based estimation on valid data becomes possible; offer the sponsor a time-boxed testing budget for the first release instead of an estimate, and explain that the syllabus regards estimates based on invalid historical data as worse than no estimate because they create false confidence

Apply the metric-based model from the four previous releases unchanged, because historical data is the most objective basis available and the sponsor has asked for a single figure; note in the estimate that the platform has changed, but keep the ratios as they are since adjusting them without new data would introduce subjective judgement into an otherwise data-driven estimate and make the number harder to defend to the sponsor

Run a full Wideband Delphi over two weeks with all stakeholders, including the sponsor, the architect, the testers and the development leads, iterating until consensus is reached; ask the sponsor to wait for the outcome, since an estimate produced in two days for a re-platformed system cannot be reliable and a wrong number delivered on time will cost more than a correct number delivered late

Estimate in story points from now on, because relative sizing is immune to the kind of drift shown here; a percentage-of-development-effort model inherits every error of the development estimate, whereas story points are calibrated by the team's own velocity each iteration and therefore cannot accumulate a systematic bias over several releases

Switch to planning poker as proposed, because three consecutive overruns of about 40 % prove that metric-based estimation does not work for this system; relative sizing by the whole team removes the dependency on outdated calibration data and the development lead's support for the change makes adoption easy, so the old model should be retired

Keep the metric-based estimate unchanged and add a 40 % management reserve to every future estimate, because the pattern is stable enough to absorb by a fixed contingency; the reserve is transparent to the sponsor, the model remains simple, and there is no need to spend effort on re-analysing historical data as long as the deviation stays within the observed band

Merge RESOLVED and CLOSED into one status so that the developer who fixes a defect can also close it, reducing the number of transitions and the waiting time for retest; keep REJECTED and DEFERRED as terminal statuses because reports that leave the main path should not re-enter it, and add a mandatory comment field to document the reason for rejection or deferral

Allow testers to move reports directly from OPEN to CLOSED so that duplicates and invalid reports can be removed quickly without developer involvement, and allow developers to move reports from IN PROGRESS to CLOSED for trivial fixes; keep REJECTED and DEFERRED as they are, since dead-end statuses prevent reports from circulating endlessly through the workflow

Remove the DEFERRED status entirely, because postponed defects should be deleted from the tool and re-raised when the target release starts, which keeps the open defect count accurate for the current release; REJECTED can stay as a terminal status since the developer's decision is final and any disagreement is handled outside the tool by the defect management committee

Raise 14 defect reports against the application, one per failed test, because each failed test must be traceable to a defect report for audit purposes and the triage meeting can reject them later; the rejection rate will show that the automation is unreliable and support a request for more maintenance effort on the regression suite

Raise one defect report against the application asking that expired contracts remain editable in test environments, because tests that depend on contract dates will keep failing at every month end; the report should be given high priority so that the change reaches the next build and the automated regression can run without further interruption

Delete the 14 failures from the run log so that the overnight pass rate is not distorted, refresh the data and re-run before the daily status report is issued; since the application behaved correctly, there is nothing to report and recording the failures would trigger unnecessary questions from the project manager about the stability of the regression suite

The developer and tester sit together and the defect is fixed within the same in-progress story before the story is ever delivered or demonstrated to the product owner

The team's definition of done requires all automated tests to pass and the coverage threshold to be met before a story can be moved to the done column

The product owner attends every daily stand-up and receives a verbal summary of the open defects from the testers at the end of each meeting

Defect management in a hybrid model is simpler because the vendor is contractually responsible for all defects in the back end, leaving the Scrum teams with their own backlog; a defect that spans the boundary is assigned to the vendor by default, and the contract's service levels replace the need for a shared workflow or agreed status model between the two sides

The issue is limited to tooling: once both sides use the same defect tracker with the same status names, the differences in cadence and process no longer matter, because every defect is visible to everyone at all times; the test manager's task is therefore to negotiate a single tool licence for the vendor rather than to design cross-model workflows or ownership rules

Hybrid models produce more defects than pure models because the integration between the sequentially developed back end and the incrementally developed app is not tested until acceptance testing; the challenge is therefore mainly one of volume, and the answer is a larger integration test phase before each quarterly release with a joint defect triage during that phase

Name of the developer who introduced the defect, so that individual training needs can be derived from the defect data by the team leads

Number of times the report has been viewed in the tool, as an indicator of how much attention each defect attracted from the team

Estimated market value of the affected feature, so that defects can be clustered by their business impact rather than by component

Make all 30 fields offered by the tool mandatory, including environment build number, browser version, reproduction frequency, business impact estimate and customer reference, so that whatever the auditor asks for later will already be recorded; the extra reporting effort per defect is small compared with the cost of a failed audit, and unused fields can be hidden from the reports without deleting the data

Add a mandatory field for the developer's estimate of the fixing time and one for the tester's confidence level in the reproduction steps, which together show the auditor how carefully each defect was analysed before and after the fix; keep requirement and test case references in the free-text description, where testers already mention them, to avoid adding more structured fields than the team can maintain

Keep the template unchanged and instruct testers to paste requirement numbers, the triage decision and the retest reference into the comments field using an agreed keyword format, since free text can be searched by the tool and the auditor can be given a saved query; adding mandatory structured fields would slow down defect reporting and the validation project is already behind schedule

Giving a developer critical feedback on a defect fix in the triage meeting without damaging the working relationship or escalating the disagreement to the project manager

Staying organised and productive when three releases are being tested in parallel and priorities are changed by the product owner at short notice several times a week

Knowing the insurance claims domain well enough to spot an implausible settlement amount in a test result and to judge whether a business rule has been implemented correctly

Herzberg's motivation-hygiene theory, which explains that the previous team lacked motivators such as recognition and responsibility and therefore lost interest before finishing; applying it, the manager should build recognition of completed work into the new team's routines rather than change its composition

The Tuckman model, which shows that the previous team remained stuck in the Storming phase and therefore kept generating competing ideas instead of converging on results; the manager should plan facilitated norming activities for the new team in its first weeks so that it reaches the Performing phase earlier

The skills matrix itself, extended with a column for years of experience and a column for the number of completed projects, because more experienced testers finish more work and the extended matrix would have revealed that the previous team consisted mainly of juniors without a completed programme in their history

Performing: the absence of conflict and the willingness to ask questions show that the team is already mature and self-aware, so the manager can focus on outputs, metrics and stakeholder reporting rather than on team development, and intervene in the team's internal working if the results deteriorate

Adjourning: the repeated questions about who does what indicate that the members expect the assignment to be temporary and are already planning their return to their previous teams, so the manager should secure lessons learned early and negotiate longer assignments with the line managers

Norming: the team is settling its ways of working and the politeness shows that agreements have already been reached, so the manager should step back, delegate decisions about task allocation to the team and act as a coach rather than as a director from this point on

Proficiency in the vendor's scripted execution tool for running the regression suite on schedule, so that the in-house team can take over the execution runs whenever the vendor's staff are unavailable during the release weekends

Skills in preparing and maintaining the physical test lab hardware used by the vendor's testers, including the card readers and mobile devices, since the bank owns the equipment and the vendor cannot be given administrative access to it

Ability to write daily execution logs in the vendor's reporting format, so that the in-house team can produce identical status reports and the bank's stakeholders do not notice a change in reporting style after the transition to the vendor

Mentoring by an external coach hired for three weeks to sit with the team and review their first test scripts, funded from the project's contingency budget rather than the training budget; an external expert brings knowledge of best practice that a single former user of the tool does not have, and the coaching format makes the learning specific to the team's own APIs

Formal training and education: wait for the next budget cycle and send all six testers on the vendor's certified three-day course, using the intervening weeks for manual testing of the APIs; a certified course gives a consistent level of knowledge across the team, which peer-led sessions cannot ensure, and the delay of one quarter is acceptable for a tool that will be used for years

Self-study by each tester using the vendor documentation and public tutorials, with a written test at the end of the three weeks to confirm the level reached; self-study fits the budget, lets each tester learn at their own pace, and avoids taking the experienced team member away from her own test assignments during a period when the team is already short of capacity

Saving per defect 5,000 − 600 = 4,400; saving per release 40 × 4,400 = 176,000, since appraisal is the cost of finding the defect and the fix cost is part of development

Saving per defect 5,000 + 300 − 600 = 4,700; saving per release 40 × 4,700 = 188,000, since the internal failure cost is an amount recovered by finding the defect early

Saving per defect 5,000 − 200 − 600 − 300 = 3,900; saving per release 40 × 3,900 = 156,000, since all three cost categories incurred before release must be deducted

The changes were too small to cross the threshold at which a hygiene factor becomes a motivator; doubling the salary increase and giving each tester a personal hardware budget would convert the same factors into motivators and the engagement figures would follow within the next survey period

The survey is unreliable because engagement and initiative are personality traits that cannot be influenced by management action within a few months; Herzberg's model applies to dissatisfaction, which the survey correctly shows to have dropped, and the manager should regard the intervention as fully successful

The changes were motivators, but according to Herzberg motivators take effect gradually over six to twelve months as employees come to trust that the improvements are permanent, so the manager should repeat the survey after a year before drawing conclusions about engagement and initiative

A net saving of 298,000, because 20 defects × 15,000 = 300,000 of production cost is avoided and a mere 20 × 100 = 2,000 is spent on fixing the defects at the review stage; the 60,000 review cost is a prevention cost that belongs in a different category and is not netted against failure cost savings

A net cost of 58,000, because the review costs 60,000 and fixing 20 defects at 100 each costs 2,000, while the production costs of 15,000 per defect are hypothetical figures that cannot be counted as a saving until the release has actually been in production without those defects

A net saving of 210,000: 20 × (15,000 − 1,500) = 270,000 minus the 60,000 review cost, because without the review the defects would have been found in system testing at 1,500 each, so the comparison must be made against the system test cost rather than the review cost

Social competence first: the team should attend communication and negotiation training because regulators and quality managers are demanding stakeholders who will challenge every test result; once the team can present its findings convincingly, the domain and lifecycle knowledge can be acquired gradually on the job, and the acquired firm's existing testers can handle the formal documentation during the transition period

None of significance: exploratory skills transfer directly to any product and the regulator mainly cares that testing was performed and recorded, so the team should keep its current way of working, add a document template for test sessions and a traceability spreadsheet maintained by the test manager; retraining eight experienced testers in formal techniques would cost more than the audit risk justifies and would demotivate a team that has been successful for years

Technology first: the team must learn embedded C, real-time operating systems and hardware debugging before any other skill, because the pump firmware is what the regulator will scrutinise most closely and testers who cannot read the code will not be able to design meaningful tests; formal documentation and traceability practices can be learned later from the acquired firm's quality department, which already has templates and procedures in place