50 QA tester interview questions with answers

How to use this list

I organised the questions around the ISTQB Foundation Level syllabus (v4.0) and then added the topics that come up most often in interviews: APIs, automation and test strategy. Each section is marked with a level, so it is easy to pick a starting point.

The answers are short on purpose. Nobody in an interview expects you to recite definitions. The interviewer wants to see whether you understand a concept and can apply it. So for every answer, have one example from your own work ready, even if it comes from a training project.

Where it matters, I added a tip on how to go beyond the definition.

Testing fundamentals

Level: basic.

1. What is software testing?

It is a set of activities that evaluate the quality of a product and reduce the risk of failures after release. It covers more than running the application: planning, analysing requirements, designing tests and reporting are all part of it. Testing provides the information the team uses to decide whether the product is ready.

Tip: talk about information and risk, not only about “finding bugs”. A tester who understands why they test makes better choices about what to test.

2. What is the difference between an error, a defect and a failure?

• An error (mistake) is a human action, for example a developer misunderstood a requirement.
• A defect (bug) is the result of that mistake in the code or documentation.
• A failure is what happens when the defect shows up while the system is running.

Not every defect leads to a failure. Code with a defect may never be executed, or may give the correct result for most inputs.

3. List the ISTQB testing principles.

1. Testing shows the presence of defects, not their absence.
2. Exhaustive testing is impossible.
3. Early testing saves time and money.
4. Defects cluster together.
5. Tests wear out (the pesticide paradox).
6. Testing is context dependent.
7. Absence-of-defects fallacy.

Tip: the list alone says little. Have a real-life example of one principle ready. A payment module that produces bugs every sprint, for instance, is defect clustering.

4. What is the difference between verification and validation?

Verification checks whether the product meets its specification (“are we building the product right”). Validation checks whether it meets the user’s needs (“are we building the right product”). An application can match the requirements and still be useless if the requirements were wrong.

5. What is the difference between quality assurance (QA), quality control (QC) and testing?

• QA is about the process: how the team works so that fewer defects are made (reviews, standards, definition of done).
• QC is about the product: checking whether a specific work product has the right quality.
• Testing is the main form of quality control.

In job ads “QA” often simply means a tester, but in an interview it is worth showing that you know the difference.

6. When do you stop testing?

When the exit criteria agreed with the team are met, for example all planned tests executed, no open critical defects, the agreed requirements coverage reached. In practice testing also ends when time runs out and the remaining risk is acceptable to the business.

Tip: do not answer “when there are no more bugs”. According to principle 1, that moment never comes.

Testing throughout the software development lifecycle

Level: basic.

7. What are the test levels?

• Component testing (unit testing): individual functions or classes, usually written by developers.
• Component integration testing: how components work together within one system.
• System testing: the whole system against its requirements.
• System integration testing: how the system works with external systems, such as a payment gateway.
• Acceptance testing: whether the system meets the needs of users and the business.

8. What is the difference between functional and non-functional testing?

Functional tests check what the system does: whether a transfer goes through, whether a filter returns the right results. Non-functional tests check how it does it: speed, security, usability, accessibility, compatibility.

9. What is the difference between black-box and white-box testing?

In black-box testing you design test cases from the specification and the behaviour, without looking at the code. In white-box testing you base them on the code structure, for example so that every branch of a condition is executed. A manual tester works mostly black-box, a developer writing unit tests mostly white-box.

10. What is the difference between a retest and a regression test?

A retest (confirmation test) checks whether a specific fixed defect is really fixed. A regression test checks whether a change broke something that used to work. After a fix you usually do both: the retest first, then regression of the areas around the change.

11. What are smoke tests and how do they differ from sanity tests?

Smoke tests are a short set that checks whether the most important functions work at all and whether the build is fit for further testing. Sanity tests are a quick, narrow check of a specific area after a change. The terms are often used interchangeably, so it is worth asking how a given team understands them.

12. What is acceptance testing and who does it?

Acceptance testing confirms that the system meets the user’s needs and is ready for release. It is often done by the client or a business representative (UAT), sometimes with support from testers. The group also includes regulatory acceptance testing and operational acceptance testing (for example backups and disaster recovery).

Test design techniques

Level: basic and intermediate.

13. What is equivalence partitioning?

You split the input data into groups that the system should treat the same way and take one value from each group. For an “age” field that accepts 18-65, there are three partitions: below 18, from 18 to 65, above 65. Instead of testing dozens of values you test three, plus the invalid partitions such as text or an empty field.

14. What is boundary value analysis?

You test values at the edges of the partitions, because that is where bugs tend to be (for example > instead of >=). For the 18-65 range, two-value boundary analysis gives 17, 18, 65 and 66. Three-value analysis adds the values next to each boundary on the valid side: 19 and 64.

Tip: this question often comes as a task: you get a field with a range and have to suggest test values. A good answer has the boundaries, the values just outside them and the invalid partitions. An even better one asks about the requirement: is 65 still a “yes”?

15. When do you use a decision table?

When the result depends on a combination of several conditions. Example: a discount depends on whether the customer has a loyalty card and whether the order exceeds 200 EUR. The table shows every combination of conditions and the expected result for each, so it is easy to spot a case nobody thought of.

16. What is state transition testing?

You describe an object as a set of states and the transitions between them, then test both valid and invalid transitions. A typical example is an order: new, paid, shipped, delivered, cancelled. A test question might be: can you cancel an order that has already shipped?

17. What is exploratory testing and when does it make sense?

It is learning the application, designing tests and running them at the same time. The tester works towards a goal (a test charter) within a time box and takes notes as they go. It works well for new features, poor documentation and as a complement to scripted testing, because it finds bugs nobody anticipated in the test cases.

18. What is the difference between a test case, a test scenario and a checklist?

• Test case: preconditions, steps, data and the expected result for a single check.
• Test scenario: a more general description of what to check, for example “guest checkout”, often covering several test cases.
• Checklist: short items to verify, without detailed steps.

The more experienced the team and the more stable the product, the more often checklists are enough.

Static testing

Level: basic.

19. What is static testing and what can you check with it?

It is testing without running the code: reviews of requirements, user stories, designs and code, plus static analysis with tools. It catches a defect in a requirement before anyone writes code based on it. That is the cheapest moment to find a bug.

20. What types of review do you know?

According to ISTQB: informal review, walkthrough (led by the author), technical review (led by experts, aimed at technical consensus) and inspection (the most formal, with roles, metrics and exit criteria). In everyday work you will mostly see informal reviews and code review in pull requests.

Defects and reporting

Level: basic and intermediate.

21. What should a good defect report contain?

• a title describing the symptom and the location;
• the environment and application version;
• preconditions (account, data, settings);
• steps to reproduce, from the very beginning;
• the expected result and the actual result, separately;
• reproducibility (for example 3 out of 5 attempts);
• attachments: screenshot, recording, logs, API request and response;
• severity and a suggested priority.

I cover this in more detail in the guide on how to report defects.

Tip: instead of reciting fields from memory, show an example of a report a developer can reproduce without asking any questions.

22. How do you write a good defect title?

The title should say where and what happens, because the team reads it in a list without opening the report. “Bug in cart” says nothing. “Cart: discount code disappears after changing product quantity” says everything triage needs.

23. What is the difference between priority and severity?

Severity describes the technical impact: how badly the defect breaks the system. Priority describes how quickly it needs to be fixed from a business point of view. A typo in the company name on the home page has low severity and high priority. A crash in a rarely used report can have high severity and low priority.

Tip: almost everyone knows the definition. Have your own example of a defect where priority and severity diverge.

24. What does the defect lifecycle look like?

Typically: new, assigned, in progress, fixed, ready for retest, closed. Plus side states: rejected, duplicate, deferred, reopened. The exact statuses depend on the tool and the team, so more important than the names is who makes the decision at each stage.

25. What do you do when a developer rejects a defect you reported?

First I check whether I am right: I go back to the requirement and reproduce the bug again. If the requirement is unclear, it is not a dispute between tester and developer but a question for the product owner. I talk about the impact on the user rather than who is right, and I add what we agreed to the report.

26. What do you do with a defect you cannot reproduce?

I collect everything I know: the time, environment, account, logs from that moment, a recording. I try changing one factor at a time: browser, data, the order of steps, click speed, network connection. If it still does not reproduce, I report it with a reproducibility of “1 in 10” and everything I collected. Such a report has value too, especially when the bug comes back.

27. What should a test report contain?

A test report is different from a defect report: it describes the state of the whole testing effort, not a single bug. It usually contains:

• the scope and period of testing, the version and environment;
• what was tested, what was not, and why;
• results: the number of tests passed, failed and blocked;
• open defects by severity, especially critical ones;
• risks and deviations from the plan;
• a recommendation: whether the version is ready for release and under what conditions.

Tip: a good report ends with a conclusion. A project manager does not need a table of numbers, they need an answer to “do we release or not, and with what risk”.

APIs

Level: intermediate.

28. What is a REST API and how do you test it?

A REST API is an interface where resources (for example /orders) are handled with standard HTTP methods and data is usually sent as JSON. When testing an API, I send requests with valid and invalid data and check the status code, body, schema, headers and response time. Typical tools are Postman for manual testing and RestAssured or Playwright for automation.

29. Which HTTP methods do you know and what are they for?

• GET retrieves a resource;
• POST creates a new resource or triggers an operation;
• PUT replaces the whole resource;
• PATCH changes part of a resource;
• DELETE removes a resource.

Less often you will see HEAD (headers only) and OPTIONS (available methods, used among others by CORS).

30. What are the groups of HTTP status codes?

• 1xx informational;
• 2xx success;
• 3xx redirection;
• 4xx client error, meaning the request is invalid;
• 5xx server error.

A rule of thumb for testing: invalid input from the client should return 4xx. If you send a wrong date format and get 500, that is a defect, because the server did not handle the user’s mistake.

31. Walk me through the most important status codes.

Tip: the difference between 401 and 403 is a common question. 401 means “I don’t know who you are”, 403 means “I know who you are, but you don’t have access”. Another common one: when 400 and when 422. There is no single right answer here; what matters is that the team agrees on one convention and sticks to it.

32. What do you check in an API response besides the status code?

• the body: whether the data is correct, not just present;
• the schema: field types, required fields, date formats;
• headers, for example Content-Type, cache and security headers;
• error messages: whether they are clear and do not leak technical details (such as a stack trace);
• response time;
• side effects: whether the record was actually saved to the database or the email was sent.

I write more about schema checks in the guide on API contract testing.

33. What is idempotency?

An operation is idempotent if running it several times has the same effect as running it once. GET, PUT and DELETE should be idempotent, POST usually is not. In practice I test this by sending the same request twice, for example with payments: a double click must not charge the customer twice.

34. How do you test authentication and authorisation in an API?

I call every endpoint without a token, with an expired token, with another user’s token and with a role that lacks permissions. The most common serious bug is access to someone else’s data after swapping the identifier in the URL, for example /orders/1001 instead of /orders/1000. These tests are not visible in the UI, which is why they are done at the API level.

Automation

Level: intermediate.

35. Which tests are worth automating and which are not?

Worth automating: repeatable, stable and frequently run tests such as regression, smoke, API tests and data-driven tests. Not worth automating: features that change often, one-off checks, and judgements about look and usability. Automation pays off after many runs, so what matters is how often a test will be executed.

36. What types of waits are there in Selenium?

• Implicit wait: a global time during which the driver keeps retrying to find an element before throwing an error. Set once for the whole session.
• Explicit wait: WebDriverWait with a condition, for example the element is visible or clickable. It waits for a specific state of a specific element.
• Fluent wait: an explicit wait with a configurable polling interval and a list of exceptions to ignore.

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement button = wait.until(ExpectedConditions.elementToBeClickable(By.id("submit")));

The Selenium documentation advises against mixing implicit and explicit waits, because wait times become unpredictable.

Tip: be ready to explain what is wrong with Thread.sleep(5000). A fixed pause slows the tests down when the application is fast and is not enough when it is slow.

37. How does waiting work in Playwright?

Playwright waits automatically: before a click it checks that the element is visible, stable, enabled and receives events. Assertions such as await expect(locator).toBeVisible() retry until they pass or time out. As a result manual waits are rarely needed and tests are more stable than in Selenium. You will find examples in the guide on regression automation in Playwright.

38. How do you choose locators?

Preferably by what the user sees or by what is meant for testing: role and accessible name (getByRole), field label, a data-testid attribute. The worst are long XPath paths and CSS classes used for styling, because they break with every visual change. If good locators are missing, ask the developers to add data-testid; it takes them a few minutes.

39. What is the Page Object pattern?

It is a way of organising test code: each page or component has a class with locators and actions (for example LoginPage.login(user, password)), and the tests use those methods. When the UI changes, you fix one place instead of ten tests. The downside is an extra layer of code, so with just a few tests it can be overkill.

40. What do you do with flaky tests?

First I find the cause: waiting for an element, dependencies between tests, shared data, the environment, or a real bug in the application that occurs randomly. I mark the flaky test and move it to quarantine so it does not block the team, but with a deadline for the fix. Retrying tests without looking for the cause hides the problem, and sometimes a real bug.

Performance and other non-functional testing

Level: intermediate.

41. What types of performance testing do you know?

• Load testing: behaviour under expected traffic.
• Stress testing: what happens above expected traffic and where the breaking point is.
• Spike testing: a sudden surge in traffic, for example the start of a sale.
• Soak (endurance) testing: steady traffic for many hours, which reveals issues such as memory leaks.

42. Which metrics do you look at in performance testing?

Response time as percentiles (p95, p99), not just the average, because the average hides slow requests. Then throughput (requests per second), error rate and server resource usage: CPU, memory, database connections. A result only makes sense against a target, for example “p95 under 800 ms with 200 users”. I describe an example setup in the guide on performance testing with JMeter.

43. What would you check in basic security testing?

A tester without a security specialisation can check quite a lot: access to other users’ data after changing an identifier, role permissions, input validation (for example a script in a text field), session expiry after logout, error messages that reveal system details, and limits on login attempts. A full penetration test is a separate specialisation, and it is worth saying so directly.

Strategy and process

Level: advanced.

44. You join a project where nobody has been testing. Where do you start?

By understanding the product and the risks: talking to the product owner and developers, reviewing production incidents, mapping the key user journeys. Then quick exploratory testing of the most important areas and a short smoke set before every release. I build the process and automation gradually, starting where bugs cost the most. That is also where I start a QA audit.

Tip: start your answer with questions rather than a tool. “I will set up Selenium” as the first sentence is the wrong order.

45. What is risk-based testing?

You rate each area by the likelihood of failure and its impact, then allocate testing according to that product. Payments and login get the most attention, the “About us” page the least. With limited time you know what you are not testing and can communicate it deliberately.

46. What is the test pyramid?

It is a model of proportions: many fast unit tests at the bottom, fewer integration and API tests in the middle, the fewest UI tests at the top. UI tests are the slowest and most brittle, so they should not be the main safety net. An inverted pyramid (almost everything through the UI) is a common problem in teams that started automation with Selenium.

47. What metrics do you use to measure quality and testing work?

Useful ones: defects found in production compared with those found before release, time from report to fix for critical defects, regression duration, and coverage of requirements or risks by tests. Bugs reported per tester or the number of test cases are bad metrics, because they reward quantity rather than outcome.

Tip: show that you know what behaviour a given metric will drive. Any metric that becomes a target starts being “optimised”.

48. How do you build tests into CI/CD?

A short smoke set runs on every pull request, full regression at night or before a release. The result has to be fast and trustworthy, otherwise the team will start bypassing it. Add test reports available in the pipeline and a clear rule for what happens when a test fails. I go into detail in the guide on regression in CI.

49. How do you test when there are no requirements?

Requirements always exist, they just are not written down. I look for them in conversations with the product owner, in the working version, in competitors’ products, in user feedback and in regulations. Exploratory testing helps me learn how the system behaves, and I write down every questionable behaviour as a question. The answers become the start of the documentation.

Practical tasks

Level: any.

50. How would you test a login form?

This question tests how you think, not whether you know definitions. A good answer covers several layers:

• functional: valid credentials, wrong password, non-existent user, empty fields, letter case in the email, leading and trailing spaces;
• security: lockout after several failed attempts, the same message for a wrong login and a wrong password, the password not visible in the URL or logs, session expiry;
• usability and accessibility: keyboard navigation, Enter submits the form, password managers work, messages are clear;
• other: “remember me”, password reset, logging in on several devices, behaviour on a slow connection, different browsers and phones.

Tip: before listing tests, ask questions: who logs in, is there sign-in with Google, is there two-factor authentication. The same goes for the classic “test this pen”: it is not about the pen, it is about whether you ask what it is for.

Final thoughts

In an interview, showing how you think matters more than definitions: you ask questions, assess risk and describe problems so that others can fix them. If you are preparing for your first job, start with the sections marked as basic and add your own example to every question. I cover the topics from this list in more depth in the “Testing from scratch” series, which starts with what a software tester does and how to get started.

If you run a team and need an experienced tester for a project, or want to put your testing in order, get in touch.