Test Manager Practice Exercise 02

Budget Crunch Decision

The CFO has just cut your Q3 QA budget by 30%. You have a product release in 6 weeks. What do you do?

Budget Cut Scenario

The Situation

You are Test Manager at KiwiPay, a Wellington payments SaaS with 80,000 customers. Q3 QA budget was $420,000 NZD. The CFO has cut it to $294,000 (30% reduction) due to macro headwinds. You have 6 weeks until the v4.2 release, which includes:

New direct debit initiation API (first release)
Refactor of the payments reconciliation engine (high risk)
15 minor UI bug fixes (low risk)
Performance improvements to the batch settlement job

Your current team: 3 senior SDETs, 2 manual testers, 1 test lead. Contractors for performance testing are $8,000/day.

Question: How do you allocate the remaining budget and what do you defer or cut?

Question 1 of 4

What is your FIRST action after receiving the budget cut news?

Why B is correct: Risk assessment comes first. You cannot make defensible decisions about what to cut until you understand the relative risk of each feature. Cancelling contractors or escalating to the CFO before you have a risk picture is reactive, not strategic. Shifting testers to automation mid-sprint is a distraction that won't help the current release at all.

Question 2 of 4

The direct debit API has never been released before. Given budget constraints, which test approach is most appropriate?

Why C is correct: First-release features have no historical baseline and no existing regression suite. The risk of an undetected defect is highest here, and in a payments context the cost of a live defect (customer impact, regulatory exposure, reputational damage) far outweighs the testing cost. Budget pressure should push you to cut low-risk work, not high-risk work. Deferring unilaterally is a business decision, not a testing one — it requires stakeholder sign-off.

Question 3 of 4

The 15 UI bug fixes are low-risk. What do you do with them under budget pressure?

Why B is correct: Risk-proportionate testing is a core Test Manager skill. Low-risk items warrant targeted, efficient coverage — confirm the fix works and scan adjacent functionality for unintended side effects. Full regression wastes budget that should go to the high-risk features. Skipping entirely removes your safety net. Unstructured exploratory time without a charter produces inconsistent results and no traceability.

Question 4 of 4

The CFO asks for a one-page risk register showing what the budget cut means for quality. Which approach is correct?

Why B is correct: The CFO is a business audience, not a QA audience. They need to understand business risk in business terms — which features are covered, which are not, and what happens if a defect gets through. A feature-level risk matrix translates QA decisions into business language. Option A is operational noise. Option C is legally and reputationally dangerous. Option D is an internal QA document, not a leadership communication tool.

What Would a Strong Test Manager Do?

Work through all four questions first, then reveal the model approach below.

The 5-Step Budget Crunch Response

Step 1 — Risk triage. Before touching the budget, produce a feature-level risk matrix. Score each work item on likelihood of defect and business impact. This becomes your objective basis for every subsequent decision.

Step 2 — Defer or cut low-value work. Low-risk items (the 15 UI fixes, cosmetic improvements) get reduced coverage first. High-risk items (new direct debit API, reconciliation refactor) are the last things you cut — they are where live defects cost the most.

Step 3 — Negotiate scope, not quality. If the budget cannot cover the full release safely, the right conversation is with the Product Owner or CTO: defer a feature, not its test coverage. Never silently reduce coverage on high-risk work without a documented decision.

Step 4 — Communicate risk formally. Produce the one-page risk register for leadership. Document exactly what will and will not be tested, why, and what the residual risk is. This protects the business and protects you.

Step 5 — Monitor and escalate. As testing progresses, if defect rates on the high-risk features exceed your predictions, escalate immediately. Budget pressure does not change your obligation to report emerging risk.

Sample Risk Register — v4.2 Release

Feature	Risk Level	Testing Decision	Budget Allocated
Direct Debit API (new)	HIGH	Full coverage — functional, edge cases, error paths, contract tests	$52,000
Reconciliation Engine Refactor	HIGH	Full regression + data integrity checks; contractor performance test (2 days)	$48,000
Batch Settlement Performance	MEDIUM	Contractor perf test reduced to 1 day; baseline comparison only	$18,000
15 UI Bug Fixes	LOW	Targeted smoke tests per fix; no full regression	$12,000

Remaining budget covers team time, tooling, and environment costs for the 6-week cycle.

Key principle: Never cut quality silently. Document what you are not testing and why. Protect yourself and the business.

NZ context: Under the NZ Consumer Guarantees Act and the Payments NZ API Centre standards, payment defects can trigger regulatory scrutiny. A direct debit API defect affecting customers is not just a reputational risk — it can attract attention from the Commerce Commission and Payments NZ. Make this visible to leadership in your risk register.