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?
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
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.
Weighted Trade-Off Matrix: Three Strategic Paths
Management decisions under budget pressure are rarely binary. A strong Test Manager can articulate multiple credible strategies and help leadership choose based on project context. Here are three valid paths, each with a defensible C-suite pitch.
| Path | Strategy | C-suite pitch angle | Risk score | Best when |
|---|---|---|---|---|
| A — Aggressive Automation Push | Convert manual headcount budget to tooling + contract SDET | "We cut cost AND improved long-term quality" | 3 / 5 | Project has > 9 months remaining; automation infrastructure exists |
| B — Risk-Based Scope De-scoping | Formally agree with stakeholders to stop testing low-risk areas; produce signed risk register | "All residual risk is owned by stakeholders, not QA" | 2 / 5 | Clear low-risk areas with clean defect history; strong stakeholder trust |
| C — Offshore Regression | Retain NZ team for exploratory; offshore structured regression to lower-cost provider | "25% cost reduction without reducing NZ headcount" | 3.5 / 5 | Mature test documentation; data sovereignty allows offshore access |
Strategy: Use the budget cut as leverage to accelerate automation investment. Redirect manual testing headcount budget to tooling and a contract SDET.
Pros: Lower ongoing maintenance cost within 12–18 months. Reduces human error on regression. Strong story for C-suite (“we cut cost AND improved quality long-term”).
Cons: High upfront risk — automation investment takes 3–6 months to yield coverage. If the project timeline is less than 6 months, the payback never arrives. Requires automation infrastructure that may not exist.
“I propose converting 2 FTE manual tester budget to 1 senior SDET contract plus tooling. By Q3 we will have 60% regression automation, cutting manual test execution time from 3 weeks to 4 days. The short-term quality risk is managed by risk-based prioritisation of what we test manually during the transition.”
Risk: 3/5 — Best when: project has > 9 months remaining, automation infrastructure exists, regression is the largest time cost.
Strategy: Formally agree with stakeholders to stop testing certain low-risk areas. Produce a signed risk register showing what is out of scope and the accepted risk.
Pros: Delivers the same deliverables on less budget. All risk is transparent and owned by stakeholders, not the QA team. Fastest to implement.
Cons: Political risk — stakeholders will later blame QA if a de-scoped area has a production defect. Requires strong stakeholder relationships and a very clear paper trail.
“We can deliver within the revised budget by formally de-scoping regression testing on the legacy reporting module (last major defect: 2023) and smoke-testing-only for the batch processing layer. I need sign-off on this risk register before we proceed — these are the specific areas we will NOT test and the consequence if they fail in production.”
Risk: 2/5 — Best when: project has clear low-risk areas with a clean defect history, strong stakeholder trust, and a governance culture that accepts formal risk acceptance.
Strategy: Retain NZ-based testers for exploratory and domain-specific testing. Offshore structured regression execution to a lower-cost provider.
Pros: Cost reduction without reducing NZ headcount. Preserves NZ domain knowledge for exploratory and edge-case testing.
Cons: Handover overhead and time-zone latency. Quality depends heavily on test script quality — if scripts are poor, offshore testers cannot compensate. Compliance risk if data cannot leave NZ (HealthNZ, Revenue NZ, Payments NZ data).
“We can reduce cost by 25% by offshoring structured regression execution to [partner] in the Philippines while retaining our NZ team for exploratory, accessibility, and domain-specific testing. Risk: we need 4 weeks to onboard and write execution-ready test scripts. A data sovereignty review is required before we proceed.”
Risk: 3.5/5 — Best when: test documentation is mature, data sovereignty allows offshore access, project has structured regression suites, timeline allows 4-week onboarding.