QA mock interview 2026: 20 Junior and Middle tester questions
This is a technical interview rehearsal, not a glossary to memorise. Set a timer, answer aloud and only then open the review. Every question includes what a strong answer demonstrates and the mistake that weakens it.
How to use this mock interview
A real interview tests whether you can assemble an answer without a long pause. Allow 90 seconds for a theory question and up to five minutes for a scenario. Speak aloud: an answer in your head nearly always sounds more structured than the one you actually say.
Do not memorise the sample wording. Compare the structure: did you identify the goal, risk, concrete check, expected result and evidence? That reasoning pattern is what separates a working answer from a definition.
- Clarify context and constraints
- Name the main risk
- Offer concrete checks
- State the expected result
Count a question only when you answered aloud before opening the review.
- 0 No answer, or unrelated terms with no connection to the problem. 0 · gap
- 1 A correct definition, but no example, expected result or priority. 1 · theory
- 2 A structured answer with concrete checks and expected results, but limited risk and evidence. 2 · Junior+
- 3 The answer uses context, risk, trade-offs and observability and explains the choice. 3 · Middle
Junior QA: fundamentals tested through examples
Junior candidates are not expected to be encyclopaedias. They need stable foundations: test design, clear defect reports, HTTP, client-server basics and the ability to see a negative path.
1 What is testing, and can it prove that no bugs exist?
Strong answer review
Testing provides information about quality and reduces risk, but it cannot prove the absence of defects. Exhaustive testing is almost never possible, so checks are selected from requirements, risk, test techniques and product history. The QA outcome is not “there are no bugs”; it is a clear account of what was tested and what risk remains.
What it assesses: the purpose of testing, limited coverage and the connection to risk.
Red flag: “QA guarantees that the product works completely”, or a definition with no practical meaning.
2 How would you test a login form?
Strong answer review
I would first clarify login methods, email and password rules, lockout, recovery and roles. Then I would cover successful login, each field, empty and boundary values, case and whitespace, a wrong credential pair, brute-force protection, error messages, and session creation. After login I would check direct access to a protected page, logout, session expiry and switching users.
What it assesses: clarifying questions, grouped checks and movement from UI validation to session and security.
Red flag: an unprioritised list of fields that never checks what happens after login.
3 How do severity and priority differ? Give an example.
Strong answer review
Severity describes the effect on the system or user; priority describes when the business wants the defect fixed. Data loss in a rarely used internal report may have high severity without the highest priority. A company-name typo on the home page before a campaign has low severity and high priority. The exact scales and field ownership depend on the team process.
What it assesses: separation of technical impact from business order, with an example where values differ.
Red flag: “QA sets severity and a manager sets priority” presented as a universal rule without explaining either concept.
4 POST /orders returned 201. Is the test successful?
Strong answer review
Not yet. A 201 covers only part of the contract. Check the response body and headers, schema and order values, Location if applicable, persistence through a later GET, stock and total changes, and unwanted side effects. Repeat the request and determine whether it should create another order or be idempotent. A successful status with a wrong total is still a defect.
What it assesses: seeing status, contract, data and side effects as separate test layers.
Red flag: “201 means Created, so it works”, or checking only the green status in Postman.
5 What is the difference between authentication and authorisation?
Strong answer review
Authentication establishes who the user is through credentials, a token or a session. Authorisation decides what that user may do. Tests should include no token, an invalid or expired token, a valid token, another role and another user’s object id. In HTTP semantics, missing valid credentials normally produces 401, while a known user without permission gets 403, although private resources may deliberately be hidden behind 404.
What it assesses: identity versus permissions, roles and object ownership.
Red flag: checking that a UI button is hidden without sending the forbidden request directly.
6 How do a test case, a checklist and an exploratory session differ?
Strong answer review
A test case records preconditions, data, steps and an expected result. It is useful for a critical repeatable path, handover and audit. A checklist is shorter and lets the tester choose exact steps, which works well for a familiar area and fast regression. An exploratory session has a charter, risks and a timebox; learning, test design and execution happen together, producing notes, findings and questions. Choose the format by risk, product maturity and the cost of reproducibility rather than habit.
What it assesses: the purpose of each artefact and the ability to select an appropriate level of detail.
Red flag: calling exploratory testing random clicking or requiring a detailed test case for every check.
7 Which HTTP methods are safe and which are idempotent?
Strong answer review
A safe method is intended for read-only use: GET, HEAD, OPTIONS and TRACE should not change state at the client request. An idempotent method should have the same intended server effect after identical repetitions as after one call; safe methods plus PUT and DELETE are idempotent. HTTP gives no such general guarantee to POST or PATCH. A repeated DELETE may return a different status and a GET may still create a log entry: idempotency concerns the requested effect, not byte-for-byte identical responses or every internal side effect.
What it assesses: safe versus idempotent semantics, retry behaviour and why identical responses are not required.
Red flag: claiming every POST must duplicate data or every DELETE must return the same status.
8 How do you distinguish 400, 401, 403, 404, 409 and 422?
Strong answer review
400 covers a general client error such as malformed request syntax. 401 means valid authentication credentials are missing and includes a WWW-Authenticate challenge. 403 means the server understood the request but refuses it. 404 means the resource was not found or is deliberately hidden. 409 is a conflict with current resource state, such as an obsolete version or an email already in use. 422 means the content type and syntax are understood but the instructions fail semantic validation. The API contract selects the exact code; QA tests the contract for consistency rather than enforcing a favourite code.
What it assesses: status semantics, contract awareness and concrete examples that separate neighbouring codes.
Red flag: treating all 4xx responses as interchangeable or expecting 401 for an authenticated user who lacks permission.
9 How would you test a session and logout beyond clicking the button?
Strong answer review
First identify where the session identifier is stored and how it is sent. Check session rotation after login, Secure, HttpOnly and SameSite cookie attributes, no token in the URL, access before and after logout, replay of the old request, a second device, idle timeout and absolute timeout. Logout must invalidate the server session or refresh token according to the chosen model, not merely redirect the UI. Clearing localStorage alone does not prove that access was revoked.
What it assesses: the session lifecycle, direct request replay and multiple clients rather than only UI state.
Red flag: checking only that the user name disappeared or demanding the same token in both cookie and localStorage.
10 How would you find duplicate emails with SQL, and what comes next?
Strong answer review
A starting query is SELECT LOWER(TRIM(email)) AS normalized_email, COUNT(*) FROM users GROUP BY LOWER(TRIM(email)) HAVING COUNT(*) > 1. Normalisation must follow the business rule; case and whitespace cannot be declared insignificant by the tester. Fetch the concrete rows next and compare tenant, status, deleted_at and creation time. Then test the write-side uniqueness constraint and two concurrent registrations. Finding existing duplicates does not prove that new ones are prevented.
What it assesses: GROUP BY with HAVING, deliberate normalisation and moving from data analysis to the source of duplicates.
Red flag: using DISTINCT, which hides duplicates, or deleting records before confirming the business rule.
Middle QA: priorities, uncertainty and product impact
Middle is not a larger vocabulary. Interviewers expect decisions under incomplete requirements, limited time and conflicting risks, plus clear communication of those decisions.
11 An API returned 202 Accepted. How do you test the asynchronous result?
Strong answer review
202 says the request was accepted, not completed. Check for a job identifier or status URL, valid transitions from queued to processing and completed or failed, an agreed timeout, repeated polling and the final business effect. Cover worker failure, duplicate message delivery, two identical commands and an unavailable dependency. The initial response must not promise success too early, and a final failure must be visible to the user and traceable by correlation id.
What it assesses: acceptance versus completion, eventual consistency, observability and duplicate delivery.
Red flag: ending the test at 202 or using a fixed sleep instead of polling an observable state with a timeout.
12 The backend changes an API field. How do you test backward compatibility?
Strong answer review
Identify every consumer and the promised contract: requiredness, type, format, nullability, enum and meaning. Run an old client against the new backend and, when rollout permits it, a new client against the old backend. Adding an optional field is often compatible; removing or renaming a field, changing its type or introducing a required enum value may break consumers. Test unknown-field handling, defaults, serialisation, versioning and contract tests. A migration plan needs an overlap period, usage telemetry for the old field and a removal date.
What it assesses: consumer-driven thinking, both compatibility directions and a gradual rollout plan.
Red flag: assuming every additive change is safe for strict parsers or testing only the current web client.
13 An automated test fails intermittently without a product change. What do you do?
Strong answer review
Keep the trace, screenshot, network data and logs from the exact run, then compare a passing and failing execution. Classify the likely source: waits and race conditions, shared data, order dependence, network, an external system, clock behaviour or a genuinely intermittent product defect. A rerun measures frequency but is not a fix. A quarantined test needs an owner, deadline and visible signal. Fix the condition with observable waits, isolated data or a stable contract instead of an unconditional sleep.
What it assesses: evidence-led diagnosis, flaky test versus flaky product and accountable quarantine.
Red flag: retrying until green or deleting the test before understanding the failure.
14 How do you test a feature behind a feature flag?
Strong answer review
Build a matrix for flag off and on, new and existing accounts, roles or cohorts, web and API, caches and multiple instances. Off must preserve the old behaviour; on must cover the new path and data migration. Check runtime switching, percentage rollout, cohort leakage, metrics and rollback. Once rollout is complete, remove the flag, dead branch and obsolete tests; otherwise the number of states grows without limit.
What it assesses: both states, segmentation, consistency, observability and the complete flag lifecycle.
Red flag: checking only the on state in one browser or forgetting existing data and rollback.
15 What should QA verify after a production deployment?
Strong answer review
Before release, agree on a small production smoke using read-only actions or safe synthetic data, dashboards, thresholds and rollback conditions. After deployment, verify health and version, a critical user path, 4xx and 5xx rates, latency, queues, a business metric and correlated logs. Compare against a baseline and separate release impact from normal noise. Record the time, version, checks, observations and the decision to continue rollout or roll back.
What it assesses: production safety, technical and business signals, and predefined stop conditions.
Red flag: experimenting on a real customer record or declaring success because the home page opens.
16 Release is tomorrow, but full regression takes two days. What do you do?
Strong answer review
I would collect the changes and affected areas, identify critical business flows and select tests by probability and impact. Smoke, changed functionality, money, access, data loss, integrations and defect-prone areas come first. I would state what remains uncovered and what residual risk the team accepts. If that risk is unacceptable, I would propose reducing release scope or moving the release.
What it assesses: risk-based selection, coverage transparency and useful options for the team.
Red flag: “I will stay late and test everything” without feasibility, or cutting cases at random.
17 A bug reproduces roughly once in ten attempts. How do you investigate it?
Strong answer review
I would record environment, account, data, time and exact sequence, then collect logs, Network data and a correlation id. I would vary one factor at a time: browser, network, repeated action, data volume and concurrency. I would compare successful and failed requests and measure frequency across a series. Even without stable steps, a high-impact issue deserves a report with evidence and a clearly labelled hypothesis.
What it assesses: experimental discipline, evidence collection and no invented causality.
Red flag: closing it as “cannot reproduce” after two tries, or presenting a guessed cause as fact.
18 The requirement says: “search must be fast and convenient.” How do you test it?
Strong answer review
I would turn the adjectives into measurable criteria: data volume, acceptable response time, searchable fields, partial matches, case, keyboard layout, typos, sorting and empty results. Before clarification I can explore current behaviour and risk, but I cannot call a subjective expectation a confirmed defect. The output is a list of product questions and draft tests with explicit assumptions.
What it assesses: requirement testability and the distinction between a question and a confirmed defect.
Red flag: deciding alone that “fast” means two seconds and reporting every deviation as a bug.
19 A CRM manager can see another manager’s client. How do you test and report it?
Strong answer review
I would use two accounts with the same role and an object owned by A. With B’s token I would request that id through the UI and directly through the API, then test read and update actions. The report includes both accounts, roles, object id, request and response, with personal data redacted. This may be Broken Object Level Authorization, so I would escalate it through the team’s security process.
What it assesses: horizontal authorisation, reproducibility and careful handling of sensitive data.
Red flag: reporting only the visible button, or attaching unredacted customer data to a broadly visible tracker.
20 A double-click creates two payments. What do you test besides the button?
Strong answer review
I would test rapid clicks, repeating the same HTTP request, retry after timeout, the same and a new idempotency key, concurrent requests and a retry from another device. At each step I would compare the API response, operation count and final balance. Disabling the button helps UX, but the backend must provide the guarantee because requests can be repeated without the UI.
What it assesses: idempotency, races and the difference between UI protection and a server guarantee.
Red flag: stopping at a disabled button and never replaying the request directly.
Ten-minute API exercise
Requirement: a manager may read only their own clients. Without changing server data, design the smallest request set that verifies this rule. Then open the review.
GET /api/clients/{id}\nAuthorization: Bearer {token}\n\nmanager_a owns client 481\nmanager_b owns client 927
A good answer covers the boundaries of the access model, not one foreign id:
- A requests 481: expect 200 and A’s client data.
- B requests 927: expect 200 and B’s client data.
- A requests 927 and B requests 481: expect 403 or 404 according to the contract.
- No token and an invalid token: expect 401.
- Unknown id: verify the agreed 404 and that responses do not leak a difference between foreign and absent objects.
Show the answer rubric
The minimum is two positive and two crossed requests. A strong candidate adds missing authentication, an unknown id, mutation through PATCH/DELETE and checks for excessive response fields. An excellent candidate first asks whether a foreign object should return 403 or be hidden as 404 instead of inventing the contract.
Seven-day preparation plan
Common preparation questions
How long is a technical QA interview?
Often 45–90 minutes, but formats vary: theory, experience, scenarios, API or SQL, and sometimes a separate take-home task. It is reasonable to ask the recruiter for the structure in advance.
Does a Junior tester need SQL and Postman in 2026?
For many manual QA roles, a confident foundation is enough: read JSON, send requests with parameters and auth, inspect responses, and write SELECT with WHERE and a simple JOIN. Applying these skills matters more than naming commands.
Is it acceptable to say “I don’t know”?
Yes. State the boundary and explain how you would resolve it: clarify the contract, read documentation, reproduce a request or inspect a log. A confident invention is more dangerous than an honest gap.
How do I know I am ready?
You are ready when you can explain a decision without notes, name the expected result and ask useful questions about an unfamiliar scenario. You do not need perfect answers to every possible question.
Preparation is complete not when you have read a hundred answers, but when you can reason through a new task aloud: clarify it, choose the risk, propose a check and name the evidence.