QA interview questions

Tell me about yourself.

What a good answer covers

• A shape, not a life story: what they do now, one thing they are good at, why this role.
• Under two minutes.
• Ends pointed at the job rather than trailing off.

What is the difference between severity and priority?

What a good answer covers

• Severity is impact on the system; priority is urgency of the fix.
• They are independent — the candidate should say so explicitly.
• An example of high severity with low priority, or the reverse. A crash in a feature nobody uses; a typo in the company name on the landing page.

What makes a good bug report?

What a good answer covers

• Steps to reproduce that someone else can actually follow.
• Expected versus actual, stated separately.
• Environment, build or version.
• Evidence: logs, a screenshot, a network trace.
• A title that says what is broken, not 'it doesn't work'.

A bug only reproduces sometimes. How do you handle it?

What a good answer covers

• Look for the variable: timing, data, state left over from a previous run, environment.
• Raise it anyway, with a frequency — 'three times in twenty runs' is data.
• Logs and instrumentation rather than more manual attempts.
• Does not say 'I'd keep trying until it happens again' and stop there.

How would you test a field that accepts a number between 1 and 100?

What a good answer covers

• Boundaries: 0, 1, 100, 101.
• Equivalence classes rather than every value.
• Non-numeric input, empty, negative, decimals, very long input.
• Names the technique — boundary value analysis, equivalence partitioning.

How would you test a login page?

What a good answer covers

• Splits functional from non-functional rather than listing cases at random.
• Valid and invalid credentials, empty fields, case sensitivity.
• Security: lockout after failed attempts, password not in the URL, session handling on logout.
• Usability and accessibility get a mention.

You are asked to test a feature and there are no requirements. What do you do?

What a good answer covers

• Does not refuse to test.
• Finds the sources that exist: designs, tickets, the person who asked for it, the existing behaviour.
• Exploratory testing with notes that become the requirements.
• Writes down the assumptions and gets them confirmed.

How do you decide what goes in a regression suite?

What a good answer covers

• Risk: what breaks most often, what hurts most when it breaks.
• Critical paths and anything that touches money or data.
• Areas the change actually touched.
• Recognises the suite has to stay fast enough to run, so it is pruned as well as grown.

The release is tomorrow and you have found a serious bug. What do you do?

Senior. Marked against your own answer in the app.

What does QA do before there is anything to test?

Senior. Marked against your own answer in the app.

What is the difference between smoke and sanity testing?

What a good answer covers

• Smoke: wide and shallow, does the build work at all, run first.
• Sanity: narrow and deep, does this specific fix or area behave, run after a change.
• Does not confuse the two or claim they are the same thing.

What would you choose not to automate?

What a good answer covers

• Anything run once, or rarely.
• Areas still changing shape every sprint — the maintenance cost exceeds the benefit.
• Exploratory work, usability, and anything needing a human eye.
• Shows they think about cost of maintenance, not only cost of writing.

One of your automated tests fails about one run in five. What do you do?

What a good answer covers

• Does not say 'add a retry' as the fix.
• Common causes: implicit waits and timing, shared or leftover test data, test order dependence, an actual race in the product.
• A flaky test that is quarantined without being fixed is a test nobody trusts.
• Considers that it might be finding a real bug.

Explicit waits versus implicit waits — which do you use, and why?

What a good answer covers

• Explicit: waits for a specific condition, so it is both faster and more precise.
• Implicit is global and interacts badly with explicit waits when both are set.
• Thread.sleep is a smell — a fixed delay is either too short or wasted time.

What is the Page Object Model, and what does it buy you?

What a good answer covers

• Locators and page interactions live in one place per page.
• A UI change is then one edit rather than fifty.
• The test reads as intent rather than as selectors.
• Bonus: knows it can be over-applied, and that the object should expose actions not elements.

How do you choose a locator for an element?

What a good answer covers

• Prefers something stable and meaningful: a test id, a role, a label.
• Avoids brittle absolute XPath and generated class names.
• Will ask developers to add a test id rather than working around its absence.

When would you test something at the API level rather than through the UI?

What a good answer covers

• Faster, less brittle, and it isolates where the fault actually is.
• Business logic, validation, error handling, and data setup for UI tests.
• The UI test then only has to cover the UI.

You are testing a POST endpoint. What do you check?

What a good answer covers

• Status code, and that it is the right one — 201 rather than 200 for a creation.
• Response body shape and content.
• The side effect actually happened — check the database or a subsequent GET.
• Auth: missing token, wrong user's token.
• Bad input: missing fields, wrong types, oversized payloads.
• Idempotency or duplicate submission.

What is the difference between a 401 and a 403?

What a good answer covers

• 401: not authenticated — we do not know who you are.
• 403: authenticated but not allowed.
• A concrete example of each.

How do you use SQL in your testing?

What a good answer covers

• Verifying that a UI action wrote what it should have.
• Setting up test data and cleaning it up afterwards.
• Names actual constructs: joins, where, count, order by.
• Understands that checking the UI alone can miss a write that silently failed.

What is the test pyramid, and do you agree with it?

What a good answer covers

• Many unit, fewer integration, fewest end-to-end.
• The reason: cost, speed and stability go the wrong way as you climb.
• An opinion, held for a reason — the shape depends on the system.

How do you know your testing is any good?

Senior. Marked against your own answer in the app.

A developer closes your bug as 'works as designed'. What happens next?

What a good answer covers

• Checks first whether they are right.
• Brings evidence, not volume.
• Reframes around user impact rather than who is correct.
• Escalates to the person who owns the requirement, calmly, if it is still unresolved.

Where do your automated tests run, and when?

What a good answer covers

• In the pipeline, not only on a laptop.
• Different suites at different stages: fast on every commit, fuller before release.
• What happens when they fail — who is told, and whether the build stops.
• Test data and environment for a pipeline run.

You are the first tester on a new project. How would you build the automation framework from scratch?

Senior. Marked against your own answer in the app.

Which object-oriented ideas do you actually use in a test framework?

What a good answer covers

• Inheritance for a base test or base page — and awareness that deep hierarchies hurt.
• Encapsulation: locators private, actions public.
• Composition over inheritance when they have been burned by the latter.
• Concrete: names a class in their own framework rather than reciting definitions.

An element's id changes on every page load. How do you write a reliable locator for it?

What a good answer covers

• Anchors on something stable: text, role, label, a parent with a test id, relative position.
• Knows the CSS or XPath to express that, not just the principle.
• Asks the developer for a test id as the real fix.
• Does not reach for a sleep or a retry loop to paper over it.

Talk me through the code you would write to check that a user can log in and see their name in the header.

What a good answer covers

• Arrange, act, assert — setup, the action, then one meaningful assertion.
• Asserts on the name being right, not merely that an element exists.
• Test data comes from somewhere repeatable, not a hardcoded live account.
• Cleans up or is independent of other tests.
• Speaks in real syntax for a real tool rather than pseudocode.

You need to run the same test against forty sets of input. How do you structure that?

What a good answer covers

• Data-driven: the data lives outside the test, in a file or a provider.
• Names the mechanism in their tool — parameterised tests, a data provider, a fixture.
• One failing row does not stop the other thirty-nine.
• A failure report says which row failed.

Your suite takes ninety minutes. How do you make it faster?

Senior. Marked against your own answer in the app.

How do your tests get from your machine into the shared suite?

What a good answer covers

• Branch, commit, pull request, review — the same workflow as the developers.
• Their test code is reviewed by someone.
• Handles a merge conflict without alarm.
• Bonus: tests live in the same repository as the code they test, and why that matters.

What makes automated test code bad, in your experience?

Senior. Marked against your own answer in the app.