Test Lead Interview Prep

I start by reading every input document I can get — the project charter, architecture decision records, business case, and any existing risk register — before writing a single line of the strategy. From those I identify the system under test, the stakeholders, and the non-functional quality attributes that matter most, whether that’s performance SLAs, privacy obligations under the Privacy Act 2020, or accessibility requirements under the NZ Web Accessibility Standard. The strategy then captures scope, out-of-scope areas, risk-based prioritisation logic, test levels and types (unit, integration, system, UAT), entry and exit criteria, environments, data strategy, tooling, and the defect management process. I always include a one-page executive summary so a non-technical stakeholder can understand what we’re testing and why. I treat it as a living document — version-controlled in Confluence or similar — and I schedule a checkpoint after the first sprint to update assumptions. A test strategy that isn’t revisited becomes fiction within four weeks of a real project.

I map every major test activity to a business outcome. If the project goal is to reduce call centre volume by 20%, I ask: which user journeys, if broken, would send customers to the phone? Those become Tier 1 in my risk model and get the most thorough coverage. I run a short discovery session with the product owner and sometimes the business sponsor to understand what “done” looks like from their perspective, which often differs from what engineering considers done. In NZ government projects I’ve worked on, the business goal was typically “move citizens off paper forms” — so usability, accessibility, and browser compatibility on mobile were as critical as functional correctness. I document that mapping explicitly in the strategy so if scope is cut later, we can have an honest conversation about which business outcomes are now at risk. Alignment stops being theoretical once it’s written down and signed off.

I don’t try to write the full ISTQB-shaped strategy document in that situation — there isn’t time and it won’t get read. Instead, I run a two-hour risk storming session with the team to surface the top ten things that could go wrong and rank them by probability and business impact. That list becomes an immediate working test plan: what we’re definitely testing, what we’re consciously skipping, and what we’re doing manually versus automating. I put that in a single Confluence page, get sign-off from the PM and tech lead within 24 hours, and start executing against it. Alongside that, I start building a lightweight strategy document that will outlast the release — it captures the decisions we made and the trade-offs we accepted. This approach gives the team clarity now and leaves an audit trail that matters for post-release retrospectives and any future Security, Privacy, or Audit reviews under the Public Records Act.

I pick metrics that tell a decision-maker something they can act on. The core set I use is: defect escape rate (defects found in production vs. found during testing), test execution progress against the release plan, open defect age by severity, and blocked test cases with reason. I avoid vanity metrics like total test cases written unless they’re tied to coverage of specific risk areas. For executive reporting, I translate everything into risk language — “We have three open High defects in the payment flow with no fix ETA; that represents a financial and reputational risk to the organisation” lands differently than “3 Highs open.” I also track flaky test rate and automation health separately, reported to the engineering lead rather than the business. Reporting cadence matters: I do a brief weekly written update and a verbal five-minute stand-up with the PM; I only call an emergency meeting when something genuinely changes the release decision.

Exit criteria must be agreed before testing starts, not negotiated on release day when everyone has deadline pressure. I define them in the test strategy with specific, measurable thresholds: for example, zero open Critical or High defects, no more than five open Mediums with documented mitigations, 95% of planned test cases executed, regression suite passing at 98% or above, and performance tests meeting the agreed SLA. I get sign-off on these from the PM, tech lead, and ideally the business owner at strategy kick-off. When release day comes, I produce a go/no-go report that scores each criterion objectively. If we fail a criterion, I make a recommendation but the final release decision belongs to the business — my job is to make sure they understand what risk they’re accepting. On one project at Auckland Council, we shipped with two known Mediums by exception because the commercial deadline was contractual; both defects had documented workarounds, and we monitored closely in production for the first 48 hours.

The NZ Government’s digital transformation agenda centres on the Te Ara Manaaki (Digital Inclusion) and Digital Strategy for Aotearoa priorities, which emphasise inclusive, secure, and trustworthy services for all New Zealanders. When writing a strategy for a government agency, I anchor quality risk areas to those goals: accessibility under the NZ Web Accessibility Standard 1.1 (WCAG 2.1 AA) is non-negotiable, not a nice-to-have; privacy testing must address obligations under the Privacy Act 2020 and any applicable Information Privacy Principles; and security testing must align with the NZ Information Security Manual. I also include interoperability testing because government systems frequently need to exchange data across agencies through the AoG Common Capabilities framework. I reference the Agency’s own Digital Service Design Standard where it exists — for example MBIE or DIA have their own standards — and I ensure the strategy is reviewed by the agency’s Privacy Officer and CISO, not just technical stakeholders.

I use a two-axis view: risk of the feature (how damaging is a defect here?) and complexity of the testing (how much domain knowledge or technical skill does it take?). High-risk, high-complexity work goes to my most experienced testers. High-risk, lower-complexity work is an excellent growth opportunity for mid-level people who are ready to stretch — I pair them with a senior for the first iteration so they get real feedback without the project carrying unmitigated risk. I’m also deliberate about matching domain knowledge — if someone has a background in financial services, they’ll catch edge cases in a payment module that a tester from a different domain simply won’t see. I document assignments in the test plan and hold a brief daily sync so blockers surface early rather than at end-of-sprint. And I rotate assignments across sprints intentionally; the same person doing the same module for months creates knowledge silos and kills motivation.

My first step is a private, direct conversation — curious not accusatory. There’s a real difference between “can’t” and “isn’t” and “won’t,” and I won’t know which I’m dealing with until I listen. Sometimes the answer is personal circumstances, unclear expectations, or they’ve been assigned work beyond their current skill level without enough support. If it’s a skill gap, I put a specific development plan in place: paired sessions, knowledge-sharing in the team, clearer written templates for what “good” looks like, and regular check-ins. If it’s about motivation or engagement, that’s a different conversation, and I loop in my manager. I set clear, written expectations with a specific timeframe — “by end of next sprint I expect X” — and I follow up consistently. If there’s no improvement after genuine support, I escalate through the people manager and HR process; I don’t manage around performance problems because they’re unfair to the rest of the team who are delivering.

I prepare before they arrive: I make sure their environment access, tooling licences, and Confluence permissions are sorted on day one, because nothing kills momentum like waiting three days for a JIRA account. Week one is about context — I walk them through the system architecture, the domain, the test strategy, and the defect workflow. I assign them a buddy (a mid-senior tester, not always me) who they can ask without feeling like they’re wasting the lead’s time. Their first real testing task is a lower-risk feature so they can build confidence and learn our conventions without being on the critical path. By the end of sprint one they’re pair-testing with an experienced team member on something meaningful. In sprint two, they take ownership of a test case set with review from me. I do a structured 30-day check-in to surface any blockers early — the most common one I’ve encountered is that new starters don’t know what they don’t know, so you have to ask specific questions, not just “how are you going?”

The key is blameless framing from the start. I open every debrief by stating explicitly that we’re looking at systems and processes, not pointing fingers, and I reinforce that by speaking in system terms myself — “our regression suite didn’t cover this scenario” rather than “so-and-so missed this.” I prepare a short data pack beforehand: defects that escaped to production, how they were discovered, which phase they were introduced in, and what our coverage of that area looked like. For each escaped defect we run a lightweight five-whys to find the root cause. Then we convert findings into specific, owned actions — “add a regression test for null payment reference by end of sprint” with a named person, not “we should test payment edge cases better.” I follow up on those actions in the next retrospective. Debriefs that produce vague takeaways are the ones teams stop caring about; debriefs that produce concrete changes to the test suite or process earn trust over time.

I separate QA-specific retrospectives from the team retrospective — there are quality concerns the testers need to discuss amongst themselves that aren’t appropriate to raise in front of developers or the PM, such as whether test environments were stable enough or whether requirements were clear when testing started. I run a monthly QA retro using a simple Start/Stop/Continue format, but I rotate the format occasionally — a timeline retro or a health check radar works well for longer releases. The most important discipline is reading back the actions from the previous retro at the start. If last sprint’s actions weren’t done, we talk about why before adding new ones. I limit actions to three per retro so they’re achievable, and I track them in a visible backlog. Over time this builds a culture where testers see that raising an issue in the retro actually changes something, which encourages candour rather than learned helplessness.

I start by understanding why testing is seen as a bottleneck — usually it’s because testing is at the end of the pipeline so every upstream delay lands on QA. I address that structurally first: shift-left by getting testers into sprint planning and story refinement, so we’re writing acceptance criteria before a single line of code is written. That alone cuts late defect discovery significantly. On the culture side, I make quality wins visible — I name in the team meeting when a tester caught a P1 before it hit production, and I quantify the cost of what was avoided. I also involve developers in exploratory testing sessions, not to offload work but to build shared ownership of quality. I’ve found that a developer who has spent two hours trying to break their own feature writes better code for the next sprint. In NZ organisations, particularly the more flat-hierarchied ones, this collaborative approach works well because testers aren’t siloed gatekeepers — they’re quality advocates embedded in the team.

I learn what format matters to each PM early in the project — some want numbers, some want narrative, some want a RAG status in a dashboard they can check asynchronously. I default to a weekly written status that follows a consistent structure: overall RAG, percentage of test execution complete vs. plan, defect summary (how many open per severity, how many closed this week), key risks, and what I need from them. I keep it to half a page. I also have a standing five-minute verbal check-in at the start of the week to flag anything that might affect their reporting to the steering committee. I only call an unscheduled meeting when something materially changes the release picture — a critical defect with no ETA, an environment outage that’s blocked execution for more than a day, or a scope change that invalidates a portion of the test plan. PMs learn to trust consistent communicators and become anxious around people who are quiet until something blows up.

I make my recommendation clearly, in writing, with evidence — specifically which exit criteria are not met, what the open defects are, and what the realistic risk is to end users if we ship. I don’t frame it as “we can’t release” because that’s not true and it puts the PM’s back up. I frame it as “here is what we know, here is what we don’t know, here is my recommendation, and here is what releasing with known risk looks like.” Then the release decision belongs to the business — not to me. My professional obligation is to ensure the decision-maker has accurate information and that my recommendation is on record. If they decide to ship over my objection, I make sure that’s documented and I help plan the monitoring and rollback strategy so we can respond fast if something goes wrong in production. What I won’t do is quietly agree and then distance myself if it fails — that’s neither professional nor helpful to anyone.

I surface the conflict explicitly rather than trying to serve two masters quietly, which always ends badly. I bring both stakeholders into a single conversation — or if that’s politically difficult, I go to the project sponsor — and present the conflict as a resource and risk trade-off: if we prioritise X, here is what Y gets and vice versa. I document that discussion and the agreed priority in the test plan immediately. Conflicting priorities are often a symptom of unclear project governance rather than individual stakeholders being unreasonable. On larger NZ government programmes, this typically means getting an escalation decision through the project board, because that’s the correct channel under Crown project governance frameworks. The one thing I don’t do is make the call myself without escalating — choosing between two senior stakeholders’ priorities is a business decision, not a QA decision, and making it unilaterally creates political problems that outlast the project.

My immediate response is not to agree or object, but to ask: what is driving the 30% figure? Sometimes there’s genuine budget pressure; other times it’s a negotiating position and the real number is flexible. Once I understand the constraint, I bring a risk-adjusted proposal rather than just cutting 30% proportionally across all test areas. I identify which areas I can reduce with low risk (stable modules, high automation coverage, low business impact) and which areas I cannot reduce without materially increasing the chance of a production incident. I present this as a trade-off menu: “We can save 30% by doing A, B, and C, which carries the following risks. We cannot reduce D and E without accepting this specific defect exposure.” That puts the decision where it belongs. I also document the final scope reduction and its rationale so there is no ambiguity if a defect escapes in an area we chose to reduce coverage on.

I lead with the business question the client cares about — is the product ready for their users? — not with test case counts or defect severity taxonomy. I use plain language: “We found and fixed 14 problems during testing. Three lower-priority issues remain; they affect the export report but not the core workflow your team uses daily. We recommend releasing with monitoring on those areas.” I use visuals where possible — a simple red/amber/green dashboard that shows progress over time, or a one-page summary with no more than five key points. I avoid acronyms (P1, P2, UAT) unless I define them immediately. For NZ clients, particularly in the public sector, I find that relating quality risk to citizen outcomes resonates strongly: “If this issue weren’t caught, a citizen submitting a consent form could have received a duplicate reference number.” Concrete and human lands far better than technical metrics with someone who isn’t living in JIRA every day.

Resistance to new tools is almost always rational — people have been burned by tool adoptions that created more work than they saved, or tools that were mandated from above without the team having a say. I start by involving the team in the evaluation: a small group trialling two or three options and reporting back creates ownership rather than imposition. I also frame the tool around the problem it solves — “we are currently spending four hours a week managing test evidence in spreadsheets; this tool reduces that to 20 minutes” is a compelling pitch where “management wants us to use this” is not. I pick a low-risk pilot, support people through the learning curve with pair sessions and documentation, and I declare a deliberate review point after eight weeks where we honestly assess whether it’s working. In New Zealand, particularly at mid-sized organisations and government agencies, licensing cost is always scrutinised; I make sure I can defend the per-head cost with a concrete productivity or risk reduction argument before I take it to leadership.

Environment instability is one of the biggest hidden productivity killers in QA and it’s chronically underreported because testers often just absorb the pain quietly. My first step is to make it visible: I track blocked test hours against each environment incident and report it explicitly to the PM so it shows up in project risk. That reporting usually accelerates the infrastructure conversation. I work with DevOps or the platform team to establish an environment booking protocol and a change freeze during UAT periods — ideally with a dedicated test environment that is not shared with development. I push for infrastructure-as-code so environments are reproducible and I advocate for environment health dashboards that flag issues before the testers hit them. Where that’s not achievable in the short term, I build environment check smoke tests that run at the start of each day and alert us immediately if something is broken, rather than having the team spend an hour debugging a data problem that turns out to be a misconfigured endpoint.

I build the case in three parts: current cost, risk cost, and automation cost with projected payback. Current cost: how many person-hours does our regression cycle take per sprint, multiplied by fully-loaded day rate, gives a dollar figure. Risk cost: what has a production defect cost us historically — incident response, PR, lost customer transactions — and what is the probability of repeating that without better coverage? Automation cost: tool licensing, initial script development time (typically three to four times the manual execution time), and ongoing maintenance, usually 15–20% of initial build per year. I model the payback period, which is typically six to twelve months for a well-scoped automation programme. I also set honest expectations: automation is not a one-time cost and badly written automated tests cost more to maintain than they save. I propose starting with a focused scope — the regression suite for the five highest-business-value user journeys — rather than trying to automate everything, which is the most common mistake I’ve seen teams make.

I use three filters. First, repetition: tests that run every sprint against stable functionality are strong automation candidates; tests that run once for a specific release are not worth automating. Second, stability: if the UI is changing weekly, automating against it costs more in maintenance than it saves; automate at the API or service layer instead. Third, human judgement: exploratory testing, usability assessment, and anything requiring contextual interpretation of “does this feel right?” must stay manual — automation finds what you asked it to find. In practice, for a mature NZ SaaS product I aim for automated coverage of the critical path and core regression, with manual effort focused on exploratory, edge-case, and new-feature testing. For a government project on a tight schedule with a once-off delivery, I’d lean heavier on manual because the automation investment won’t be recouped. The worst outcome is automating tests that nobody maintains, which gives a false green signal while the application drifts.

Twenty percent flakiness is a crisis, not a minor annoyance, because it means the team has stopped trusting the suite — and an untrusted test suite is worse than no suite because it creates noise that masks real failures. My immediate action is to quarantine the 40 flaky tests: move them to a separate run that doesn’t block CI and tag them as known unstable. This stops the false alarms without deleting tests that may cover real risk. I then prioritise the flaky tests by business impact and investigate each one for root cause: are they hitting timing issues (needs explicit waits), test data collisions (needs isolated data), environment dependencies (needs stubbing), or genuine application race conditions that the test is correctly exposing? I fix them root-cause-up rather than adding retry logic as a band-aid — retries mask problems. I also establish a flakiness SLA going forward: any test that fails intermittently three times without an obvious reason gets quarantined immediately, so we don’t accumulate technical debt in the suite again.

AoG procurement contracts for testing tools, cloud services, and professional services mean that tooling choices are often pre-determined or constrained by what’s on the AoG panel, and I need to design my test approach within those constraints rather than assuming I can bring in any tool I prefer. More relevantly, AoG contracts typically have specific Service Management and delivery obligations — SLAs, reporting requirements, and sometimes mandated testing gates — that must be reflected in the test strategy. For example, if the project is using an AoG cloud IaaS contract, the environment provisioning timelines and change approval windows are governed by the contract, which directly affects my environment schedule. I read the relevant contract schedule at the start of every government project to understand what testing-related obligations are embedded in the procurement vehicle. I also need to understand whether the deliverable requires Government Procurement Rules compliance documentation, because Test Strategy and Test Completion Reports are frequently referenced in Gateway Reviews and project audits.

Health New Zealand is subject to the Privacy Act 2020, the Health Information Privacy Code 2020, and the Health (Retention of Health Information) Regulations 1996, all of which have direct implications for how I approach test data and security testing. My first principle is that no real patient data is used in test environments — ever. I work with the project team and the agency’s Privacy Officer to establish a synthetic data generation approach or a rigorous de-identification process before test data leaves production. I include specific test cases for the Information Privacy Principles: data minimisation (are we collecting only what we need?), access controls (can only authorised roles see a patient’s record?), retention (does the system correctly handle deletion or archival at end of the retention period?), and breach notification (does the system log access and support an audit trail that could be produced to the Privacy Commissioner?). I also test that any third-party integrations — labs, pharmacies, ACC — are transmitting health information only over encrypted channels and that API responses don’t leak PII in error messages.

New Zealand government websites and apps are required to meet the NZ Web Accessibility Standard 1.1, which mandates WCAG 2.1 Level AA compliance. I treat accessibility as a first-class quality attribute, not a post-launch audit activity. I include accessibility acceptance criteria in every user story — keyboard navigability, screen reader compatibility, sufficient colour contrast, alt text on images, form label associations — so developers build with it from the start rather than retrofitting. My test suite includes both automated accessibility checks using tools like Axe or WAVE (which catch roughly 30–40% of WCAG issues reliably) and structured manual testing with a screen reader, typically NVDA on Windows and VoiceOver on macOS. I also involve at least one real user with a disability in UAT where feasible, because automated tools and sighted testers miss interaction patterns that assistive technology users encounter naturally. I report accessibility defects at the same severity level as functional defects — a Critical accessibility barrier that prevents a user from completing a task is a P1, not a cosmetic issue.

The most significant difference is governance overhead and accountability structures. Government agencies operate under the Public Finance Act, the Crown Entities Act, and their own internal assurance frameworks, which means that Agile “move fast” culture runs into formal Change Advisory Board processes, ICT investment approval cycles, and mandatory project Gateway Reviews. As a Test Lead I need to produce artefacts — test strategies, test completion reports, risk registers — that can withstand scrutiny from internal audit and the Office of the Auditor-General, which is a higher bar than most private sector projects. Procurement and vendor engagement also moves far more slowly, so I plan tooling and resource ramp-up much further in advance. On the upside, NZ government teams tend to be genuinely committed to quality because the systems serve citizens directly, and there is strong cultural alignment with the Treaty of Waitangi obligations that sometimes shapes testing priorities around equitable access and Māori language support. Agile in this context is real but pragmatic — you follow the ceremonies and adapt the governance artefacts to fit the sprint cadence rather than expecting one to replace the other.

On a mobile banking feature release, we found a data truncation defect in the transaction description field during final smoke testing two hours before the deployment window. The defect caused amounts over $10,000 to display incorrectly in transaction history — a clear financial and reputational risk. My first action was to document the defect immediately with full reproduction steps, screenshots, and severity classification, then call an emergency bridge with the tech lead, PM, and the relevant business stakeholder — not email, voice call, because we needed a decision in minutes not hours. I presented the defect clearly, without catastrophising but without softening the risk, and gave the team three options: delay the release entirely; release with the defect and a manual monitoring protocol for affected accounts; or hotfix and test in the next 90 minutes if engineering could turn it around. The tech lead confirmed a one-line fix was possible; we patched, ran a targeted regression on the affected flow in 40 minutes, confirmed the fix, and released on a 90-minute delay. I then wrote a post-incident report that afternoon covering what we caught, the decision-making process, and what we would add to our pre-release checklist. The lesson we extracted was to include boundary value testing on all financial display fields as a mandatory pre-release check, which is now in our regression suite.

My immediate action is to do a risk-triage of the remaining 40%. Not all unexecuted tests are equal: some cover core high-risk workflows, others cover edge cases in low-traffic parts of the application. I work through the list and divide it into: must-execute before release, can defer to post-release monitoring, and can skip with documented rationale. I communicate the situation to the PM the same day — not on release day — with the risk-adjusted picture: “We can complete coverage of the critical path and the highest-risk areas; we are consciously deferring these lower-priority areas with the following monitoring plan.” I also explore whether any resource can be temporarily redeployed — a junior tester from another team, a developer who can pick up low-complexity test execution. I would never ask a developer to sign off on their own code, but they can execute scripted test cases on other modules. The key discipline is transparency early: three days out I can still shape the outcome. Three hours out, I’m just documenting a fait accompli.

I respond with curiosity before I respond with a policy. “Tell me more about what the config change does” — because sometimes it genuinely is low-risk and a smoke test is proportionate, and sometimes a “config change” is modifying a feature flag that affects 80% of users. Once I understand the change, I make a risk-based recommendation. If the change touches a payment gateway URL, a permissions model, or a third-party API endpoint, that is not a config update that ships without testing regardless of how small it looks in the code. I’ve seen production outages caused by a single character change in a connection string that wasn’t tested. I also use the moment as a teaching opportunity without being preachy: “I understand this looks trivial, and I want to make sure we both understand the blast radius before we decide. Here is what I propose to test and how long it will take.” If the developer genuinely can’t see the risk, I get the tech lead involved rather than having an unresolvable standoff with a peer. I never agree to skip testing by social pressure; I may agree to reduce scope based on a shared risk assessment.

The most impactful quality improvement I led was introducing a structured defect escape rate metric and a monthly review process at a mid-sized NZ software company that had been treating all production incidents as individual events rather than as a signal about systemic test coverage gaps. I proposed the metric, got buy-in from the QA manager and CTO, and spent two months building a clean baseline by going back through 18 months of production incidents and mapping each one to the phase it was introduced in and why it wasn’t caught. The data was clear: 60% of production defects were in three specific integration points that had low automated coverage. I built a targeted integration test suite for those areas over the next two sprints — it took about three weeks of effort. In the following quarter, production incidents in those three areas dropped by 70%. What I learned was that the hardest part wasn’t the technical work — it was getting the organisation to look at the data honestly rather than treating each incident as a one-off bad luck event. Change at system level requires someone willing to make an argument with evidence and persist through the “that’s interesting but we’re busy right now” response until it reaches the right decision-maker.