Interview Questions to Ask a QA Engineer
For a hiring manager, engineering lead or recruiter choosing interview questions to ask a QA engineer or software tester. The list follows the interview: background, test design, automation and tools, bug reports, working with developers around a release, and judgment about what to leave untested. The notes are written so that an interviewer who has never filed a bug can tell a practiced answer from a rehearsed one, and the guide says which part of the hour needs a developer in the room.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Background
Walk me through how testing worked on your last team, from the moment a feature was proposed to the day it shipped.
Why ask it
A strong answer puts the candidate at specific points in the story: reading the requirement, raising questions, testing the build, signing off. Notice where they first appear. Someone who only arrives once the code is finished may have tested late by habit or because the team was set up that way, so ask which.
In your last role, how did a week divide between hands-on testing, writing automation, and meetings or planning?
Why ask it
QA engineer, SDET and test analyst mean different jobs at different companies, so ask for the hours and ignore the title. Compare the split with the job you are filling. A candidate who spent most weeks on manual checks can still suit an automation role, but the practical exercise then carries more weight.
What is the difference between a test plan, a test case and a test scenario?
Why ask it
This is a vocabulary check and most candidates pass it, so the value is in the follow-up: ask for one of each from a recent project. A plan sets the scope and approach, a scenario is a situation worth checking, and a case is the steps with an expected result. Clean definitions with no example behind them point to study more than practice.
Which types of testing have you done yourself, and which do you only know by name?
Why ask it
Functional, regression, API, performance, security, accessibility, mobile: a resume often lists all of them. Asking for the split invites honesty, and the candidates you want draw the line clearly. Take one they claim and ask for the last thing it caught.
Tell me about a bug that reached customers on your watch. What had the testing missed?
Why ask it
Anyone who has tested for a few years has one. Good answers name the gap exactly, such as an untested browser, an unusual data condition or an assumption nobody checked, and say what changed afterwards. Be wary of a story where the fault lies wholly with developers or deadlines, and equally of a candidate who says it has never happened.
What is the best bug you ever found, and how did you find it?
Why ask it
People who like this work tend to light up here. What counts is how the find happened: a hunch followed up, an odd line in a log, a question about a requirement that nobody could answer. 'I ran the test case and it failed' is fine from a junior tester and thin from a senior one.
What drew you into testing, and what has kept you there?
Why ask it
Testers arrive from support desks, from development and from jobs using the kind of software they now test, and no route is better than another. What you want is a reason to stay that belongs to the work, such as liking to find out how things fail or to speak for the user. If testing is a stop on the way to a developer job, that is no fault, but ask how long they picture staying and say plainly whether your team offers that path.
How would you explain the difference between quality assurance, quality control and testing?
Why ask it
The textbook line is that assurance is the process that keeps defects from being made, control is checking the finished product for them, and testing is one way of doing that checking. Plenty of teams use all three words for one job, so do not mark anyone down for saying so. The useful part is whether the candidate counts prevention as their work: ask for one thing they changed that stopped a kind of bug from being written at all.
How do you learn a product you have never seen before well enough to test it?
Why ask it
Look for sources beyond the documentation: using the product the way a customer would, sitting with the support team, asking developers which parts of the code are fragile. Reading old bug reports is the detail that marks experience, because it shows where the product has broken before.
Test design
Here is a login form with an email field, a password field and a 'forgot password' link. What would you test?
Why ask it
Count the categories, not the cases. A strong candidate moves past right and wrong passwords into lockout after repeated failures, the reset email, what happens to the session, keyboard and screen reader use, and how much the error message gives away. The best ones question you first: who the users are, and what they land on after signing in.
A field accepts ages from 18 to 65. Which values do you try, and why those?
Why ask it
This is boundary value analysis and equivalence partitioning without the names. You want to hear 17, 18, 65 and 66, one value from the middle, then the awkward inputs: blank, a decimal, letters, a negative number, something very long. A candidate who offers twenty values from inside the range has not yet learned to choose tests.
Our product has to work in several browsers, and on phones as well as desktops. How do you decide which combinations to test?
Why ask it
Every combination is not on offer, so the answer has to be a way of cutting the grid down. Sound ones start from figures on what customers really use, run the full flow on the two or three commonest setups and a shorter pass on the rest, and keep real devices for anything involving touch, the camera or a weak signal. Ask what they do when a customer reports a fault on a browser that was left off the list.
You are handed a feature with a one-line requirement and nobody free to explain it. How do you decide what correct behavior is?
Why ask it
Thin requirements are ordinary, so this is close to a description of the job. Good answers find other references, such as how the rest of the product behaves and what support says customers expect, then write the assumptions down and get someone to confirm them. 'I would wait for proper requirements' should worry you as much as 'I would test whatever the developer built'.
How do you write a test case so that someone else could run it a year from now without asking you anything?
Why ask it
The parts to listen for are preconditions, the data needed, an expected result for each step and a title that says what is being checked. Ask how long their cases tend to run. Forty-step cases are expensive to keep current, and a candidate who has had to maintain a suite usually says so before you ask.
When do you put the script down and test by exploring, and how do you keep track of what you covered?
Why ask it
Exploring is a method with rules of its own: a time limit, a stated aim for the session and notes taken along the way, so that anything found can be reproduced. A candidate who calls it 'just clicking around' has not done it properly. If they say they never explore, ask how they find the problems nobody thought to write a case for.
A developer changes one shared component, say the date picker that appears on thirty screens. How do you decide what to retest?
Why ask it
The two weak answers are 'everything' and 'just the date picker'. A good one asks where the component appears, picks the screens where a wrong date costs most, such as billing, bookings and reports, and checks what differs between them, such as time zones and formats. Scoping a retest comes up every time shared code changes, so a hesitant answer here matters more than a missed definition.
How would you test an API endpoint that has no user interface yet?
Why ask it
Expect a tool by name, such as Postman or a scripted client, and then the checks: status codes, the shape of the response, missing and malformed fields, authentication, and how it answers a bad request. Candidates who have only tested through the screen tend to stall here. How much that matters depends on how much of your product is services.
What is the difference between smoke testing and regression testing, and when would you run each?
Why ask it
A smoke test is a quick check that a build is worth testing at all, and regression testing checks that what worked before still works. Experience shows in the second half of the question: someone who has lived with both can say how long each took and who read the results. Teams use these words loosely, so accept any sensible definition that the candidate holds to.
How do you test something that depends on time, such as a subscription renewal, a trial that expires or a report that runs at midnight?
Why ask it
Nobody can sit through a thirty-day trial to watch it expire, so the answer has to be a way of controlling the clock: dates changed in the test data, a setting that shortens the period, a hook requested from the developers. Month ends, leap days and time zones should come up without prompting. 'I would wait for it' is the answer to worry about.
What test data do you need before you start, and how do you get it?
Why ask it
Testers who have lost a day for want of a usable account plan for this early. The plan should cover creating data by script or through the API, keeping it apart from other people's tests, and caution with anything copied from real customers. Rules on using customer data in testing differ by employer and place, so ask how it was handled where they worked and check your own.
Beyond 'does it work', what do you check on a feature when nobody has asked you to?
Why ask it
The answer shows whether accessibility, speed, security and ease of use are in the corner of their eye. Nobody expects a functional tester to be a specialist in all four. Do expect them to try the keyboard alone, a slow connection and a second account with fewer permissions, and to know when to bring in someone who knows more.
Automation and tools
Which automation tools and languages have you worked in, and what did you build with each?
Why ask it
Selenium, Cypress, Playwright, Appium and the rest can be learned, so weigh what was built above which tool it was built in. Ask whether they started the suite or added tests to someone else's, and roughly how many tests it held. If your stack is different, ask how long their last change of tool took.
How do you decide whether a test is worth automating?
Why ask it
Sound reasons to automate: the check runs often, the feature is stable, doing it by hand is tedious or error-prone, a failure would be costly. Sound reasons to leave it manual: the feature is still changing, it needs a human eye, it runs once a year. 'Automate everything' is a warning, and so is having no rule at all.
Where should most automated checks live: at the unit level, the API level or the user interface? Why?
Why ask it
This is the test pyramid. The usual argument is for pushing checks downward, because tests that drive the interface are the slowest to run and the first to break when a screen changes. A reasoned disagreement is a fine answer. Never having thought about it is the weak one.
A test passes on your machine and fails one run in ten in the pipeline. How do you track it down?
Why ask it
Flaky tests are where automation skill shows most plainly. A capable candidate names suspects in order: timing and waits, shared test data, the order tests run in, the environment. Then ask what happens to the test in the meantime. Setting it aside with a ticket is sound, while adding a retry and moving on hides real bugs along with the false alarms.
How do you structure a suite so that one change to a screen does not break fifty tests?
Why ask it
Page objects, shared helpers, stable test ids agreed with the developers, and data set up through the API instead of the screen are the usual answers. The pattern names matter less than signs that they have paid the maintenance bill once and now design to avoid it. Ask what the worst suite they ever inherited looked like.
Where did your automated tests run, and what happened when one failed?
Why ask it
You are finding out whether their tests were part of the pipeline or something run from a laptop before a release. Wait for a trigger, such as every merge or every night, then for who was told about a failure and whether it blocked anything. A suite nobody acts on is decoration, and a candidate who has owned one will say so.
Tell me about automation you deleted or decided not to write.
Why ask it
Removing tests takes confidence. Good stories involve tests that duplicated cheaper ones, checked something that had stopped mattering, or cost more to keep passing than they ever caught. A candidate with no such story has probably not owned a suite for long.
Have you used an AI assistant to produce test cases or test code? What did you have to fix in what it gave you?
Why ask it
Yes and no are both acceptable. If yes, the second half is the useful part: generated tests that assert nothing meaningful, selectors that do not exist, cases that only restate the requirement. If no, ask why not. Check your own company's rules on these tools before you count the answer for or against anyone.
How comfortable are you with SQL, and when did you last use it to check a result?
Why ask it
Plenty of bugs sit in the data and never show on a screen. A tester who can query the database confirms that the order was really saved, not only that the page said so. If the role needs it, sketch two tables and ask for the query on the spot. If it does not, simple selects and joins are enough.
Bug reports
What goes into a bug report you would be happy to put your name on?
Why ask it
The core is a title that states the problem, numbered steps, expected and actual results, the build and environment, and evidence such as a screenshot or a log. Better candidates add how often it happens and what they have already ruled out. Ask them to write one during the interview, because the writing is the skill.
What states did a bug pass through on your last team between being logged and being closed, and who moved it at each step?
Why ask it
This is the bug life cycle, and the textbook chain of new, assigned, fixed, retested and closed is the easy half. The second half shows how the team really ran: who triaged, whether the tester or the developer closed the ticket, and where deferred and rejected bugs ended up. A candidate who has only ever dragged their own tickets to 'done' has probably not sat in a triage meeting, which is fine for a junior role and a gap for a senior one.
What is the difference between severity and priority? Give me a bug that is high on one and low on the other.
Why ask it
Severity is how much damage the bug does, and priority is how soon it should be fixed. The example is the real test. A crash on a screen almost nobody opens is severe but can wait, and a misspelled company name on the home page is trivial but urgent. A candidate who cannot produce an example has memorized the definitions.
A developer closes your bug as 'cannot reproduce'. What do you do next?
Why ask it
The patient answer wins: make it happen again, narrow down the conditions, compare environments, data and accounts, capture a recording or logs, then sit down with the developer and show it. Reopening the ticket with 'still happens' and nothing new is the habit that sours the relationship.
A developer says your bug is working as designed, and you think the design is wrong. How do you argue it?
Why ask it
The case should come from the user's side, with evidence: what a customer would expect, a complaint that reached support, how the rest of the product behaves. After that comes knowing who decides, often a product owner, and accepting the decision once it is made. Winning by persistence and giving way at once are both poor signs.
You see a failure once and cannot make it happen again. Do you report it?
Why ask it
Yes is the answer to hope for, with the report marked clearly as intermittent and carrying everything they can recall about the moment: the time, the account, what else was running, and what they tried in order to bring it back. A failure that goes unrecorded because it could not be shown twice tends to turn up again in front of a customer.
You find twelve problems in one afternoon on the same feature. How do you report them?
Why ask it
This one tests organization and tact together. One ticket for each distinct problem, linked to the others, with the serious ones flagged first, is the usual sound answer. Many candidates add that they would speak to the developer before filing: a dozen tickets arriving unannounced reads as an attack, and a short conversation often turns up one cause behind several of them.
Before you file a bug, what do you rule out first?
Why ask it
A stale build, the wrong environment, an expired test account, cached data, an issue already in the tracker. Checking these protects a tester's credibility, and credibility is what gets the next report looked at quickly. A very long checklist is its own warning, since a serious bug should be reported fast and refined afterwards.
What do you do with a bug you reported that has sat untouched for three months?
Why ask it
A workable plan is to check whether it still happens, add fresh evidence or a customer's experience of it, raise it at triage, and close it if it has stopped mattering. Pay attention to the tone as well as the plan. Old tickets are a fact of the work, and resentment about them tends to travel with the person.
How do you verify a fix once the developer says it is done?
Why ask it
Running the original steps again is the minimum. Stronger candidates test around the fix too: the neighboring cases, the other platforms, whatever the change might have disturbed. Ask whether they read the code change itself. Not every tester does, and those who do often find the second bug that the fix introduced.
Team and releases
It is the day before a release and you have time for a third of your planned testing. What do you run?
Why ask it
A good answer ranks the work by what changed, what would hurt customers or revenue most if it broke, and what has broken before, then ends with telling the team plainly what was left uncovered. 'I would stay late and do all of it' sounds dedicated and avoids the question, so put it again with the extra hours taken away.
You find a serious bug two hours before a release that leadership has promised to a customer. What do you do?
Why ask it
The candidate you want brings facts to the people who decide: what the bug does, who it affects, how likely it is, whether there is a workaround. 'I would block the release' assumes an authority that testers hold at some companies and not at others, so ask who held it where they worked. 'It is not my call', with nothing after it, undersells the tester's duty.
Tell me about a time you were overruled and something shipped that you had argued against. What happened?
Why ask it
The story shows temperament. Good signs are a risk stated in writing beforehand, help with watching for the problem after release, and a telling that does not score points. Ask whether the bug did appear. A candidate who can say 'it turned out fine and I had overestimated it' has judgment you can calibrate against.
How do you get involved in a feature before any code is written?
Why ask it
Testers who only see finished builds find problems at the most expensive moment. The habits to hear about are reading requirements and designs, asking 'what happens if' during planning, and agreeing acceptance criteria with the developer. Then ask for one problem they caught at that stage, since a single real example outweighs any amount of talk about shifting left.
What testing do you expect a developer to have done before a build reaches you, and what do you do when it has not been done?
Why ask it
Unit tests and a check that the main path works are a reasonable expectation. The second half matters more. Sending the build back with a clear reason is fair, and raising a pattern with the whole team is better than complaining about one person. Contempt for developers rarely stays hidden in an answer to this, so listen for it.
How do you report where testing stands to someone who does not want the detail?
Why ask it
A product manager or director wants three things: what has been checked, what has not, and what worries you. Candidates who answer with counts of test cases passed are reporting activity. Ask for a status on their last release in under a minute and you will hear which kind you have.
How do you build trust with developers who see QA as the people who slow them down?
Why ask it
Practical answers beat attitudes: quick feedback on small pieces of work, bug reports that save the developer time, testing on a branch before it merges, saying so when something is built well. A candidate who describes developers as the other side will rebuild that divide wherever they go.
Once a release is live, is your job done? What do you watch?
Why ask it
No is the answer you want, followed by what they watch: a quick pass over the main paths in production where that is allowed, the error logs and monitoring, and the first support tickets. If testers had no production access at their last company, that is a fact about the company, so ask what they would have wanted to see.
Judgment
What would you deliberately not test, and how do you defend that?
Why ask it
Nobody can test everything, and the candidates worth hiring say so without embarrassment. Expect reasons tied to risk: code that did not change, a third-party service with its own testing, a rarely visited path where failure is cheap. The defense should include writing the decision down where the team can see it.
How do you know when you have tested enough?
Why ask it
There is no formula, and a candidate who offers one, such as a coverage percentage, is giving you a number in place of a judgment. Stronger answers combine several things: the risky areas covered, new bugs arriving more slowly, the agreed exit criteria met, and the time available. Ask what they do when bugs are still turning up and the time has run out.
Should a team aim for zero bugs reaching customers?
Why ask it
It is a popular slogan, and a thoughtful tester takes it apart politely: the last sliver of certainty gets expensive, and a team chasing it slows to a crawl. The better answers sort bugs into those that must never get out, such as lost data, a wrong charge or a security hole, and those that can be fixed quickly once seen. Someone who simply agrees to please you may agree with every deadline as well.
Which quality numbers do you trust, and which have you seen gamed?
Why ask it
Bugs filed per tester, test cases written and pass rates are all easy to inflate, and candidates with some years behind them usually have a story about it. What they would put in their place tells you more: bugs that reached customers, the time from finding a bug to fixing it, how long the team waits for test results. Skip this one for someone applying for a first job.
Who is responsible for quality on a team?
Why ask it
The expected answer is 'everyone', so push past it and ask which part falls to the tester because nobody else will do it. Good replies talk about making risk visible, asking the questions others skip and speaking for the user. A candidate who answers 'QA is' may struggle on a team where developers write tests as well.
You join a team with no test cases, no automation and a release every two weeks. What do you do in your first month?
Why ask it
Use this for a senior candidate or a first QA hire. Sound plans begin with finding out where the product hurts, from support tickets and past incidents, then a short checklist for the riskiest paths, and only after that automation. Choosing a framework before knowing the product is the classic mistake.
If we gave you thirty minutes with our product right now, where would you start, and why there?
Why ask it
Better done for real on a test account than talked through. Watch where they go first: sign-up, payment, anything that takes input or changes what is stored. The reasoning matters more than any bug they find. If you run it live, tell candidates beforehand and keep it short.
How to interview a QA engineer
Practical guidance for the conversation itself
Before the interview
Manual tester, automation engineer or first QA hire
These are three different hires that often share one title. Write down the rough split of the work in an ordinary week before you choose questions. For a mostly manual role, lean on Test design and Bug reports. For an automation role, Automation and tools should take a third of the hour. For a first or lead hire, spend the most time on Team and releases and on Judgment.
Plan the hour around what you can watch
A test design problem and a bug report written on the spot each take about ten minutes when the candidate is allowed to ask about the feature first. That leaves room for eight to ten of the other questions: one or two from Background, most from the two groups the role depends on, and one from Judgment whatever the level. Each group opens with the familiar question a candidate is likely to have rehearsed, and the later ones are harder to prepare for.
Bring something to test
Testing questions get better answers when there is an object on the table: a screen from your own product, a sign-up form, a deliberately poor bug report to improve. Pick it beforehand and decide what a good response would include, so every candidate is measured against the same thing.
Borrow a developer for the automation part
A recruiter or a manager from outside engineering can judge most of this page from the notes. Automation and tools is the exception, since a confident candidate can name frameworks all afternoon. Ask a developer or a current tester to sit in for that group, or to read a short code sample from the candidate afterwards.
In the room
Let them question you first
On a test design problem, a good tester asks who uses the feature, what it connects to and what has gone wrong before. That is the job being done in front of you, not stalling. Answer briefly and note what they asked, because the questions are often more telling than the list of tests that follows.
Follow one bug all the way through
Early on, pick a bug from one of the candidate's stories and keep coming back to it: what the report was titled, what the developer said, whether it was fixed before the release, how the fix was checked. One bug followed from discovery to release answers half of Bug reports and a good part of Team and releases. A candidate who lived it remembers the build it appeared in and the argument at triage.
Make 'I have not done that' a safe answer
Say early on that nobody has done every kind of testing and that you would sooner hear where the edges are. A tester's value rests on reporting what is true, including about themselves. A candidate who bluffs about performance testing in an interview is showing you how a status report might read on a bad week.
Keep the practical exercise small and announced
Twenty to thirty minutes on a test account, with a short written bug report at the end, shows more than a long take-home task. Tell candidates in advance so nobody is ambushed, never use live customer data, and check your own company's hiring policy before setting any work to be done outside the interview.
Reading the answers
Listen for ranking, not volume
A long list of tests can sound impressive and still miss the point. The stronger candidate says which three checks they would run first and why, and what they would leave for last. Ordering by risk is the skill that carries over to a week with too little time, which is most weeks.
Notice how they talk about developers
Across the bug and release questions, keep an ear on the pronouns. 'We found' and 'we decided' suggest someone who works inside a team. A steady 'they broke it, I caught it' suggests someone who works against one. Both can find bugs, but only one gets those bugs fixed quickly.
Adjust for level
From a junior tester, look for curiosity, careful observation, clear writing and a working vocabulary. From a mid-level one, add sound test design and some automation that ran in a pipeline. From a senior one, expect scoping under pressure, an account of a suite kept healthy over time, and an argument lost gracefully.
Five answers to ask about again
'I would test everything.' A career with no bug that got through. Tool names with nothing built in them. A coverage figure offered where a judgment was asked for. Blame that always lands on the developers or the deadline. Any tester can give one of these on a nervous day, so put the question again in different words before you hold it against them. Hearing three of them in one hour is another matter.
After the interview
Read what they wrote
Most of a tester's output is written: bug reports, test cases, a status note before a release. Read the report from the exercise as a developer would on a busy afternoon. Could you reproduce the problem from it alone, and does the title tell you what is wrong?
Have the developer and the manager score separately
If a developer sat in, each of you should write down a view on every group of questions before the debrief. Developers tend to weigh the automation answers and the quality of the bug report, managers the judgment and the manner, and whoever speaks first usually sets the tone for the rest. Two sets of notes keep both views in the room.
Ask a developer who worked with them
If you take references, a former manager can tell you about reliability. A developer who received the candidate's bug reports can tell you whether they were clear, fair and usually right. Ask about one disagreement and how it ended. How references are requested and what a past employer will say differ from company to company, so follow your own process.
Tell them what the job really is
Before an offer, give the honest split of manual and automated work, how often you release, and who decides when something ships with a known bug. A candidate hired to build automation who spends the year on manual regression will not stay, and one honest conversation costs less than a second search.