25 QA Engineer Interview Questions & Testing Answers

QA interviews have quietly transformed. The role is no longer "person who clicks through the app before release," and interviews now probe for engineering judgment: what to automate, what to leave manual, and how to find the bug that matters before users do. Candidates who still prep for the old role walk in answering questions nobody asked.

The key idea: Testing is risk management. You can never test everything, so the job is deciding what to test, how deeply, and in what order — and being able to defend those choices with a risk argument.

The question taxonomy

• Test design. Boundary value analysis, equivalence partitioning, state transitions. "How would you test this form?" is a design question, not a list-making exercise.
• Automation strategy. The test pyramid, what belongs at each level, why end-to-end suites rot.
• Automation craft. Writing a test, handling flakiness, selectors and waits, test data management.
• Quality process. Bug reports, severity vs priority, when to block a release.
• Specialised testing. API, performance, security, accessibility — expect at least one, depending on the role.

Worked example: "test a login form"

The most famous QA question, and the most fumbled. Don't list test cases randomly — show a system:

1. Happy path: valid credentials succeed; invalid credentials fail with a generic message (never "wrong password" — that leaks which part failed).
2. Boundaries: empty fields, maximum-length input, leading/trailing whitespace, unicode and emoji in passwords.
3. Security: SQL injection strings, XSS payloads in the username, brute-force lockout and rate limiting, password field masking, HTTPS only.
4. State and edge behaviour: session expiry, back button after logout, concurrent logins, "remember me" across browser restarts.
5. Non-functional: accessibility with a screen reader, behaviour on slow networks, mobile layouts.

That structure — happy path, boundaries, security, state, non-functional — transfers to any "test this thing" question you'll ever get. The framework is the answer; the cases are proof.

How answers get scored

Rubrics reward risk-based prioritisation (saying "I'd test payment flows deepest because failure there costs the most" shows judgment), automation realism (knowing that a flaky end-to-end suite everyone ignores is worse than a small trustworthy one), and communication — a well-written bug report with repro steps and expected/actual behaviour is still a core skill interviewers explicitly ask about.

Common mistakes

• Proposing to automate everything. Some things — exploratory testing, usability, brand-new features — resist automation, and saying so shows maturity.
• Writing brittle selectors and fixed sleep() waits, then calling the resulting flakiness "the app's fault."
• Conflating severity (impact) with priority (urgency). A crash on an obscure settings page is high severity, low priority.
• Listing test cases without any organising principle in design questions.

The flakiness question

"Your end-to-end suite is flaky — what do you do?" Every automation-heavy loop asks some version of this, because every real suite suffers it. A strong answer has a system: first, quantify — which tests fail most, and is the failure in the test or the product? Second, fix the common causes in order of frequency: fixed sleeps replaced by explicit waits on conditions, brittle selectors replaced by stable test IDs, tests that share state made independent, and test data created fresh per run instead of assumed. Third, quarantine the incorrigible — a flaky test that runs but doesn't gate is honest; a flaky test everyone ignores is poison. Fourth, push coverage down the pyramid: anything that can be verified in a fast integration test shouldn't live in a browser test at all. That last move — deleting end-to-end tests on purpose — is the senior answer, because it shows you optimise the signal, not the test count.

FAQ

How much coding do QA roles expect now? Most automation roles expect real programming — usually Python, Java, or JavaScript with a framework like Playwright or Cypress. The Python guide covers the language side.

Is manual testing still valued? Yes, framed as exploratory testing — skilled, intentional, and documented. Undervaluing it in an interview is itself a mistake.

For the development side of the house, see the frontend and backend guides, and rehearse with Aissence practice.