In this article
How to use this list
The questions are grouped by topic and written in our own words; the same themes are reported by candidates for software test engineer roles. Many of those roles also include a coding round, so practice that routine in the coding interview guide. Where an answer rests on a public source it is linked in the sentence; where it is advice on how a strong answer sounds, it says so.
Test design techniques
What is equivalence partitioning?
Equivalence partitioning is a black-box technique that divides input data into partitions, on the expectation that the test object processes every element of one partition in the same way. Therefore one test per partition is sufficient, according to the ISTQB syllabus text on black-box techniques (read October 2026). For an age field you pick one valid value and one from each invalid side, not every possible age; a field that accepts typed text also has non-numeric and empty input as further invalid partitions.
Why it is asked: it shows whether you can cut an unlimited input space to a small, justified set of tests. Read the full explanation: ISTQB black-box test techniques.
What is boundary value analysis, and how does it differ from equivalence partitioning?
Boundary value analysis is a technique that exercises the boundaries of equivalence partitions; a partition's minimum and maximum values are its boundary values (ISTQB glossary, boundary value). Because a boundary needs an order, it applies only to ordered partitions, such as numbers and dates, not to a list of countries (ISTQB syllabus text). A comparison written as less-than instead of less-than-or-equal is exactly what boundary tests catch.
Why it is asked: it separates candidates who know the edges from those who test only a typical value. Read the full explanation: ISTQB glossary, boundary value.
Which black-box test techniques should I know?
The ISTQB syllabus lists four commonly used black-box techniques: equivalence partitioning, boundary value analysis, decision table testing and state transition testing (ISTQB syllabus text). A decision table suits rules that combine several conditions. State transition testing suits behavior that depends on history, such as an account that locks after repeated failed logins.
Why it is asked: naming the technique that fits a feature shows structured thinking, not guessing. Read the full explanation: ISTQB black-box test techniques.
How many tests does an age field that accepts 18 to 65 need?
In this illustrative example, equivalence partitioning gives three partitions (below the range, inside it, above it), so three tests, such as 10, 30 and 80. Two-value boundary analysis adds 17, 18, 65 and 66; a three-value variant adds the neighbors too, six values in total. The partition tests plus the two-value boundary tests make seven distinct cases.1 Trying every age from 0 to 120 takes 121 tests. Say which boundary variant you use.
Text description of the diagram
- Equivalence partitioning gives three tests for an age field accepting 18 to 65.
- Two-value boundary analysis adds four tests and the three-value variant six.
- Trying every age from 0 to 120 takes 121 tests.
Why it is asked: it turns the two techniques into a number you can defend. Read the full explanation: ISTQB black-box test techniques.
How do you write a good test case?
A test case is a documented set of preconditions, inputs, actions and expected results that checks one behavior (ISTQB glossary, test case). In practice, give it an ID or title, preconditions, numbered steps, the test data, the expected result and the requirement it traces to. A good one checks a single thing, so a failure points to one cause.
Why it is asked: test cases are the basic unit of a tester's work, and clarity here predicts clarity everywhere else. Read the full explanation: interview questions for quality assurance (QA) roles.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Test strategy
What is the test pyramid?
The test pyramid is a way of thinking about how different kinds of automated tests should be used to create a balanced portfolio. Its essential point, in Martin Fowler's testing guide, is that you should have many more low-level unit tests than high-level tests that run through a graphical user interface. A strong answer adds the reason: the more of the system a test drives, the more can break for unrelated reasons.
Why it is asked: it tests whether you can plan a suite, not only write a test. Read the full explanation: Fowler's testing guide.
Does the test pyramid prescribe 70/20/10?
No. Fowler's summary states a principle, many more low-level tests than interface-driven ones, and calls the result a balanced portfolio, not a fixed ratio (Fowler). The Ministry of Testing glossary describes it as a metaphor for grouping tests into buckets of different granularity. If you quote percentages, say whose version they are, because the summary gives none.
Why it is asked: it catches candidates who repeat a ratio as if it were a rule. Read the full explanation: Ministry of Testing, test pyramid.
What is test-driven development?
Test-driven development is a technique for building software in which writing tests guides the development; Kent Beck developed it in the late 1990s as part of Extreme Programming (Fowler's testing guide). The usual loop is to write a failing test, make it pass with the simplest code, then clean up. It is a way of working, not a kind of test.
Why it is asked: it checks that you do not confuse a development practice with a test level. Read the full explanation: Fowler's testing guide.
Automation and flaky tests
What is a flaky test?
A flaky test is a test that exhibits non-deterministic behavior: it may pass or fail inconsistently without any change in the code under test (Wikipedia, flaky test, read October 2026). Common suspects, as general experience rather than a measured ranking, are timing and waits, data shared between tests, and tests that depend on running order. A flaky suite teaches a team to ignore red results; the Google Testing Blog treats flakiness as a real cost worth managing.
Why it is asked: it probes whether you have maintained automation, not just written it. Read the full explanation: Google Testing Blog, flaky tests.
Does retrying a failed test fix flakiness?
No. A rerun can confirm whether a failure repeats, but it does not remove the cause (Wikipedia, flaky test). A strong answer is to quarantine the test so it stops blocking the team, record it, and find the root cause, for example a missing wait or shared state; the Google Testing Blog discusses rerunning, monitoring and quarantining flaky tests as mitigations. An unlimited automatic retry hides real intermittent defects in the product.
Why it is asked: it shows whether you treat red builds as information. Read the full explanation: Wikipedia, flaky test.
What is an explicit wait in Selenium, and why not use a fixed sleep?
An explicit wait is a loop that polls the application for a specific condition to become true before the code continues; if the condition is not met before the timeout, the code raises a timeout error (Selenium documentation, October 2026). A fixed sleep always pays the full delay and still fails when the page is slower, so waiting on a condition is both faster and steadier.
Why it is asked: waits are a common cause of unstable interface tests. Read the full explanation: Selenium waiting strategies.
Can you mix implicit and explicit waits?
You should not. An implicit wait is a global setting that makes every element lookup retry until a timeout, while an explicit wait applies to one condition. Selenium's documentation warns that mixing them can cause unpredictable wait times; its own example of a 10-second implicit wait with a 15-second explicit wait could time out after 20 seconds (Selenium documentation). Pick explicit waits for conditions and leave the implicit wait off.
Why it is asked: it checks that you know a documented trap, not only the application programming interface (API). Read the full explanation: Selenium waiting strategies.
How do you decide what to automate?
Advice for a strong answer: automate checks that are repeatable, stable and valuable to run often, such as regression checks on core flows, and keep exploratory work, one-off checks and fast-changing screens manual. Place most automation at the low level, following the test pyramid, and keep a few end-to-end checks for the journeys that must never break. State the cost of maintaining each test as part of the choice.
Why it is asked: it shows judgment about return on effort. Read the full explanation: JUnit interview questions, for the low-level tests that most automation should be.
Bugs, scenarios and newer systems
How do you write a good bug report?
Advice for a strong answer: a clear title that states the failure, numbered steps to reproduce, the expected result against the actual result, the build and environment, and evidence such as a log or screenshot. Add how often it happens and how badly it affects users. A developer should be able to reproduce it without asking you a question.
Why it is asked: defects are only useful if someone can act on them. Read the full explanation: interview questions for quality assurance roles.
What is the difference between severity and priority?
Severity is how badly a defect affects the system or its users (ISTQB glossary, severity); priority is how soon it should be fixed (ISTQB glossary, priority). They can disagree: a spelling error in a company name on the home page is low severity but may be high priority, while a crash in a rarely used screen is high severity but may wait. Teams define the scales differently, so ask for theirs.
Why it is asked: it shows you separate technical impact from business order. Read the full explanation: interview questions for quality assurance roles.
How would you test a login page?
Advice for a strong answer: start with partitions, a valid login and each kind of invalid input (wrong password, unknown user, empty fields), then boundaries on field length, then the state behavior such as lockout after repeated failures. Add checks that the error message does not reveal which field was wrong (the OWASP Application Security Verification Standard covers generic authentication failure messages), and that a session ends on logout. Finish with what you would automate first.
Why it is asked: an open scenario shows whether you apply the techniques unprompted. Read the full explanation: interview questions for QA.
How do you test a feature built on a language model?
Advice for a strong answer: exact-string assertions fail because the output varies, so assert properties instead, such as the required format, the facts that must appear and the content that must not. Keep a fixed set of prompts with a scoring rubric, review a sample by hand, and compare results across versions. Put ordinary deterministic tests around the parts you control, such as parsing and tool calls.
Why it is asked: it checks that you can adapt test design to non-deterministic output. Related reading: Fowler's testing guide, which notes that tests differ by what they verify and how much code they cover.
Follow-up questions
What are software test engineer interview questions?
Software test engineer interview questions cover four groups: test design techniques, test strategy, automation and flaky tests, and bug handling with scenario questions. Many roles also add a coding round in a language such as Java or JavaScript, so prepare the language your test code uses.
What are AI test engineer interview questions?
Questions about testing artificial intelligence (AI) features focus on non-deterministic output, evaluation sets and how you would judge quality without one exact right answer; see the language-model question above.
Do specific companies ask different test engineer questions?
Candidates report variations, but this page cites no public source for what any named company asks, so it claims none. Read the job description and prepare for the tools and levels it names.
What is a t test, and is it part of test engineer interviews?
A t-test is a statistical hypothesis test, a different subject from software testing, and this page does not cover it. Online assessment platforms such as coding-test sites are also a different topic; the coding routine is in the coding interview guide.
- Use equivalence partitioning for one test per partition, then boundary value analysis on ordered partitions.
- The test pyramid asks for many more low-level tests than interface-driven ones; it is not a fixed ratio.
- A retry confirms a flaky failure but does not fix it; find the cause and quarantine meanwhile.
- Prefer explicit waits on a condition, and do not mix them with implicit waits.
- A good bug report lets someone reproduce the defect without asking you anything.
Sources
- Software Testing Guide (Martin Fowler) — martinfowler.com, 26 Oct 2026
- 4.2 Black-Box Test Techniques (ISTQB Foundation Level Syllabus) — ASTQB (US board of ISTQB), 26 Oct 2026
- boundary value (ISTQB Glossary) — ISTQB, 26 Oct 2026
- Waiting Strategies (Selenium documentation) — Selenium, 26 Oct 2026
- Flaky Tests at Google and How We Mitigate Them (Google Testing Blog) — Google Testing Blog, 27 May 2016
- test case (ISTQB Glossary) — ISTQB, 26 Oct 2026
- severity (ISTQB Glossary) — ISTQB, 26 Oct 2026
- priority (ISTQB Glossary) — ISTQB, 26 Oct 2026
- OWASP Application Security Verification Standard — OWASP, 26 Oct 2026
- Flaky test (Wikipedia) — Wikipedia, 26 Oct 2026
- Test Pyramid (Ministry of Testing glossary) — Ministry of Testing, 26 Oct 2026
