Manual QA tester interview questions and how to answer them
Remote QA tester interviews usually have a short screening call, a practical task (find and report bugs in a demo app, or write test cases for a screen) and one or two calls with the QA lead and a developer or product manager. Expect them to test how you think about what could break, not just definitions.
The questions below come up again and again. Many interviewers will hand you an everyday object or screen and say "test this", so practise thinking out loud.
Updated October 2026 by the WorkRemote careers team
On this page
About the role and your experience
Openers that check you understand the job and have done the work.
How do you decide what to test when there isn't time to test everything?
Why they ask
Real releases always run short of time. This tests your judgement.
How to answer
Talk about risk: what users do most, where money or data is involved, what changed in this release and where bugs appeared before. Say you'd tell the team what you didn't test.
Show a sample answerHide the sample answer
I'd rank by risk. Payment, login and anything that changed in this release come first, then the most-used screens, then areas with a history of bugs. I'd leave cosmetic checks on rarely used pages for last, and I'd write in the release ticket exactly what I didn't cover so the decision to ship is made knowingly.
Why manual testing, and where do you want to be in two years?
Why they ask
Interviewers know manual testing is changing. They want to hear you're realistic and learning.
How to answer
Say what you enjoy about testing, then show you're building towards API testing or automation. Don't pretend manual testing is all you'll ever need.
Show a sample answerHide the sample answer
I like finding the things nobody thought about, and I'm good at writing them up clearly. Right now I'm learning Postman for API testing and starting Playwright with TypeScript. In two years I'd like to be the person on the team who handles both exploratory testing and the automated regression suite.
Technical questions
What you know and how you'd do the work, often with a live task or test.
How would you test a login page?
Why they ask
The classic opener. It shows whether you think beyond the happy path.
How to answer
Group your ideas instead of listing randomly: valid login, invalid inputs, security and session behaviour, usability and accessibility, and different devices and browsers. Ask a clarifying question first, such as whether there's two-factor authentication.
Show a sample answerHide the sample answer
First I'd ask what login methods exist, email and password only or also Google and two-factor. Then I'd test a valid login, wrong password, unregistered email, empty fields and very long inputs. I'd check the password is masked, that the error message doesn't reveal whether the email exists, what happens after several failed attempts, and that the session ends on logout and pressing back doesn't show the account. Then I'd repeat key checks on Safari and a small Android phone, and with a screen reader.
What is the difference between severity and priority?
Why they ask
Testers use these words on every bug. Mixing them up causes arguments with developers.
How to answer
Severity is how badly the bug affects the system or user; priority is how soon it should be fixed. Give an example where they differ.
Show a sample answerHide the sample answer
Severity is impact, priority is urgency. A typo in the company name on the home page is low severity but high priority because every visitor sees it. A crash in a rarely used export screen is high severity but might be lower priority if almost nobody uses it this month.
A field accepts ages from 18 to 65. What values would you test?
Why they ask
Checks that you know boundary value analysis and equivalence partitioning, the two most used test design techniques.
How to answer
Name the partitions (below 18, 18 to 65, above 65, plus non-numbers) and the boundaries on each side.
Show a sample answerHide the sample answer
I'd test 17, 18, 65 and 66 for the boundaries, one value from the middle like 40, and then invalid inputs: empty, 0, a negative number, a decimal like 18.5, letters and a very large number. That covers each partition without testing every age.
Write a bug report for this: on the checkout page, the total doesn't update when I remove an item.
Why they ask
Bug reporting is the core output of the job. They want to see structure and precision.
How to answer
Give a specific title, numbered steps, expected and actual results, environment and evidence. Keep one action per step.
Show a sample answerHide the sample answer
Title: Cart total stays the same after removing an item on the checkout page.
Steps: 1. Open the shop and sign in. 2. Add two different products to the cart. 3. Go to checkout. 4. Remove one product with the bin icon.
Expected: the total drops by the removed product's price.
Actual: the item disappears but the total still includes its price; it corrects only after a page refresh.
Environment: latest Chrome on Windows 11, staging build 4.2.1. Screen recording attached.What's the difference between retesting and regression testing?
Why they ask
A basic concept that shows whether you understand release cycles.
How to answer
Retesting checks that a specific bug is fixed. Regression testing checks that the change didn't break anything else.
Show a sample answerHide the sample answer
If a developer fixes the cart total bug, I retest those exact steps to confirm it's fixed. Then I run regression tests on the rest of checkout, discounts, shipping and payment, because the fix touched code they share.
What's the difference between a smoke test and a sanity test?
Why they ask
These terms come up in stand-ups. Interviewers want to know you won't waste a day testing a broken build.
How to answer
A smoke test is a quick, broad check that a new build is stable enough to test. A sanity test is a narrow check of one area after a small change. Admit that teams use the words loosely.
Show a sample answerHide the sample answer
A smoke test is the first 15 minutes on a new build: can I install it, log in, reach the main screens and make one transaction? If that fails, I send it back. A sanity test is narrower, like checking only the password reset flow after a fix there. Different teams use the terms a bit differently, so I follow the team's definitions.
What is exploratory testing and how do you do it?
Why they ask
Remote teams want testers who find bugs nobody scripted. They also want to know you work with structure.
How to answer
Explain that it's simultaneous learning, test design and execution, done in time-boxed sessions with a goal, and that you take notes so others can follow what you covered.
Show a sample answerHide the sample answer
It's testing without a fixed script, where what I learn on each step decides the next. I work in sessions, say 45 minutes with a charter like "explore transfers with poor network". I note what I tried, what I found and questions for the team, so the session is useful even if I find no bugs.
How would you test an API endpoint that creates a user?
Why they ask
Testers who can check APIs are worth more. This separates click-testers from rounded QA analysts.
How to answer
Mention valid and invalid requests, status codes, response body, what's saved in the database and authentication.
Show a sample answerHide the sample answer
In Postman I'd send a valid POST and expect 201 with the new user's ID in the response. Then a missing required field, which should give 400 with a clear message, a duplicate email, and a request with no token, which should give 401. I'd check the user really exists afterwards with a GET or a SQL query, and that the password isn't returned in the response.
Behavioural questions
Past situations. Answer with a real example: what happened, what you did, what changed.
Tell me about the best bug you've found.
Why they ask
Shows curiosity and whether you understand why a bug matters to the business.
How to answer
Pick a bug with real impact. Explain how you found it, why it mattered and what happened next.
Show a sample answerHide the sample answer
On a crowdtesting cycle for a food delivery app, I noticed that if I switched my phone to flight mode just after tapping pay, the app showed the order as failed but my card was still charged. I reproduced it three times, recorded it and reported it as critical. It was accepted as a high-value bug because customers could be charged for orders that never reached the restaurant.
Tell me about a time you missed a bug that reached production.
Why they ask
Everyone misses bugs. They want honesty and what you changed afterwards.
How to answer
Pick a real example, own your part without blaming others, and describe the test you added so it can't slip through again.
Show a sample answerHide the sample answer
I once missed a layout bug that only appeared on small Android screens, because I'd only tested on my own phone. A customer reported it. I added a small-screen check to our regression suite and started using the Android emulator for the two smallest screen sizes in our analytics before every release.
Situational questions
Hypotheticals about problems you'd meet in the job.
A developer says your bug 'works on my machine' and closes it. What do you do?
Why they ask
Friction between testers and developers is normal. They want someone who resolves it with evidence, not emotion.
How to answer
Reproduce it again, check your environment and steps, add more detail (build number, device, test data, recording) and offer a quick call or screen share.
Show a sample answerHide the sample answer
I'd first retest on the latest build to make sure it isn't already fixed. If it still happens, I'd add the exact build, device, account and a screen recording, and compare our setups, because it's often a data or configuration difference. If we still disagree, I'd ask for a ten-minute screen share. The goal is to find out why it differs, not to win.
The release is tomorrow and you've found a serious bug late tonight. What do you do?
Why they ask
Tests judgement and communication when the stakes are real.
How to answer
Report it immediately with clear evidence, tell the right people in the agreed channel, explain the user impact and leave the ship decision to the product owner.
Show a sample answerHide the sample answer
I'd log it straight away with steps and a recording, mark it critical, and post in the release channel tagging the product owner and the developer on call. I'd say who is affected and whether there's a workaround. Whether we delay the release is their call, but they should make it knowing exactly what I found.
Remote work questions
How you'll work from Nigeria with a team elsewhere: hours, power, internet, communication.
How do you keep up quality when you're working alone in a different time zone from the developers?
Why they ask
Remote QA often means you test while the developers sleep. They want to know you can work without hand-holding.
How to answer
Talk about writing complete bug reports, end-of-day updates, clear test status in the tool and knowing when to escalate.
Show a sample answerHide the sample answer
I write every bug so it can be picked up without a question, because the developer may read it hours later. At the end of my day I post a short summary: what I tested, what passed, what's blocked and anything critical. Lagos is one hour ahead of London in winter and on London time in summer, so I can also overlap with UK colleagues for most of their day.
What devices and setup do you have for testing?
Why they ask
Device coverage and reliable power and internet matter for remote testers, especially on mobile projects.
How to answer
List what you have honestly: phones, OS versions, browsers, and your backup power and internet. Mention emulators and cloud device tools you can use.
Show a sample answerHide the sample answer
I have a Samsung on Android 14, an iPhone 12, and a Windows laptop with Chrome, Firefox and Edge. For older Android versions I use the Android Studio emulator. For power I have an inverter that runs the laptop and router for about six hours, and I keep a MiFi on a different network as backup internet.
Remote interview tips
Prepare for a live task. Have Chrome with DevTools, a notes app and a screen recorder ready. If they share a demo site, narrate what you're checking and why.
Bring a bug report you're proud of. Have one or two real reports (from crowdtesting or your portfolio) ready to share on screen. It answers half their questions before they ask.
Ask clarifying questions before you test. On "test this pen" or "test this login" questions, the strongest candidates ask who uses it and what matters most before listing tests.
Put both time zones in writing. Reply with "3pm BST / 3pm WAT" or "10am EST / 4pm WAT" and double-check around the UK and US clock changes in March, October and November.
Check your setup. Charge the inverter, test both internet connections and close notifications before a screen share.
Questions people ask
What questions are asked in a manual testing interview?
Mostly test design ("how would you test a login page?"), definitions like severity versus priority and regression versus retesting, a bug report exercise and situational questions about release pressure and developer disagreements. Many also include a short practical task on a demo app.
Do manual QA interviews include coding?
Usually not for a pure manual role. Expect basic SQL or API questions in some, and if the ad mentions automation, expect a coding task in JavaScript, TypeScript, Python or Java.
How long is a QA take-home test?
Usually one to three hours: find and report bugs in a demo site, or write test cases for a feature. If a task looks like more than a day of unpaid work, it's fair to ask for a shorter version.
Do I need ISTQB to pass a QA interview?
No. Interviewers care more about how you think and write. ISTQB vocabulary does help you answer definition questions cleanly, and some European employers and outsourcing firms list it in ads.
Updated October 2026 by the WorkRemote careers team
Interview questions for roles close to manual qa tester
- QA Engineer
A QA engineer makes sure software works before users find out it does not, by planning tests, finding bugs and, increasingly, writing automated tests in code with tools like Playwright, Cypress and Postman. Remote QA roles open to Nigerians exist, especially for automation engineers (often called SDETs); purely manual testing roles are fewer and pay less.
- AI Data Annotator
An AI data annotator labels images, text and audio, and rates, ranks or rewrites chatbot answers so AI models learn what a good output looks like. You can do it from Nigeria on platforms whose country list includes Nigeria, but it is gig work: projects end, queues go empty and accounts get paused, often without warning.
- Technical Support Specialist
A technical support specialist troubleshoots software, hardware or integration problems that ordinary customer support can't solve, reading logs, testing APIs and escalating real bugs to engineers. It's a strong remote option from Nigeria for people with IT or coding basics, and it pays noticeably better than general support once you can work at second-line level.
- Business Analyst
A business analyst works out what a business actually needs from a system or process change and writes it up as clear requirements that developers can build and test. It's a common remote role for Nigerians, especially those with banking, fintech or telecoms experience, though fully remote junior roles are scarce.