QA Interview Prep

Verification asks "are we building the product right?" and checks that the software conforms to its specification — for example, reviewing a requirements document or inspecting code against coding standards. Validation asks "are we building the right product?" and checks that the finished software actually meets the user's real-world needs, typically through testing the running system. A simple way to remember it: verification is done before or during development and catches specification mismatches, while validation is done on the working product and catches usability or business logic gaps. In practice, a QA engineer does both — reviewing requirements early (verification) and testing the build later (validation). Missing either step increases the risk of shipping software that technically "passes" but doesn't solve the actual problem. NZ government projects often require documented evidence of both activities as part of their procurement standards.

A test case is a documented set of conditions and steps used to verify that a specific feature or piece of functionality behaves as expected. A good test case includes a unique ID so it can be tracked, a clear title that describes what is being tested, any preconditions (e.g. "user must be logged in"), step-by-step actions written precisely enough that another tester can follow them without guessing, the expected result for each step or at the end, and the actual result recorded after execution. It should also include the test environment (browser version, device, OS) and the current pass/fail status. Vague expected results like "it should work" are a red flag — a good expected result is specific and measurable, such as "the system displays a confirmation message within 3 seconds." Well-written test cases also make regression testing much faster because anyone can pick them up and run them consistently.

The defect life cycle describes the stages a bug moves through from discovery to closure. When a tester finds a problem, they log it as New in a tool like Jira. A team member (often the QA lead or product owner) then triages it — if it's a genuine defect it moves to Open, or it may be Rejected if it's actually expected behaviour or a duplicate. Once a developer picks it up it becomes In Progress or Assigned. After the fix is applied it moves to Fixed or Resolved, and the tester re-tests it. If the fix works the defect is Closed; if the fix didn't work or introduced a regression, it's Reopened and the cycle repeats. Some teams also have a Deferred state for real bugs that won't be fixed until a later release. Knowing this cycle matters because it shows you understand that defect management is a team communication process, not just a personal to-do list.

Testing is the process of executing software with the intent of finding failures — it's a QA responsibility and results in a pass or fail outcome against expected behaviour. Debugging is the process a developer uses to locate and fix the root cause of a failure once it has been found. As a tester, my job is to find and clearly describe the symptom (what went wrong, steps to reproduce, environment, expected vs actual result); the developer's job is to trace that symptom back to the code that caused it and apply a fix. These are distinct skills — a tester doesn't need to know exactly which line of code is broken, but they do need to give the developer enough information to find it quickly. That said, a QA who understands basic debugging concepts (reading logs, using browser developer tools, checking network requests) can write far more useful bug reports and becomes a much more effective team member over time.

Software development is an inherently human activity, which means mistakes are inevitable no matter how skilled the developer is. Complex systems have thousands of interacting variables — different devices, browsers, user inputs, network conditions, and data states — that are practically impossible to anticipate perfectly in code. Testing provides an independent perspective: a developer knows how the code is supposed to work, which makes them less likely to discover how it breaks. Beyond catching bugs, testing also validates that business requirements were understood correctly, provides documentation of expected behaviour, and builds confidence before a release. The economic case is also compelling: the NIST estimated that defects found after release cost 10-100x more to fix than those caught during development. For NZ businesses handling customer data under the Privacy Act 2020, untested software can also create regulatory risk. So testing isn't a sign that developers are bad — it's a safety net that makes the whole team more effective.

Boundary value analysis (BVA) is a technique based on the observation that defects are most likely to occur at or just outside the edges of valid input ranges, not in the middle. Rather than testing only typical values, you deliberately test the minimum and maximum valid values and the values just outside those limits. For example, say a form accepts ages from 18 to 65. Using BVA you'd test: 17 (just below minimum — should be rejected), 18 (minimum valid — should be accepted), 19 (just above minimum — should be accepted), 64 (just below maximum — should be accepted), 65 (maximum valid — should be accepted), and 66 (just above maximum — should be rejected). In practice you might find the system rejects 65 when it should accept it, or accepts 66 when it shouldn't — these are classic off-by-one errors that developers make when writing comparison operators. BVA is efficient because it gives you good defect coverage without testing every possible number between 18 and 65.

Equivalence partitioning (EP) is a technique that divides the possible input values for a field into groups (partitions) where you'd expect all values in the group to behave identically. If they all behave the same, you only need to test one representative value from each group rather than every possible value. For the age example above, the partitions would be: invalid below range (e.g. 0-17), valid range (18-65), and invalid above range (66+). You test one value from each partition. EP and BVA are complementary: EP tells you which partitions exist, BVA tells you to focus your testing on the boundaries between those partitions where bugs are most common. Used together, they give you a structured, efficient approach to input testing that's far more systematic than guessing values at random. This combination is particularly useful when testing form validation, which appears constantly in NZ web and mobile applications.

Exploratory testing is a simultaneous approach where test design, execution, and learning happen at the same time, guided by the tester's skill, curiosity, and understanding of risk rather than a pre-written script. Instead of following step-by-step test cases, you explore the application with a goal or "charter" in mind — for example, "investigate what happens when a user interrupts the checkout process on a mobile device." It's most valuable when you're testing a new feature for the first time, when you have limited documentation, when you want to find unexpected bugs that scripted tests wouldn't reach, or when you're running a time-boxed session to get quick coverage before a release. Exploratory testing isn't unstructured guessing — good explorers take notes, track what they've covered, and log findings systematically. In NZ startup and scale-up environments, where documentation is often sparse and releases are frequent, exploratory testing is an essential skill rather than an optional extra.

Risk-based testing is the approach I'd use: prioritise the areas where a failure would have the greatest impact on users or the business. I'd start by asking what the core user journey is — the path that the most users take most often — and make sure that works end-to-end before spending time on edge cases. Then I'd consider what's changed in this release, since changed code is more likely to contain new defects than stable code. High-risk areas like payment processing, login, or anything touching personal data also get priority because failures there have serious consequences. I'd also look at historical bug data if it exists — areas that have been buggy before often stay buggy. If I'm working with a product owner or developer, I'd ask them what they're most worried about, as they often have gut-feel knowledge of where the risky code is. The goal is to fail fast on the important stuff rather than exhaustively testing low-risk areas while the critical path remains untested.

I've used Jira in my bootcamp training to practise logging and tracking defects. As a QA, I'd use Jira primarily for three things: tracking defects (creating bug tickets with clear titles, reproduction steps, expected vs actual results, severity, and supporting screenshots or logs), tracking test progress against user stories in the current sprint (linking test evidence to story tickets), and monitoring the defect life cycle as bugs move from Open through to Closed. I'd keep my defect reports concise and specific so developers can act on them quickly without having to chase me for more information. Jira also integrates with tools like Confluence for test documentation and Zephyr or Xray for structured test case management. Most NZ tech companies and agencies use Jira or a similar tool (some use Linear or Azure DevOps), so the underlying concepts transfer even if the specific interface differs.

Agile is an iterative approach to software development where work is broken into short cycles (usually two-week sprints) and teams collaborate closely rather than following a rigid upfront plan. For QA, Agile means testing happens continuously throughout development rather than at the end — you're testing features as they're built rather than waiting for a complete build to arrive in a handoff. This is a fundamental shift from traditional waterfall testing. In Agile, QA is involved from the beginning of a story: you review acceptance criteria, raise questions about edge cases before coding starts, and build test cases alongside development. You also need to be flexible, because requirements can change between sprints. Agile QA requires strong collaboration skills — you're a team member with shared ownership of quality, not a gatekeeper at the end of the pipeline. The vast majority of NZ tech companies — from startups to enterprises like ANZ and Spark Digital — run some form of Agile.

A sprint is a fixed-length development cycle, typically one or two weeks, during which the team commits to completing a set of user stories from the product backlog. At the start of a sprint the team holds sprint planning: stories are selected, tasks broken down, and everyone agrees on what "done" means for each story (the definition of done). During the sprint the team has a daily standup — a short check-in where each person shares what they did yesterday, what they're doing today, and whether anything is blocking them. At the end of the sprint there's a sprint review (demo to stakeholders) and a retrospective (team reflects on what went well and what to improve). As a QA, my sprint activities include refining acceptance criteria during planning, testing stories as they're completed during the sprint, logging defects, re-testing fixes, and contributing to the retrospective with quality observations. The goal is that by the end of the sprint, all committed stories are tested and ready to ship.

Day-to-day QA in a sprint is more varied than most people expect. At the start of the sprint you're reviewing user stories and acceptance criteria to identify ambiguities before coding starts — catching a misunderstood requirement here saves far more time than finding it as a defect later. Once development is underway, you're writing test cases for upcoming stories while also testing stories that have just been completed. When you find defects you're logging them clearly and following up with developers to confirm understanding. You'll attend the daily standup, raise blockers, and update your testing progress on the sprint board. You'll also spend time on regression testing — checking that new changes haven't broken existing features. As a grad you might also be maintaining a shared test environment, updating test documentation, or running automated smoke tests if the team has them. No two days look identical, which is one of the things that makes the role interesting.

During my bootcamp training I was testing a registration form and noticed that the system accepted an email address without an "@" symbol — it processed the input and showed a success message, which was clearly wrong. I first confirmed I could reproduce it consistently with different invalid email formats, then noted down the exact steps, the environment (Chrome 124 on Windows 11), the expected result (validation error), and the actual result (success message shown). I took a screenshot and logged a defect ticket in Jira with all of that detail, including the severity rating (medium, since it would create bad data in the system). I flagged it to the relevant team member rather than just leaving it in the backlog unnoticed. When the fix was deployed I re-tested all the email format scenarios I'd tried originally to confirm the fix was complete and hadn't introduced any new issues. The experience reinforced to me that a good bug report is one that gives the developer everything they need to reproduce and fix the issue without a back-and-forth conversation.

My first step would be to listen carefully and try to understand their reasoning — sometimes developers have context about design decisions that aren't reflected in the documentation, and they might be right. I'd ask them to point me to where the current behaviour is specified, because if I was testing against incorrect expectations then I need to update my test cases. If I genuinely believe the behaviour is harmful to users or the business, I wouldn't just drop it — I'd escalate it by bringing it to the product owner or business analyst for a decision, rather than continuing to argue with the developer directly. The key is to keep it factual and non-confrontational: "I understand you're saying this is intended, but the acceptance criteria on the story says X. Can we get the PO to clarify?" Disagreements like this are normal in QA and the best outcome is always a clear, documented decision rather than an unresolved standoff. At the end of the day, QA's job is to surface information and risk — the business decides what to do with it.

I start by getting a quick mental model of what the tool is for and how it fits into the broader workflow, usually by reading the official documentation overview or watching a short introductory video. Then I try to get a working example running as fast as possible — even a small "hello world" equivalent gives me enough hands-on context to ask better questions. After that I identify the specific features I need for the task at hand and focus on those rather than trying to learn everything at once. I take notes as I go, especially on anything that confused me at first or that I had to look up, because that's the information I'll need again later. I also find it valuable to look for communities — Slack groups, Stack Overflow tags, or local meetups like Wellington QA or Auckland Test Automation Meetup — where I can see how experienced practitioners use the tool in real contexts. I'm comfortable accepting that I won't be an expert immediately; what matters is making steady progress and asking for help when I hit a wall rather than losing hours trying to figure it out alone.

I'm drawn to QA because it sits at the intersection of technical work and real-world impact — you're the person who makes sure the software actually works for the people who use it, not just in theory. I find a lot of satisfaction in structured problem-solving: approaching a new feature methodically, designing test cases that cover the important scenarios, and finding issues before they reach users. I also like the collaborative nature of the role — you work closely with developers, product owners, and designers, which means you get broad exposure to how software is built without being siloed in one area. Longer term, QA is a strong foundation for many paths in tech, whether that's specialising in test automation, moving into DevOps or security testing, or stepping into an SDET role. I want to start in QA because I believe quality is a craft, and I want to build that craft from the ground up in a team where I can learn from experienced practitioners. (Note to candidates: personalise this answer — the model above is a framework. Add your own specific reason.)

Most NZ tech companies run some version of Agile, but in practice it's usually a pragmatic blend rather than textbook Scrum or Kanban. Smaller NZ companies and startups — which make up a significant part of the tech sector in cities like Auckland and Wellington — often have flat team structures where the QA talks directly to the CEO or CTO, processes are informal, and the team adapts ceremonies to fit their size. Larger organisations like Xero, Trade Me, Spark, or ANZ tend to run more structured Agile at scale, sometimes using SAFe (Scaled Agile Framework) or their own hybrid approach. What I've found in my training is that the underlying values — iterative delivery, close collaboration, responding to change — are consistent, but the ceremonies and tools vary a lot. As a grad I'd expect to adapt to whatever framework the team uses rather than advocate for one specific approach. I'd also expect NZ teams to be more informal in communication style compared to what some international case studies describe — "she'll be right" pragmatism is real, and that includes in how QA processes are run.

The Privacy Act 2020 governs how organisations in New Zealand collect, store, use, and share personal information. As a QA, this affects my work in several concrete ways. First, I should never use real personal data in a test environment unless it's been properly anonymised or pseudonymised, because loading a production database dump into a test environment that lacks production-level security controls is a privacy risk. Second, when testing features that handle personal information — such as user profiles, health records, payment details, or contact information — I need to verify that data is only accessible to authorised users, that it's stored securely, and that deletion or export requests (privacy principles 6 and 7) actually work correctly. Third, if I discover a data exposure risk during testing, I have a professional obligation to report it to the development team and document it clearly as a high-severity defect. The Privacy Commissioner can investigate organisations that fail to protect personal information, and breaches can result in significant reputational and financial consequences for NZ businesses.

New Zealand has a strong fintech and SaaS sector — companies like Xero, Pushpay, Hnry, and Sharesies have built globally-used software from NZ, and those environments offer excellent QA experience because the stakes around accuracy and reliability are high. Healthtech is also growing, with organisations like Orion Health and various DHB-connected software vendors doing work where quality failures have direct patient safety implications, which raises the bar for testing practice. Government digital services are another interesting area — the Digital Public Service Alliance is investing in modernising public-facing systems, and testing in that context involves accessibility compliance (which in NZ often references WCAG 2.2 AA), privacy requirements, and wide browser/device coverage because the public uses everything. I'm also interested in the agritech space given NZ's primary industries — companies building software for farm management, supply chain traceability, or environmental reporting are less well-known but technically interesting. I'd encourage you to research which sector genuinely interests you and mention it specifically in your interview. (Note to candidates: replace the industries above with ones that genuinely appeal to you.)