Test engineer interview questions, with worked answers

How to use these questions

Read the short answer and say it out loud. That is your first thirty seconds. Then read the full answer and pick two or three points to add, with an example from your own work. Interviewers want to hear how you decide what to test, what you leave out, and how you know it worked.

What a test engineer is expected to know

• Test designAsked in 43% of test engineer ads (as of 5 Nov 2026).Test design: equivalence classes, boundary values, state changes and exploratory sessions. The core of the job at every level.: turning a feature into the few tests that matter, with techniques such as boundary values (testing at the edges of what is allowed) and exploratory testing (learning the product while you test it).
• Test automationAsked in 34% of test engineer ads (as of 5 Nov 2026).Automated checks that run on every change, are fast, stable and easy to read, and that the team trusts.: checks that a machine runs on every change, written so the team trusts them.
• A browser tool: Selenium, Cypress or PlaywrightAsked in 11% of test engineer ads (as of 5 Nov 2026).Browser automation with Selenium, Cypress or Playwright: stable locators, waits done right, and tests that do not flake., and when not to use the browser at all.
• A language: PythonAsked in 33% of test engineer ads (as of 5 Nov 2026).Scripting test data, API checks and small tools; pytest for test suites. Readable code, reviewed like product code., JavaAsked in 8% of test engineer ads (as of 5 Nov 2026).Common in enterprise test automation (JUnit, TestNG, Selenium, REST Assured). Clean, maintainable test code., JavaScriptAsked in 2% of test engineer ads (as of 5 Nov 2026).Needed for Cypress and Playwright tests and for reading the front-end code you test. or TypeScriptAsked in 3% of test engineer ads (as of 5 Nov 2026).The usual language for Playwright suites in newer web teams; typed page objects and test helpers., at the level of clean, reviewed test code.
• APIs and data: testing REST APIsAsked in 0% of test engineer ads (as of 5 Nov 2026).Test APIs directly: status codes, contracts, error cases, authorisation, and the data a call leaves behind. directly, and SQLAsked in 5% of test engineer ads (as of 5 Nov 2026).Check what a test left in the database, build test data, and find the record behind a bug report. to check what a test left behind.
• The pipeline: CI/CDAsked in 17% of test engineer ads (as of 5 Nov 2026).Tests run on every change in the pipeline; a failed check stops the release and the team sees why at once. (the steps that build, test and release every change), GitAsked in 20% of test engineer ads (as of 5 Nov 2026).Branches, pull requests and reviews; test code lives in version control like product code., and DockerAsked in 2% of test engineer ads (as of 5 Nov 2026).Start the app and its database in containers so every test run starts from the same clean state. for clean test environments.
• How the team works: AgileAsked in 10% of test engineer ads (as of 5 Nov 2026).Testing inside the sprint, not after it: refine stories, agree acceptance criteria, test as code lands. and ScrumAsked in 12% of test engineer ads (as of 5 Nov 2026).Know the ceremonies and where a tester adds most: refinement, the definition of done, the review., acceptance criteria, and Test-driven developmentAsked in 0% of test engineer ads (as of 5 Nov 2026).Writing the test before the code. Testers who pair with developers on it shape what gets built. (writing the test before the code) with developers.
• Bugs: clear reports in a tool such as JiraAsked in 18% of test engineer ads (as of 5 Nov 2026).Write clear bug reports and link them to stories and test cases; read a board to see what is at risk., and how a bug moves from found to fixed to checked.

Test strategy and test design

How would you build a test strategy for a new product or a big new feature?

What they check: that you start from risk and the product's users, not from a template; that you mix levels of testing; and that you say how you will know testing is done.

Short answer: "I first find out what the product must never get wrong and who uses it. I list the risks and rank them by how likely they are and how bad they would be. Then I decide what each level of testing covers: many fast unit and API checks, fewer end-to-end tests for the main journeys, and exploratory testing for the new and risky parts. I agree with the team what 'done' means, put the checks in the pipeline, and report risk in plain words."

The full answer, in seven steps:

1. Understand the product. Who uses it, what it must do, what it must never do (lose money, leak data, lock people out), which systems it talks to, and what the law or the industry demands.
2. List and rank the risks. For each part, ask how likely a failure is and how bad it would be. Payment, sign-in and personal data usually come first. This ranking is the heart of the strategy.
3. Decide the levels. Unit tests (developers' small checks of one piece of code), API tests, a small number of end-to-end tests through the user interface, and exploratory sessions. Say which risks each level covers, so the same thing is not tested three times.
4. Decide what is not tested, and why. Writing this down is what makes it a strategy rather than a wish list. Low-risk, stable parts get light checks.
5. Plan the environments and the test data. Where tests run, how data is created and cleaned up, and how personal data is kept out of test systems.
6. Put it in the pipeline. Fast checks on every change, the longer suite every night or before a release, and a clear rule for what stops a release.
7. Agree how you report. Which risks are covered, which are open, and what you recommend. Review the strategy when the product or the risks change.

A weak answer: "I write test cases for every requirement and automate them." No ranking of risk, no levels, nothing left out on purpose.

Follow-up: "You have half the time you planned. What changes?" Keep the highest risks fully covered, cut depth on the low ones, and tell the team in writing which risks are now open.

What is the test pyramid, and do you always follow it?

What they check: that you know why the pyramid exists, and that you can adapt it.

Short answer: "The test pyramid says: many small, fast unit tests at the bottom, fewer API or integration tests in the middle, and only a few slow end-to-end tests at the top. Fast tests give quick feedback and break less. I follow the idea, not the exact shape: what matters is that each risk is tested at the cheapest level that can catch it."

The full answer: UI tests are slow, and they break when a button moves, so a suite made mostly of them (people call it an ice-cream cone) becomes slow and flaky. But some products need a different shape. A front end with little logic may need more component tests. A system that joins many services needs more contract tests (checks that two services agree on the format of their messages). I look at where bugs actually come from and move tests down a level whenever I can.

A weak answer: "We automate everything through the UI, so it is like a real user." Follow-up: "Your end-to-end suite takes two hours. What do you do?" Find the checks that do not need the browser and move them to API tests, run the rest in parallel, and keep only the main journeys end to end.

What is risk-based testing, and how do you do it in a sprint?

What they check: that you can decide quickly what matters most, and explain it.

Short answer: "Risk-based testing means spending test time where a failure is most likely and would hurt most. In refinement I ask what could break and what it would cost, rate each story, and test the high-risk ones deeply and the low-risk ones lightly."

The full answer: I use two simple scales, how likely and how bad, and multiply them. Signs of high likelihood: new code, complex rules, many changes, a part with a history of bugs. Signs of high impact: money, personal data, the law, many users. High-risk stories get test design before the code is written, automated checks, and an exploratory session. Low-risk ones get a quick check. I write the ratings where the team can see them, so the choice is shared, not hidden.

A weak answer: "Every story is tested the same way, to be safe." Follow-up: "The product owner says a story is low risk and you disagree." Show the evidence (past bugs, the data it touches), agree a rating together, and record the decision.

How would you test a sign-up form with an email, a password and a date of birth?

What they check: real test design techniques, not a random list of ideas.

Short answer: "I split each field into groups of values that should behave the same, then test one value from each group and the edges between them. Then I test the fields together, the error messages, security, accessibility, and what happens to the data afterwards."

The full answer: For the date of birth, the groups are too young, old enough, impossible dates and empty; the edges are the day someone turns old enough and the day before. That is equivalence partitioning (groups that behave the same) and boundary value analysis (testing at the edges). For the email: valid, invalid, already used, very long, with capitals. For the password: each rule just met and just missed. Then the whole form: can the same email sign up twice if two people press at once? Is the password never shown or logged? Can someone use it with a keyboard and a screen reader? Does the confirmation email arrive, and is the account created only once?

A weak answer: "I'd try some valid and invalid values." Follow-up: "Which of these would you automate?" The field rules at the API level, one end-to-end sign-up, and the duplicate case; accessibility and odd inputs as exploratory sessions.

When do you use exploratory testing, and how do you make it more than clicking around?

What they check: that you value human testing and can run it with structure.

Short answer: "I use it for new features, risky changes and anything automation cannot judge, such as whether a flow makes sense. I run it as short sessions with a charter, a clear goal for the session, take notes, and report what I covered and what I found."

The full answer: A charter says what to explore, with what, to find what, for example "explore the refund flow with partial refunds to find wrong totals". A session lasts sixty to ninety minutes. I note the paths I tried, the questions it raised and the bugs. Afterwards, any check worth repeating becomes an automated test. That is how exploration and automation help each other.

A weak answer: "Exploratory testing is when there is no time to write test cases." Follow-up: "How do you show a manager what a session covered?" The charter, the notes and a short summary of covered areas, open questions and bugs.

Test automation and frameworks

How would you choose a test automation framework for a web product?

What they check: that you choose from the team's needs, not from habit, and think about who will keep the tests running.

Short answer: "I look at the product, the team's language, and what must be tested. For a modern web app I would usually try Playwright or Cypress, because they wait for the page by themselves and are quick to debug. Selenium fits when we need many browsers or the company already uses Java. I try the top choice on two or three real flows before deciding."

The full answer: A framework here means the tool plus the structure around it: how tests are organised, how they get data, how they report. My questions: Which language does the team write? Tests in the developers' language get reviewed and fixed by developers too. Which browsers and devices must we cover? Does it run in our pipeline and in parallel? How good are its reports, screenshots and traces when a test fails? Is it well supported? Then a short trial: write the same few tests, run them twenty times, and compare speed, stability and how easy the failures are to understand. I write the decision down with the reasons.

A weak answer: "Selenium, because it is the standard." Follow-up: "How do you keep the tests easy to change?" Page objects or similar (one place that knows each screen), test data built in code, no fixed waits, and test code reviewed like product code.

Your automated tests fail at random. How do you deal with flaky tests?

What they check: that you treat flaky tests as a real problem and fix causes, not symptoms.

Short answer: "A flaky test passes and fails without any change to the code, so people stop trusting the suite. I measure which tests flake, take them out of the blocking run until fixed, and fix the cause: usually waiting, shared test data, or a test that depends on another."

The full answer: First, measure: rerun the suite many times or read the pipeline history, and list the tests that change result. Then sort the causes. Timing: the test acts before the page is ready, so wait for a clear signal instead of a fixed pause. Data: two tests use the same record, so give each test its own data. Order: a test needs another to run first, so make each test set up what it needs. Environment: a slow or shared test system, so use containers or stub the outside service. Sometimes the flake is a real bug in the product, such as a race between two requests, so look before you blame the test. Track the flake rate over time and make it visible.

A weak answer: "We rerun failed tests three times automatically." That hides real bugs and teaches the team to ignore red. Follow-up: "A manager wants all flaky tests deleted." Delete only those whose risk is covered elsewhere; quarantine and fix the rest, with an owner and a date.

What do you automate, and what do you keep manual?

What they check: judgement about cost and value.

Short answer: "I automate checks that are repeated often, are stable, and protect something important: regression checks, API rules, the main user journeys. I keep human testing for new features, usability, and anything that needs judgement or changes every week."

The full answer: For each candidate I ask: how often will this run, how much does a failure here cost, how stable is the feature, and how hard is the check to write and keep? A check that runs on every change and protects payments is worth a lot. A check of a screen that is redesigned every month is not, yet. Accessibility is half and half: tools find some problems, a person with a screen reader finds the rest.

A weak answer: "We aim for one hundred percent automation." Follow-up: "How do you know your automation is worth it?" Bugs it caught before release, time saved on regression testing, and how often the team acts on its results.

How do you test a REST API?

What they check: that you test beyond the happy path, including security and data.

Short answer: "I check each endpoint against its contract: the right status codes, the fields and their types, and clear errors for bad input. Then the rules behind it, who may call it, what it changes in the data, and how it behaves under load or when a dependency fails."

The full answer: A REST API is the set of addresses a program calls to read or change data. I test: valid requests; missing, wrong or extra fields; very large inputs; calls without a login and with someone else's login (can user A read user B's order?); the same request sent twice; and what is in the database afterwards, checked with SQLAsked in 5% of test engineer ads (as of 5 Nov 2026).Check what a test left in the database, build test data, and find the record behind a bug report.. Contract tests catch a changed field name before another team's app breaks. These checks are fast, so they are the main layer of my automation, written in the team's language, for example PythonAsked in 33% of test engineer ads (as of 5 Nov 2026).Scripting test data, API checks and small tools; pytest for test suites. Readable code, reviewed like product code. or JavaAsked in 8% of test engineer ads (as of 5 Nov 2026).Common in enterprise test automation (JUnit, TestNG, Selenium, REST Assured). Clean, maintainable test code..

A weak answer: "I send requests in Postman and check they return 200." Follow-up: "The API calls a payment provider. How do you test it?" A stub (a fake that answers like the provider) for most tests, including its failures, and a few checks against the provider's test system.

Tests in the pipeline

How do you put tests into a CI/CD pipeline?

What they check: that you design for fast feedback and a clear rule for stopping a release.

Short answer: "CI means every change is built and tested automatically. I run the fast checks, unit and API, on every change, so a developer knows within minutes. Longer end-to-end tests run in parallel before merging or every night. A failed check stops the change, and the report says clearly what failed and why."

The full answer: I set stages: build, unit tests, API and contract tests, then deploy to a test environment and run the end-to-end checks for the main journeys. Each stage has a time budget, for example the first feedback within ten minutes. Tests run in parallel, in clean containers with DockerAsked in 2% of test engineer ads (as of 5 Nov 2026).Start the app and its database in containers so every test run starts from the same clean state.. Reports include screenshots and logs for failures. After a release, a few smoke tests (quick checks that the main things work) run against production. The pipeline tool may be JenkinsAsked in 6% of test engineer ads (as of 5 Nov 2026).A common CI server in older and enterprise setups: jobs, pipelines, test reports and parallel runs., GitLab CIAsked in 3% of test engineer ads (as of 5 Nov 2026).Pipelines defined next to the code: stages for unit, API and UI tests, with reports on each merge request. or GitHub ActionsAsked in 0% of test engineer ads (as of 5 Nov 2026).Workflows that run the test suite on each pull request, in parallel, with saved reports.; the design is the same.

A weak answer: "The QA team runs the regression suite before each release." Follow-up: "The pipeline is red most mornings and people ignore it." Fix or quarantine the flaky tests, make one person own a red build each day, and make failures easy to read.

How do you handle test data and test environments?

What they check: that you know most flaky tests and blocked testers come from data and environments.

Short answer: "Each test creates the data it needs and cleans up after itself, through the API where possible. Environments are built the same way every time, ideally in containers. Real customer data stays out of test systems, or is anonymised first."

The full answer: Shared test accounts that everyone changes are the classic cause of tests that fail for no reason. I build data in code, give it unique names, and reset the database between runs where I can. For systems we cannot start ourselves, I use stubs. For personal data, the GDPR (the EU data protection law) and similar laws elsewhere apply to test systems too, so production copies are anonymised or replaced with made-up data.

A weak answer: "We test on a copy of production." Follow-up: "Two teams share one test environment and break each other's tests." Separate environments per change, or at least separate data per team.

Bugs and defect management

What makes a good bug report, and how do you manage defects in a team?

What they check: clear communication, and a process that gets the right bugs fixed.

Short answer: "A good bug report lets a developer see the problem in a minute: a clear title, the steps, what happened and what should have happened, the version and environment, and evidence such as a screenshot or log. Then the team agrees how severe it is and when it gets fixed."

The full answer: A defect (another word for bug) has a life: found, reported, triaged (looked at and given a priority), fixed, checked, closed. I separate severity, how bad the effect is, from priority, how soon it must be fixed. A spelling mistake on the home page can be low severity and high priority. I keep the list short: duplicates merged, old low bugs closed with a reason. Every fixed bug that could come back gets an automated check. Patterns matter more than single bugs: if many bugs come from one part, that part needs better tests or a redesign. The tool is often JiraAsked in 18% of test engineer ads (as of 5 Nov 2026).Write clear bug reports and link them to stories and test cases; read a board to see what is at risk..

A weak answer: "I write 'checkout broken' and assign it to the developer." Follow-up: "A developer says your bug cannot be reproduced." Pair with them, compare environments and data, and add the missing detail to the report.

You find a serious bug the day before a release. What do you do?

What they check: calm judgement, and that you inform rather than decide alone.

Short answer: "I confirm it quickly, find out who and what it affects, and tell the people who decide at once, with the facts and the options: fix and retest, release without the feature, or delay. I give my recommendation, but the release decision is a team or business decision."

The full answer: Facts first: can I reproduce it, how many users meet it, is there data loss or a legal risk, is there a workaround? Then options with their risks: a small fix needs a focused retest of the area around it; turning a feature off with a feature flag (a switch in the code) can be safer than a rushed fix. Afterwards, ask why the bug was found so late and add the check that would have caught it earlier.

A weak answer: "I block the release." Or: "I log it and let them decide." Follow-up: "The manager releases anyway." Make sure the risk is written down and accepted, prepare the rollback, and watch the feature closely after release.

Test planning, metrics and leading a team

These questions come up for senior test engineers, test leads and test managers.

How do you write a test plan for a release?

What they check: that a test plan is a working agreement about scope, risk, people and time, not a long document nobody reads.

Short answer: "The test plan says what we test and what we do not, the risks and how we cover them, who does what, the environments and data, the schedule, and the rules for starting, stopping and releasing. I keep it short and agree it with the team and the business."

The full answer: The strategy is the general approach; the plan applies it to one release. I write the scope and what is out of scope, the ranked risks, which tests cover each, the entry criteria (what must be ready before testing starts) and the exit criteria (what must be true to release, such as no open critical bugs and the main journeys passing). I list the dependencies and what happens if they slip. I review the plan as the release changes, and report progress against risks, not against the number of test cases run.

A weak answer: "I fill in the company template." Follow-up: "Development is two weeks late, and the date cannot move." Re-plan by risk, agree openly what gets less testing, and offer options such as releasing the risky part behind a switch.

Which quality metrics do you track, and which do you avoid?

What they check: that you measure outcomes, and know how numbers can be gamed.

Short answer: "I track what tells us about quality for users and the speed of feedback: bugs that reach customers, how fast they are found and fixed, the share of changes that cause a problem, how long the pipeline takes, and the flaky test rate. I avoid counting test cases or bugs per tester, because people then chase the count."

The full answer: Good metrics: escaped defects (bugs found after release) and their severity; time to find and fix; the change failure rate (how often a release needs a fix or a rollback); pipeline time; the flaky rate; and coverage of the top risks, not code coverage alone. Code coverage says which lines ran during tests, not whether the tests check the right things. I show trends over months and always with context, and I use metrics to ask questions, never to rank people.

A weak answer: "Number of test cases executed and bugs found per tester." Follow-up: "Leadership wants one number for quality." Offer the escaped defects trend, explained with two or three supporting numbers.

How do you lead a test team and help testers grow?

What they check: for test lead and test manager roles, people leadership as well as testing.

Short answer: "I make sure each tester knows the priorities and why, remove what blocks them, and give them room to own an area. I have regular one-to-ones, give honest feedback, and plan each person's growth, for example a manual tester learning automation step by step."

The full answer: In practice: clear goals for the quarter linked to the product's risks; testers placed in delivery teams rather than in a separate team at the end; pairing and code reviews to spread automation skills; a learning plan per person with time set aside for it; and a say in hiring. When there is conflict with development, I bring data, not blame. A test manager also owns the budget, the tools and the hiring plan, and speaks for quality to senior management.

A weak answer: "I assign the test cases and check they are done." Follow-up: "One tester is struggling and the team is unhappy." Talk early and privately, agree clear expectations and support, follow up, and act if nothing changes.

How do you get developers to own quality too?

What they check: that you see testing as a team job and can change habits without authority.

Short answer: "I bring testing earlier: I join refinement to write acceptance criteria with the team, pair with developers on tests, make the pipeline the place where quality is visible, and celebrate bugs caught early rather than counting bugs late."

The full answer: This is often called shifting left, testing earlier in the work. Concrete steps: examples agreed before coding, unit and API tests in the definition of done, developers fixing their own red builds, and test code reviewed by both sides. Some teams practise test-driven developmentAsked in 0% of test engineer ads (as of 5 Nov 2026).Writing the test before the code. Testers who pair with developers on it shape what gets built.. The tester's job moves from finding bugs at the end to helping the team prevent them, plus exploring what automation misses.

A weak answer: "Quality is the QA team's job." Follow-up: "The developers say they have no time to write tests." Show the time lost to late bugs and reruns, start with one team and one rule, and share the result.

Your CV for these questions

Every answer above is easier when your CV already says it, because the interviewer asks about what is on it. Put one line under each job for each of these, in the words the ads use:

Then score your CV against a real job: you will see which of these the job needs and which your CV does not prove yet.