QA Analyst interview questions, and what a good answer sounds like
QA interviews test whether you think like a tester, not whether you've memorized definitions. Expect to be handed a login page, a vague requirement or a buggy form and asked what you'd do with it. The candidates who do well talk through their reasoning out loud and admit what they'd need to find out.
What happens in each round
- 1
Recruiter screen
What happens
Whether your background matches the posting: manual or automation, the tools you've used, the kind of product you've tested, and whether your pay expectations fit the range.
- 2
Hiring manager conversation
What happens
How you've worked inside a delivery team. They listen for how you handle a late build, a developer who pushes back on a bug, and a release you didn't think was ready.
- 3
Practical testing exercise
What happens
Your test design on the spot. You might write test cases for a feature, find bugs in a demo app, write a SQL query, or build a quick Postman request. They're watching your process as much as your answers.
- 4
Team or panel round
What happens
Whether developers, a product owner and another tester would want you on their team. Communication matters here: can you explain a bug to someone who's busy and a little defensive.
Questions you're likely to get
1.How would you test a login page?
Why they ask
It's the classic warm-up. Everyone knows what a login page does, so the only thing being tested is how organized and thorough your thinking is.
How to answer
- Ask a clarifying question first: who uses it, is there single sign-on, is there a lockout rule, is there a password reset flow
- Group your cases: valid login, invalid credentials, empty fields, boundary lengths, special characters
- Cover security basics like the password field masking, error messages that don't reveal whether the email exists, and lockout after repeated failures
- Mention non-functional checks: works across browsers and on mobile, keyboard-only use, screen reader labels
- Say which cases you'd run first if you only had a short window
2.Walk me through how you write a good bug report.
Why they ask
Developers live with your bug reports. A tester who writes vague tickets creates hours of back and forth, and managers have been burned by it.
How to answer
- A title that says what broke and where, readable in a Jira list
- Exact steps to reproduce, the environment, the build, and the test account used
- Expected result against actual result, stated plainly
- Evidence: a screenshot, a screen recording, console errors or the failing API response
- A severity you can defend, kept separate from priority, which the product owner usually owns
3.What's the difference between severity and priority? Give me an example where they don't match.
Why they ask
It's a basic concept, but the example shows whether you've actually triaged bugs with a team.
How to answer
- Severity is how badly the bug breaks the product; priority is how soon the business wants it fixed
- High severity, low priority: a crash in an admin screen almost nobody opens
- Low severity, high priority: the company name misspelled on the home page right before a launch
- Mention that you suggest severity but priority is usually agreed with the product owner in triage
4.Here's a requirement: users can upload a profile photo. What test cases would you write?
Why they ask
They want to see boundary value analysis and equivalence partitioning in action, without you naming the techniques unless it helps.
How to answer
- Ask what the requirement leaves out: allowed file types, maximum size, image dimensions, what happens to the old photo
- Cover valid types, invalid types, a renamed file with the wrong extension, and sizes just under, at and just over the limit
- Check the flow around it: cancel mid-upload, slow connection, uploading from a phone camera
- Verify where the photo shows up afterward, not just that the upload succeeded
- Point out any gaps you'd raise with the product owner before writing the final cases
5.Tell me about a bug you found that you're proud of.
Why they ask
This shows your instincts. Great testers remember the weird bug that nobody else would've caught and can explain how they found it.
How to answer
- Set the scene in a sentence: the product and the feature
- Explain what made you suspicious, which is the interesting part
- Describe how you narrowed it down and made it reproducible
- Say what the impact would have been if it shipped and what changed afterward, like a new regression test
6.A developer closes your bug as 'works on my machine.' What do you do?
Why they ask
Every QA analyst hits this. They're checking whether you stay calm and use evidence rather than escalating straight away.
How to answer
- Reproduce it again and check your own setup first: environment, build, browser, test data
- Add whatever evidence was missing, such as a recording, logs or the exact account used
- Offer to walk through it together, at their desk or on a quick call
- Only bring in the lead or product owner if you still disagree and the bug matters
7.How do you decide what to test when there isn't time to test everything?
Why they ask
There's never time to test everything. They want to hear risk-based thinking, not a promise to work late.
How to answer
- Start with what changed in this build and what it touches
- Rank by risk: money, customer data, the core flow most users take, anything that broke before
- Run a smoke test first so a broken build gets caught early
- Tell the team clearly what you didn't cover so the release decision is made with open eyes
8.Write a SQL query to find orders that don't have a matching customer.
Why they ask
Many QA roles check data behind the screen. A simple join problem shows whether your SQL is real or just a line on your résumé.
How to answer
- Use a LEFT JOIN from orders to customers and filter where the customer key IS NULL
- Or use NOT EXISTS and explain why either works
- Talk about why you'd run this: checking that a migration or a delete didn't leave orphaned records
- Mention you'd run it against a test database, not production
9.What's your experience with test automation, and what would you automate first?
Why they ask
Even analyst roles lean on automation now. They want an honest read on your level and some judgment about what's worth automating.
How to answer
- Be straight about what you've done: written Selenium or Cypress tests, maintained someone else's, or only run the suite
- Automate stable, repetitive, high-value checks first, like regression on login, search and checkout
- Leave brand-new or often-changing features manual until they settle
- Mention flaky tests and why you'd fix or remove them rather than rerun them until they pass
10.How do you test an API without a user interface?
Why they ask
Modern products break at the API layer long before the screen shows it. This checks whether you can test below the surface.
How to answer
- Use Postman or a similar tool to send requests and inspect responses
- Check status codes, the response body against the contract, and error messages for bad input
- Test auth: missing token, expired token, a user reaching another user's data
- Confirm the change actually landed in the database, not just that the API said it did
11.Tell me about a time you disagreed about whether something was ready to release.
Why they ask
QA is the last gate before customers. They need to know you'll speak up, and also that you won't block every release out of caution.
How to answer
- Describe the risk you saw in concrete terms, not a general bad feeling
- Explain how you presented it: what was tested, what wasn't, what could go wrong
- Show that the decision belonged to the product owner or release manager and you respected it
- Say what happened after and what you'd do the same or differently
12.Why QA, and not development?
Why they ask
Some candidates see QA as a waiting room for a developer job. Managers want people who actually like finding problems.
How to answer
- Talk about what you enjoy: breaking things on purpose, thinking like the user, the detective work
- Give a short example of that instinct outside of a formal testing role if you have one
- Be honest about where you want to grow, like automation or test leadership, without calling QA a stepping stone
Mistakes that sink good candidates
Reciting definitions from the ISTQB syllabus without tying them to something you've tested
Jumping into test cases for a practical exercise without asking a single clarifying question
Talking about developers as the enemy
QA works with the build team, and interviewers listen for tone.
Overstating automation skills
A panel with an automation engineer on it will find the edge of what you know within minutes.
Need more QA Analyst interviews to prep for?
HeroApply applies to QA Analyst jobs that match you, every day. 177 jobs are open today.