Junior QA Interview Prep

Boundary value analysis tells us that defects cluster at the edges of input ranges, so I would test the values immediately on and around each boundary rather than random values in the middle. For an age field accepting 18–100, I would identify four boundaries: 17 (just below the lower bound), 18 (the lower bound itself), 100 (the upper bound), and 101 (just above the upper bound). I would also test a typical mid-range value like 45 to confirm the happy path works. In practice, this means entering dates of birth that produce ages of 17, 18, 100, and 101 in the system — which requires calculating those dates relative to today's date, not just typing numbers directly into the field. I would also check edge cases around leap years and check that the field handles "100 years ago today" correctly, since some implementations calculate age differently at the exact anniversary. In a NZ context this matters especially for anything tied to the Age of Majority or KiwiSaver eligibility, where an off-by-one error has regulatory consequences.

Equivalence partitioning divides input data into classes where the system is expected to behave identically for every value in that class, so you only need one representative test per class rather than testing every possible value. Boundary value analysis is complementary — it specifically targets the edges of those partitions, because that is where off-by-one errors and conditional logic mistakes typically occur. I use EP first to identify the classes (valid: 18–100, invalid below 18, invalid above 100), then BVA to generate the specific test values at each boundary (17, 18, 100, 101). If I had very limited time and had to pick one, I would choose BVA for numeric ranges because it subsumes many of the EP values while also catching the edge defects. For categorical inputs — like a drop-down with options "Student", "Employed", "Retired" — EP is more relevant because there are no numeric boundaries to probe. In practice at places like Xero or ANZ NZ, you typically use both together as part of a structured test design session.

Decision tables are the right tool when the system's behaviour depends on combinations of multiple conditions rather than a single input range. A classic example is a loan eligibility check where the outcome depends on income level, credit score, and employment status simultaneously — BVA only tests one variable at a time, so it would miss interactions between conditions. I build a decision table by listing all conditions as rows and all possible combinations as columns, then filling in the expected output for each column. For a three-condition system there are eight possible combinations (2³), though often some are impossible or produce the same result so the table collapses. In a NZ insurance or lending context, where product eligibility rules can be complex and change frequently, decision tables also serve as great living documentation that business analysts can review — which reduces miscommunication between QA, BA, and developers. I flag this technique especially when I receive a requirements document that has phrases like "if… and… then…" repeated multiple times, because that is a signal the logic is table-shaped.

State transition testing works by mapping all the states a system can be in, the events that cause transitions between them, and the expected outcomes of those transitions. For a login flow I would identify states like: Logged Out, First Failed Attempt, Second Failed Attempt, Locked, and Logged In. Transitions include: entering correct credentials (Logged Out → Logged In), entering wrong credentials once (Logged Out → First Failed Attempt), entering wrong credentials again (First Failed Attempt → Second Failed Attempt), a third failure (Second Failed Attempt → Locked), and a successful unlock via email. My tests would cover every valid transition, but also invalid transitions — for example, trying to go directly from Locked to Logged In without unlocking, which should be rejected. I would draw a state diagram first to visualise this, which also makes a useful artefact to share with the developer. In a NZ banking context like ASB or Westpac NZ, account lockout rules may also be tied to fraud detection systems, so I would confirm with the BA whether a locked account triggers any downstream alerts that also need testing.

Pairwise testing, also called all-pairs testing, is a combinatorial technique based on research showing that most software defects are triggered by the interaction of two parameters rather than three or more simultaneously. Instead of testing every possible combination of inputs — which grows exponentially — you generate a minimal set of test cases that covers every pair of parameter values at least once. For example, if you have three browsers, three operating systems, and four screen sizes, exhaustive testing requires 36 combinations, but pairwise testing typically reduces this to around 12 while still catching the majority of interaction bugs. I use tools like PICT (Microsoft's free pairwise tool) or the built-in pairwise support in some test management tools to generate the combinations automatically. This is particularly valuable at NZ companies where small QA teams are asked to test across many configurations — say, a government portal that must work on Chrome, Firefox, Edge, and Safari across both Windows and macOS, tested by a team of two. Pairwise gives a principled way to maximise coverage within realistic time constraints rather than just picking test cases arbitrarily.

Scripted testing follows pre-written test cases with defined steps and expected results, making it repeatable and auditable — ideal for regression suites, compliance requirements, or acceptance criteria sign-off where you need a documented record. Exploratory testing is simultaneous learning, test design, and test execution — you use what you discover about the system during testing to guide your next action in real time, without a script. I think of scripted testing as "confirming what we expect" and exploratory as "discovering what we didn't expect." In practice I use scripted tests for anything that needs to be demonstrated to a stakeholder or regulator, such as showing that a change to Inland Revenue's myIR portal doesn't break tax filing. I use exploratory testing when I first receive a new feature, when I'm investigating a reported defect, or when I have time after scripted tests pass and want to probe for unexpected behaviour. Good exploratory testing is not random clicking — I use session-based test management, noting my charters (what I'm exploring and why), time-boxing sessions to 90 minutes, and logging notes as I go so the session is still reviewable afterwards.

A good test case has a clear, single objective so that when it fails you immediately know what broke — a test that checks five things at once tells you something went wrong but not what. It must have unambiguous preconditions (the exact starting state, data, and environment), specific steps that anyone on the team could follow without interpretation, and a precise expected result stated before execution so confirmation bias doesn't creep in. It should be independent of other test cases so it can be run in any order without setup from a preceding test. A good test case is also proportionate — it is as short as it can be while still covering its objective, because long test cases are brittle and hard to diagnose. I also think a good test case documents its rationale: which requirement or risk it covers, so that when a product manager asks "why are we testing this?" there's a clear answer. At a company like Datacom or Spark Digital, where test cases may be maintained by multiple people over years, readability and traceability to requirements matter as much as correctness.

The biggest maintainability killers are hard-coded test data and UI-specific steps that break every time a label or layout changes. I avoid these by keeping test cases at the behaviour level ("the user can submit a valid address") rather than the implementation level ("click the blue button labelled 'Submit' in the top-right corner"). I separate test data from test logic — data should live in a data file or table, not embedded in the steps — so changing a test account number means updating one place, not fifty test cases. I also apply the DRY principle by using shared setup steps or precondition templates rather than copy-pasting the same login sequence into every test case. Tagging tests to the requirements they cover means that when a requirement changes, I can quickly find every test case that needs review. In Agile teams I've learned to write test cases during sprint planning, not after development starts, so they reflect the agreed behaviour and are easier to keep aligned with changes. Finally, running a brief test case review after each sprint to retire obsolete tests is just as important as adding new ones — a bloated test suite is as harmful as a thin one.

Code coverage measures the proportion of source code lines (or branches, or paths) executed during testing, and it is a useful signal but a poor target. I can achieve 100% line coverage while still missing critical bugs if my tests don't assert on meaningful expected outcomes, or if they only exercise the happy path. So my answer to the developer would be: "Our automated unit tests currently hit about X% of lines, but what matters more is whether we have risk-based coverage — are we testing the areas most likely to fail and most costly if they do?" I distinguish between different coverage types: line coverage (was this line executed?), branch coverage (was every if/else path taken?), and test condition coverage (was every logical condition evaluated to both true and false?). In practice I focus on coverage of requirements and risk areas rather than code lines — I'd rather have 70% code coverage with all high-risk paths tested than 95% coverage achieved by executing low-value code. Tools like JaCoCo for Java or Istanbul for JavaScript can give the metric, but I always pair it with a risk map review to spot the gaps that matter.

A test condition is a testable aspect of a feature — a statement of what needs to be true or what behaviour needs to be verified, without specifying how to test it. A test case is the specific, executable procedure that verifies one or more test conditions, including steps, data, environment, and expected result. For example, a test condition for a password reset feature might be: "A user who has forgotten their password can regain access within 10 minutes using only their registered email address." From that single condition I might write three or four test cases — one for the happy path, one for an unregistered email, one for an expired reset link, and one for a link used twice. Keeping test conditions separate from test cases is useful in Agile because the conditions can be agreed with the business analyst during backlog refinement before the developer has built anything, serving as a shared definition of done. In ISTQB terminology, test conditions are derived from the test basis (requirements, user stories, risk items), and they form the bridge between "what we need the software to do" and "how we will verify it does that."

A good bug report lets a developer reproduce the defect quickly without needing to come back to me for clarification. That requires: a clear, specific title that describes what went wrong (not "login broken" but "Login fails with valid credentials when username contains an uppercase letter"); numbered steps to reproduce starting from a clean state; the actual result I observed; the expected result based on requirements or reasonable behaviour; environment details (browser, OS, app version, test account used); and the severity. I attach screenshots or a short screen recording for every visual bug and for any bug that is hard to reproduce — video evidence removes doubt and saves back-and-forth. I also note whether the bug is reproducible consistently, intermittently, or was a one-time occurrence, because that affects how a developer prioritises investigating it. In Jira, which is common at NZ companies, I fill in all mandatory fields and add relevant labels and components so the right team sees the ticket. A bug report that a developer can act on immediately is one of the most valuable things a junior QA can deliver — it builds trust and speeds up the fix cycle.

Severity describes the technical impact of the defect on the system — how badly it damages functionality, data integrity, or performance. Priority describes how urgently the business needs it fixed — which is determined by business context, not technical impact alone. These two dimensions are independent and can combine in all four ways. A typo on the About Us page is low severity (nothing breaks) and low priority (fix it when convenient). A crash in the payment flow is high severity and high priority — both dimensions align. The interesting cases are where they diverge: a crash in an admin-only debug screen that no end user can reach might be high severity but low priority (fix it eventually, not tonight). Conversely, a minor display error on the homepage of a publicly traded NZ company on the day of an annual result announcement might be low severity technically but extremely high priority commercially. As a QA I set severity based on my technical assessment, but I escalate priority decisions to the product owner or team lead because they understand the business context I may not have. Conflating the two is a common junior mistake that leads to either under-reacting to damaging bugs or wasting developer time on cosmetic issues.

My first response is to ask the developer to show me the requirement or design decision that specifies the current behaviour, because "works as designed" needs to be traceable to something. If they can point to a clear acceptance criterion or design document, I re-read it carefully — sometimes I misunderstood the expected behaviour and this is a genuine clarification. If I still believe the behaviour is wrong after that conversation, I escalate by looping in the BA or product owner to arbitrate, rather than continuing a back-and-forth with the developer — the question then becomes "what did we agree the system should do?" rather than "who is right?" If it turns out the requirements were genuinely ambiguous, that is itself useful information: we update the acceptance criteria so there is no dispute for similar scenarios in the future. I also document the outcome on the defect ticket so there is a written record of the decision, whatever it is. I never close a defect just because a developer says it is WAD without getting that decision confirmed by someone with product authority. Staying calm, curious, and evidence-based — rather than defensive — is what makes these conversations productive.

Regression testing verifies that changes to the codebase — new features, bug fixes, refactors — haven't broken functionality that was previously working. It matters in Agile because every sprint introduces new code, and without regression testing you can fix one bug while silently introducing another in a completely different part of the system. In a two-week sprint cycle there simply isn't time to manually retest everything after every change, which is why teams invest in automated regression suites that run on every build or pull request via CI/CD pipelines. I prioritise my regression suite around high-risk and high-impact areas: the critical user journeys (checkout, login, core business transactions), areas that share code with the recent change, and features that have historically been fragile. In a NZ context, for a company like Trade Me or Pushpay, where the core transaction flow processes millions of dollars, regression testing on payment and listing functionality is non-negotiable before any production deployment. For manual regression I use a risk-based approach to decide which areas need human eyes beyond what automation covers — typically the new features and any areas where the automated tests are weak.

The Software Development Life Cycle covers the entire process of building software — requirements gathering, design, development, testing, deployment, and maintenance. The Software Testing Life Cycle is the subset of that process specifically concerned with testing: planning, analysis, design, environment setup, execution, and closure. The STLC runs in parallel with and feeds into the SDLC rather than sitting as a sequential phase after development. One of the most important insights for a junior QA is that QA involvement should start at requirements phase in the SDLC, not wait until a build is handed over — reviewing requirements for testability and ambiguity early is far cheaper than finding those problems during test execution. In an Agile SDLC there isn't a hard boundary between phases; instead the STLC activities happen within each sprint. Test planning happens during sprint planning, test design happens alongside development, and execution and closure happen before the sprint review. Understanding how STLC maps onto an Agile SDLC helps you explain to a product owner why QA needs to be in backlog refinement sessions, not just sprint execution.

My first move is to quickly triage what is in scope: which stories are code-complete and ready to test, and which are still being developed? I focus immediately on the code-complete items rather than waiting for everything to be ready. I read the acceptance criteria and check whether they are clear enough to test against — if not, I raise that with the developer or BA right away, not at the end of the day. With limited time, I apply risk-based prioritisation: I test the highest-risk and highest-value functionality first so that if time runs out, the most critical scenarios have been covered. I explicitly communicate to the team what I have and haven't tested, and I distinguish between "tested and passing", "tested and defect raised", and "not yet tested" — keeping the team informed so they can make a release decision with accurate information. I also capture any remaining test cases as known gaps that carry forward. In the sprint retrospective I'd raise whether the QA entry point in the sprint is too late, because joining three days before close suggests stories aren't ready for test early enough — that's a process improvement conversation, not a personal criticism.

User Acceptance Testing is the phase where the people who will actually use the system — end users or their business representatives — verify that the software meets their real-world needs before go-live. It is distinct from QA testing because it is not about finding bugs per se; it is about the business confirming that the software is fit for purpose in their context. As a QA my role in UAT is facilitating, not leading. I prepare the UAT environment, ensure test data is realistic and loaded, brief the UAT participants on how to report issues (what information to capture, how to submit defects), and triage the defects they raise — some will be genuine defects, some will be scope questions, and some will be change requests that surfaced during UAT. I also make sure the software entering UAT has already passed system testing so participants aren't blocked by basic bugs. In NZ public sector projects — say, for a Ministry or a DHB/Health NZ system — UAT often involves end users from multiple regional offices and must demonstrate compliance with requirements before a formal sign-off. I keep a log of UAT session outcomes and produce a UAT completion report that the project can use to make the release go/no-go decision.

Smoke testing is a shallow, wide check run on a new build to determine whether it is stable enough to proceed with deeper testing — like checking whether the application starts, you can log in, and the main pages load without crashing. The name comes from hardware testing: you power on a new circuit board and check whether smoke comes out before doing anything more involved. Sanity testing is narrower but deeper — it focuses specifically on the area of the system that was just changed or fixed to verify that the change works as intended and hasn't broken the immediate surrounding functionality. You'd run a sanity test after a developer pushes a bug fix to confirm the fix works before sending the build to a broader regression run. In practice: smoke first (is the build worth testing at all?), then sanity (does this specific change work?), then full regression (has anything else broken?). Both are typically fast and targeted — smoke tests should complete in minutes. In a CI/CD pipeline context at a NZ tech company, smoke tests often run automatically on every deployment to a staging environment, with the result determining whether the build is promoted to QA.

An API — Application Programming Interface — is a defined contract that allows two software systems to communicate with each other, specifying what requests can be made, in what format, and what responses to expect. A REST API, the most common type in web development, uses HTTP methods (GET to retrieve data, POST to create, PUT/PATCH to update, DELETE to remove) and exchanges data in JSON or XML format. QAs need to understand APIs because in modern applications the UI is just one way to interact with the system — the business logic sits in the backend and is exposed through APIs. Testing at the API layer lets me verify core logic independently of the UI, which is faster, more stable, and catches defects earlier. It also lets me set up test data programmatically — creating a user account via API is far quicker than clicking through a UI form 50 times. In NZ, practically every significant digital product — from Xero's accounting platform to Inland Revenue's gateway services — exposes APIs that partners and customers integrate with, so API testing is not optional for a QA in those environments. Tools like Postman and Bruno make API testing accessible even without a programming background.

I would start by reading the API specification or contract (Swagger/OpenAPI documentation if available) to understand the required and optional fields, data types, and expected response codes. Then I would test across several dimensions. For the happy path: send a valid POST request with all required fields and verify the response is 201 Created, the response body contains the new customer's ID, and the record actually exists in the database. For validation: send requests with missing required fields (expect 400 Bad Request with meaningful error messages), with invalid data types (a number where a string is expected), and with values that exceed field length limits. For security: check whether the endpoint requires authentication (expect 401 Unauthorized without a token) and whether a user can create a customer under another tenant's account (authorisation, expect 403 Forbidden). For duplicates: try creating a customer with an email that already exists and verify the system handles it correctly. For the response: confirm the HTTP status codes match the spec for every scenario, and that error messages don't expose internal system details like stack traces or database table names. I'd run all of this in Postman and save the collection so it can be re-run as a regression check.

SQL lets me verify that what the UI shows or the API returns actually matches what's stored in the database — which is the ground truth. Without database access, I'm only testing what the application chooses to show me, and a defect in the data layer might be invisible at the UI level. Common scenarios where I use SQL: verifying a record was actually created after a successful POST (not just that the UI said it was), checking that a delete operation removed all the right related records and didn't leave orphaned data, validating that data migrations ran correctly by comparing row counts and spot-checking field values, and setting up specific test data states that would be tedious to create through the UI. The essential queries for QA are: SELECT with WHERE to retrieve and filter records, COUNT to verify record counts, JOIN to check relationships across tables, and UPDATE/DELETE for test data cleanup (with care and always in test environments only). I use SELECT far more than anything else — modifying production-like data requires explicit permission and careful documentation. At a company using tools like Azure Data Studio, DBeaver, or even the query console in a test management tool, basic SQL literacy is a genuine differentiator for a junior QA in NZ's market.

In a previous role I was testing an e-commerce checkout and noticed that orders would occasionally fail at payment, but I couldn't reproduce it reliably — it happened roughly one in ten attempts. The task was to gather enough information for the developer to investigate without me having a consistent reproduction path. I started by capturing everything I could each time it occurred: timestamp, session ID, browser console errors, network tab responses. I noticed the failures only happened when I had two browser tabs open simultaneously on the cart page. I hypothesised this was a session or concurrency issue, shared my findings with the developer, and they confirmed there was a race condition in the session token refresh logic that only triggered with concurrent requests. The result was a fix that prevented a bug that would have affected real customers with multiple tabs open — which is very common behaviour. What I learned was that intermittent bugs require a systematic observation approach rather than just repeated clicking, and that documenting the conditions when it does and doesn't occur is as valuable as the reproduction steps themselves.

When I joined my first QA role, each tester was manually creating the same set of 30 test user accounts at the start of every sprint because our test environment was wiped on refresh. This was taking about two hours per person per sprint and occasionally going wrong when data was set up inconsistently. I recognised this as a repetitive, error-prone manual task and proposed scripting it. I wrote a small set of SQL insert scripts and a short setup checklist so any tester could recreate the standard test data in under five minutes with consistent results. I presented it to the QA lead as a draft, got feedback, and we refined it together before rolling it out to the team. The outcome was roughly six hours of QA time saved per sprint across the team, and a significant reduction in "this test failed because the data was wrong" noise in our defect tracking. It also gave me confidence to propose process improvements in retros, because I had demonstrated I could implement as well as identify. The lesson for me was that good QA extends beyond finding bugs in the product — finding inefficiencies in the testing process and fixing them is equally valuable.

My first step is to get full visibility of what needs to be done: I list everything in scope and then assess each item by two factors — risk (what is the business or user impact if this is wrong?) and effort (how long will this take to test?). High-risk, low-effort items go first. I'm transparent with the team early rather than late — if I can see that the volume of work won't fit the timeline, I say so in the stand-up that day so the team can make an informed decision about descoping or adding capacity, rather than discovering at 5pm on the last day. I also distinguish between what must be tested before release and what can be deferred or covered by monitoring in production — not everything has equal importance. During the crunch I avoid perfectionism: a good test of the critical paths is far more valuable than an exhaustive test of low-risk edge cases. Afterwards, I document what wasn't tested and why, so there is a clear record of the known risk that was accepted. Working in NZ teams I've found that being upfront about constraints is always received better than surprising stakeholders — people respect honesty about scope far more than a last-minute scramble.

Early in my QA career I raised a defect on a user-facing error message that was technically accurate but confusing to non-technical users — it showed a raw system error code with no explanation. The developer argued it wasn't a bug because the application was handling the error correctly and not crashing. I disagreed because users were unable to understand what had gone wrong or what to do next, which I considered a functional problem, not just a UX preference. Instead of escalating immediately, I asked the developer to look at the user story's acceptance criteria together with me — one of them stated that "users must be informed of errors in plain language." That resolved the factual disagreement: the behaviour didn't meet the agreed criteria. The developer updated the message and we both agreed that having clearer, testable acceptance criteria for error states up front would prevent similar debates. What worked was keeping the conversation evidence-based (pointing to written criteria rather than opinion), remaining respectful, and framing it as "what did we agree the software should do?" rather than "you're wrong." Developers and QAs share the goal of shipping quality software — approaching disagreements from that shared foundation makes them much easier to resolve.