Questions to Ask in a QA Interview
For a QA tester, QA engineer or test automation engineer deciding what to ask the interviewer at the end of a QA interview. The questions run in six groups, in the order the conversation tends to go: the role and the team around it, how testing fits into the release process, automation and tools, bugs and who can stop a release, growth, and the close. Under every question is a note saying what a good or a worrying answer sounds like, and often what to ask next.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Role
How much of this role is manual testing, and how much is writing automated tests?
Why ask it
Job titles in QA rarely settle this, so ask for the split in an ordinary week last month and not the plan for next year. If the posting said automation and the answer is manual regression with scripting 'when there is time', the job is manual. That suits some testers well, and it is better learned now than in month three.
How many testers are on the team, and how many developers does each one support?
Why ask it
No ratio is right everywhere, so listen for how the work is shared instead of judging the number. One tester to ten developers can work where developers write and run most of the checks themselves. Where they do not, that tester spends each sprint choosing what goes unchecked, and you should ask who makes that choice with them.
At what point does QA first see a new feature: while it is being planned, or when the build is ready to test?
Why ask it
A tester who is in the room when requirements are written can raise the awkward cases while they cost nothing to fix. One who first meets the feature as a finished build finds the same problems with no time left. Ask about the most recent feature, because teams tend to describe earlier involvement than they practice.
What does a typical week look like for a tester on this team?
Why ask it
Notice where the testing falls in the week or the sprint. Steady testing as each story is finished means work is handed over in small pieces. A quiet start followed by everything landing in the last two days means the end of every sprint is a squeeze, and the tester is the one squeezed.
What would you want me to have done by the end of my first 90 days?
Why ask it
A manager with a plan answers in testing terms: the regression run for one product area in your hands, a first batch of automated checks merged, a test plan written for a named feature. 'Getting to know the product' is a start, not a goal. Follow up by asking which area you would be trusted to sign off first.
Is QA its own team with its own manager, or does each tester sit inside a development team?
Why ask it
Embedded testers hear about changes early, but can be the only voice for quality in a team run by its developers. A central QA team gives you peers and a manager who knows testing, at the cost of work arriving over a wall. Either way, find out who would write your review, since their idea of good testing is the one you would be held to.
Would I be the only tester on my team, and who would look over my test plans?
Why ask it
Working alone means nobody catches the case you did not think of, and nobody covers the release when you are out. Some teams solve it with a tester from a neighboring team or a developer who reviews plans. If the honest answer is nobody, weigh that against how much experience you already have, because there would be no one to learn from either.
Is this a new position, or am I replacing a tester who left?
Why ask it
A replacement inherits test cases, habits and expectations, so ask how long the last person stayed and who has covered the work since. A first QA hire has a different job: deciding what testing looks like here. In that case ask what happened that made the company want a tester now.
What is the biggest challenge facing the QA team right now?
Why ask it
Sort the answer into two kinds. A slow suite, thin coverage or too few hands are problems inside QA, and solving them would be the job. Late handovers, requirements that change mid-build or no room in the plan for testing come from outside it, so ask who above the team wants that changed.
How does a new tester learn the product here: documentation, shadowing someone, or working through the old test cases?
Why ask it
A tester who does not yet know the product can only check what the script says, so how that knowledge is passed on matters more than the tool training. Someone to shadow and a first area small enough to learn properly is a plan. Being handed the regression suite in week one teaches the steps without the reasons.
How would the developers here describe QA?
Why ask it
Put it to a developer if one is on the panel. The answer to hope for is a story in which a tester's question changed how something was built. A joke about QA being the people who say no is an answer too, and it tells you how your bug reports would be received.
What is the hardest part of this product to test?
Why ask it
Payments, third-party integrations, anything that depends on timing, reports built on years of data: most products have a part like this. An interviewer who names it at once knows where the risk sits, and has probably just described your first few months. If they need a while to think, ask what broke most recently.
Release process
Could you walk me through how a change gets from a developer's branch to production, and where testing happens along the way?
Why ask it
Count the stops as they describe them: code review, automated checks, a test environment, a sign-off, a gradual rollout. Any stop that depends on one person is where work waits. If that person would be you, ask how many changes arrive in a normal week.
How often do you release, and how long is the testing window before each one?
Why ask it
The cadence sets the shape of the job. Releases several times a day rely on automated checks and small changes, while a monthly release usually ends in a regression cycle. Find out whether the window is a fixed number of days or simply whatever is left when development finishes.
Do releases go out during working hours, and are testers expected to be around for them in the evening or on weekends?
Why ask it
Some teams deploy midweek in the morning so that everyone is at a desk if it goes wrong. Others release late at night to stay out of customers' way, with a tester checking the result afterwards. Ask how often that turn comes round and whether the time is given back, since both differ from one employer to another.
What is the team's definition of done, and does it include testing?
Why ask it
The answer you want includes tested, and says by whom and in which environment. Where done means the code is merged and testing comes afterwards, bugs surface once the developer has moved on, and every fix competes with new work.
When work is estimated, does the estimate include the time to test it, and does a tester have a say?
Why ask it
An estimate that covers only development treats testing as free, and free things get squeezed. In a healthy setup a tester helps size the work, or it is not planned until QA has seen it. A good follow-up is what became of the last piece of work that took longer to test than to build.
How are requirements written down, and what do I test against when they are thin?
Why ask it
Acceptance criteria on a ticket give you something to hold the build up to. If the fallback is to ask the developer what it should do, you end up checking the code against its author's own understanding. Some interviewers will pull up a real ticket if you ask, and reading one shows at once how much a tester here is given to go on.
What testing do developers do before they hand work over?
Why ask it
Unit tests and a run through their own feature mean the builds you receive mostly work, which leaves your time for the difficult cases. Builds that fall over on the first click turn a tester into a developer's spell checker. How often a build gets sent straight back is the number to ask for.
How long does a full regression pass take, and how often is it run?
Why ask it
Minutes suggests it is automated and runs on every change. Several days by hand before each release tells you what a large share of this job is. When time runs short someone picks which parts to skip, so ask who that is and how they choose.
Is there room for exploratory testing, or is the work mostly running scripted test cases?
Why ask it
Scripted cases confirm what someone expected. Exploring finds what nobody thought to write down, and a team that sets aside sessions for it is trusting its testers' judgment. If the work is all steps to execute, ask who writes the cases and whether a tester may change them.
Who tests performance, security and accessibility, and at what stage?
Why ask it
These often belong to nobody until something goes wrong. A specialist team, an outside firm or a scheduled pass before major releases are all sound answers. If QA is expected to fit them in around everything else, the responsibility comes without the hours, so ask whether training and tools come with it.
After a release goes out, does anyone test it in production, and how would the team know if something was wrong?
Why ask it
A short smoke test on the live system, dashboards, error tracking and a way to switch a feature off mean the team keeps checking once the code is out. If the first signal is a customer complaint, everything rests on what was caught beforehand. Ask whether testers can open the production logs and dashboards themselves or have to request them.
What happens when the release date arrives and testing is not finished?
Why ask it
Every team has faced this, so ask about the last time and not the policy. A good account has someone weighing the untested areas, deciding on purpose and writing the risk down. In a worrying one the tester was asked to sign off anyway, or the weekend quietly became part of the schedule.
Automation and tools
What is automated today, and what is still checked by hand?
Why ask it
Ask layer by layer: unit tests, API tests, tests through the interface. Plenty of teams have solid unit tests from developers and a thin, slow suite at the top, and the gap between the two is likely to be your first project. If the answer is an ambition to automate everything, ask what was added last quarter.
Which framework and language are the automated tests written in, and who chose them?
Why ask it
If the framework is one you have not used, say so and ask how quickly other newcomers were writing useful tests in it. Do not drop the part about who chose it. A framework picked by someone who has since left can be a thing nobody understands well enough to change, and it tends to land with the newest tester.
Who writes and maintains the automated tests: testers, developers, or a separate automation group?
Why ask it
Where developers and testers share one suite, a test tends to get fixed in the same change that broke it. A separate group can fall a release or two behind the product. If you are a manual tester hoping to learn automation, this is also the moment to ask whether you would be allowed to contribute.
How often do the automated tests fail for reasons that are not real bugs?
Why ask it
How a team treats its flaky tests says more about the suite than its size does. A team that sets them aside and repairs them has tests people believe. Where the habit is to rerun until the build goes green, a red result has stopped meaning anything, and a real failure can hide among the false ones.
Do the automated tests run on every change, and can a failing one block a merge?
Why ask it
Tests that run in the pipeline and can block a merge are part of how the team ships. Tests run overnight, or from one person's laptop, produce a report that may or may not be read. The length of the run is worth asking about as well, because a slow suite tempts people to go around it.
What test environments are there, and how closely do they match production?
Why ask it
Listen for the differences: less data, integrations stubbed out, other settings. Each one is a kind of bug that cannot be found before release. Then ask how many teams share the environment, since on a shared one your results can be thrown off by another team's deployment.
Which platforms, browsers and devices would I be testing on?
Why ask it
Web, mobile, an API and hardware each call for different skills, so get the list and the supported versions. Then ask how the team covers them: a shelf of real devices, a cloud device service, emulators, or whatever phones people own. The last answer tells you how seriously the support list is taken.
Where does test data come from, and how is it reset between runs?
Why ask it
Data created by a script makes a result repeatable. Copies of production data raise the matter of how customer details are masked, and the rules for that depend on the company and its industry, so ask how it is handled there. Accounts set up by hand that one person knows about are a sign that tests cannot easily be run twice.
How do you track test cases and results: a test management tool, the ticket system, or spreadsheets?
Why ask it
The tool matters less than whether anyone reads what is in it. Find out who looks at the results before a release and what they do about a failed case. Ask when the library was last pruned, too: thousands of cases nobody has reread in years cost a lot to run and prove little.
When a test environment is down or a build is broken, who fixes it, and how long does it usually take?
Why ask it
Blocked time is the hidden cost of a testing job. A platform team that responds within hours keeps it small. If testers have to chase a developer for a favor, whole days go, and the test window before the release rarely stretches to make up for them.
Is the team using AI tools to write or maintain tests, and who checks what they produce?
Why ask it
A generated test can pass while checking nothing at all, so the reassuring answer is that it gets reviewed like any other code. Ask too whether there is a rule about pasting product code or customer data into such tools. Policies differ from one employer to the next, and some have none yet.
Bugs
How are bugs triaged, and who decides which ones get fixed before a release?
Why ask it
You are listening for a named meeting or person and some agreed meaning for severity. Without them, each bug is argued from scratch and the loudest voice wins. Ask how many bugs are open now and how old the oldest is: a backlog nobody reads is where reports go to be forgotten.
Who can stop a release, and when did that last happen?
Why ask it
A date and a story mean the authority is real. A sign-off that has never once held anything back may be a ceremony. And if QA alone is the gate, ask whether the blame lands there too when something gets through, because being the only gate and being the one blamed tend to go together.
When a serious bug reaches customers, what happens afterwards?
Why ask it
A healthy account is a review that traces how the bug passed each stage and ends in a new test or a changed step. The worrying one starts and finishes with 'why did QA not catch this?' Ask for the latest example and listen for whose names come up.
What makes a good bug report here, and what happens to one a developer cannot reproduce?
Why ask it
The first half gives you the house standard: steps, environment, logs, a recording. The second shows the working relationship. A developer who asks to watch it happen is a colleague, and a ticket closed with 'works on my machine' is a pattern you would meet every week.
When a tester and a developer disagree about whether something is a bug, how is it settled?
Why ask it
'Working as designed' disputes are routine, so the question is who referees. A product owner with the requirement in hand is a fair one. If the developer's view stands by default, find out what the tester did the last time they were sure they were right.
How quickly do bugs found in testing get fixed, and what becomes of the ones that are put off?
Why ask it
A bug fixed while the code is fresh in the developer's mind is cheap. One that is deferred joins the backlog, where it has to compete with features for attention. Some teams reserve part of each sprint for fixes, so ask whether this one does and whether that time survives a busy month.
Which kinds of bug get through to production most often?
Why ask it
A team that keeps track of escaped bugs can name a pattern: one integration, one device, anything involving a data migration. That pattern is where they most need you. If escapes are counted against individual testers instead of studied by the team, think about what that would do to how you report.
When support passes on a problem from a customer, who tries to reproduce it: support, QA or a developer?
Why ask it
On some teams this is a steady stream that reaches testers unplanned and comes out of the time meant for the release. A rotation, or a set share of the week for it, means someone has counted the cost. Ask how many such reports came in last month, and how a tester gets at the customer's setup or data to reproduce one.
How is quality measured here, and which of those numbers is QA judged on?
Why ask it
Team numbers come first: bugs that reach customers, time from report to fix, how long a release takes to verify. A coverage percentage alone shows how much code the tests ran, not whether they checked the right things. Ask which number QA alone answers for, and what was done the last time one moved the wrong way.
Growth
Where have testers on this team gone next: senior QA, automation, test lead, or into development or product?
Why ask it
You want real examples: the tester who now leads the team, the one who moved across to automation or product. If every example left the company to move up, the ladder may end at this role. Mention the direction that interests you and watch whether the manager picks it up or changes the subject.
Are there defined levels for QA here, and what does the level above this one do differently?
Why ask it
A ladder written for testers, and not borrowed from the developers with a few words swapped, shows that someone has thought about the craft. If the next level is described only as more automation, ask where a strong exploratory tester goes. Titles and levels differ between employers, so have them describe it instead of assuming.
If I wanted to move from manual testing toward automation, how would that work here?
Why ask it
A workable answer has time set aside inside the sprint, someone to review your first scripts, and ideally a tester who has already made the move. 'In your own time' means the manual workload stays full and the change depends on your evenings. Skip this one if the role is already an automation role.
Does the company pay for testing courses, certifications or conferences, and has anyone used that this year?
Why ask it
Employers differ on how much weight they give a certificate such as ISTQB, so ask whether it counts for anything at review or promotion there. The second half separates a real benefit from a line in the handbook. A manager who can name the course and the person has seen it happen.
How is a tester's performance reviewed, and what does a strong year look like?
Why ask it
Listen for whether the measure is bugs found, which penalizes the tester who prevents them by asking good questions early. A better answer talks about judgment: risks raised in time, releases that went quietly, a suite kept in good order. It also helps to know whether the developers you work with have a say.
What is your own background: testing, development, or something else?
Why ask it
Put it to whoever would manage you. A former tester usually knows what good exploratory work looks like, while a manager who came from development may judge mostly by the automation, which they can read. Either can be a good boss, so ask how they tell a strong tester from an average one and you will hear what your review would rest on.
Closing
Where do you want testing on this team to be a year from now?
Why ask it
Listen for a named gap: API coverage, earlier involvement, fewer checks done by hand on release day. That gap is the job as the manager sees it. If the answer is the same as today but faster, ask which problem they would hand to a new tester first.
Could I see a recent test plan or a couple of bug reports from the team before I decide?
Why ask it
Not every company will share them, and some will only show them on screen in a later round. Where they do, look at how much detail a report carries and how the developer replied. Those two things show the standard expected of a tester and the tone of the daily back and forth.
Is there anything in my background that makes you doubt I could do this job?
Why ask it
In testing interviews the reservation tends to be specific: not enough coding for an automation role, or a product area you have not worked in. Asking brings it out while you can still answer it. Give one concrete example, such as a script you wrote or a domain you learned quickly, and leave it there.
What are the next steps, and is there a practical test or take-home exercise still to come?
Why ask it
QA processes often include one: finding the problems in a sample app, writing test cases for a feature, or a short coding task. Ask how long it is meant to take and what they will look at, so you spend the time on the right thing. Ask too when they expect to decide.
How to use your questions in a QA interview
Practical guidance for the conversation itself
Before the interview
Use the product first
If the company has an app or a site you can reach, spend twenty minutes with it the way you would on a first day: sign up, change a setting, try the path a hurried user would take. Note two or three things you would want to test early. Do not open the interview with a list of bugs. Turn one into a question instead, such as how a problem like it would be reported and who would decide whether to fix it.
Read the posting for the split
Postings give the mix away in their nouns. Test cases, regression cycles and sign-off point to manual work. A named framework, a programming language and the word pipeline point to automation. Form a guess, then use the first question on this page to check it, because a posting is often reused from the last time the role was filled.
Start with the three that decide it
There is rarely time for more than a handful. For most testers three answers decide the job: the real split of manual and automated work, the point at which QA first sees a feature, and whether anyone has ever held a release. Ask those first, in whichever round you meet someone who runs the tests, and give whatever time is left to the group that matters most to you.
Decide which job you want
A tester who loves exploratory work, one who wants to write automation all day and one who wants to lead a team are looking for three different answers to the same questions. Settle beforehand which answers would rule the job out for you and write them down, because a good conversation can make almost any setup sound workable.
Who to ask what
The QA lead or manager
This is the person for Role, Bugs and Growth: why the job exists, who can stop a release, how a tester is reviewed and where testers have gone next. If the manager is not a tester by background, ask the Growth questions with extra care, since they will be judging work they have not done themselves.
A tester on the team
A future peer knows the week as it is lived. Ask them about flaky tests, how often the environment is down, whether release nights fall to them, and what happened the last time the date arrived before testing was finished. Their answers are the ones to compare against the manager's.
A developer
A developer on the panel is a chance to hear the other side of the handover. Ask what they test before passing work on, how they would describe QA, and what they do with a bug report they cannot reproduce. Notice whether they talk about testers as people they work with or as a stage their code passes through.
The recruiter
A recruiter can usually tell you the size of the team, why the role is open, whether a practical exercise is coming and when a decision is due. They are unlikely to know the framework or the regression time, so save those for someone who runs the tests.
Reading the answers
Ask about the last release
Most testing questions can be answered with the process as written. Adding 'what happened on the last release?' moves the answer from the wiki to the week. It works for the testing window, for triage, for who signed off and for what got skipped.
Listen for who owns quality
Notice the grammar. 'We missed it' and 'QA missed it' describe two different places to work. In the first, testing is one of several checks and a tester's concerns are part of the plan. In the second, the tester is the last line and the first to be asked what went wrong.
Check one answer twice
Put the same question, such as when QA first sees a feature, to two interviewers. Matching answers mean the process is real. If the manager says planning and the tester says the day before release, believe the tester, and think about why the manager does not know.
When the setup is thin
Little automation, no test environment worth the name and a spreadsheet of cases can be a warning or a chance to build something. The difference is whether someone with authority wants it fixed and will give time and money for it. Ask what has been tried already and why it stalled before you decide which you are looking at.
Mistakes to avoid
Sounding like an audit
A run of questions about coverage, flaky tests and escaped bugs can feel like an inspection. Ask out of curiosity, respond to what you hear, and say when something sounds good. You are finding out whether you would like the work, not grading it.
Asking only about tools
Frameworks are the easy subject and the least telling. A team can run a fashionable stack and still test everything in the last two days. Spend at least one of your questions on the release process or on bugs, where the working conditions show.
Talking down manual testing
Candidates who want automation sometimes speak as though manual and exploratory work were beneath them. The person across the table may do that work, and most automation roles include some of it. Say what you want to do more of without dismissing the rest.
Leaving without the release question
Whether QA can hold a release, and whether it ever has, says more about the standing of testers than any description of the culture. If you only have time for one question from Bugs, make it that one.