Manual Testing Interview Questions for Freshers (2026): The Role Most Students Dismiss and Then Get
Updated August 2026
A substantial share of fresher intake at service companies goes into testing, and many students are allocated there regardless of which stream they prepared for. The pattern that follows is predictable: a student who spent months on data structures is offered a QA role, has never prepared a single testing answer, and walks into the round unable to define a test case. Whatever you think of the role, being unprepared for it is an expensive way to find out you were allocated to it.
So here is the honest framing before the questions. Manual testing is not a lesser version of development and it is not a dead end, but it is also not automatically a route into one. Testers who progress deliberately — into automation, into SDET roles, into performance or security testing, into business analysis or domain expertise — do so because they drove it, usually by learning a scripting language and an automation tool in their first two years while doing the manual work well. Testers who wait to be moved often are not. That is worth knowing at the offer stage rather than at the two-year mark, and it is a reason to take the role seriously rather than to refuse it.
What the interview actually tests is narrower than the syllabus suggests. Definitions matter — severity versus priority, smoke versus sanity, the bug life cycle — and you should know them crisply. But the questions that decide the outcome are practical: given a login page, a lift, or a pen, can you generate sensible test cases out loud without freezing? A fresher who can think aloud about what might break, and who writes one clear reproducible bug report, interviews better than one who has memorised the STLC phases and cannot apply any of them.
Frequently asked questions
What is manual testing, and why is it still needed when automation exists?
Manual testing is executing test cases by hand, without a script driving the application, to find defects a user would encounter. It remains necessary because automation is expensive to write and maintain and only checks what it was told to check — it confirms known behaviour rather than discovering unknown problems. Exploratory testing, usability judgement, one-off checks, and testing features whose design is still changing are all cheaper and more effective manually. The realistic answer is that mature teams automate stable, repetitive regression paths and keep humans for judgement and discovery, and interviewers like this answer because it shows you understand the trade-off rather than repeating that automation is the future.
What is the difference between verification and validation?
Verification asks "are we building the product right?" — checking work products against specifications through reviews, walkthroughs and inspections, without necessarily executing the code. Validation asks "are we building the right product?" — executing the software to confirm it meets the user's actual requirement. A document review is verification; running a test case against a build is validation. The compact way to say it in an interview: verification is static and specification-facing, validation is dynamic and user-facing.
What is a test case, and what does a good one contain?
A test case is a documented set of conditions under which you determine whether a feature works as expected. A usable one has an identifier, a clear title, preconditions, specific test data, numbered steps precise enough for someone else to follow without asking you questions, an expected result, and space for the actual result and status. The most common fresher weakness is a vague expected result — "page should work" tells the next person nothing. "User is redirected to the dashboard and the header shows their registered name" is a testable expectation, and interviewers notice the difference immediately.
Test case versus test scenario — what is the difference?
A test scenario is a high-level description of what to test: "verify the login functionality". A test case is the detailed, step-by-step execution of one specific path within that scenario: "verify login fails with a valid email and an incorrect password". One scenario typically breaks into many test cases. Scenarios are useful for coverage discussions and for getting agreement on scope; test cases are what you actually execute and report against.
What should a bug report contain?
A title that states the problem in one line, the environment (build number, browser or device, operating system, test data used), numbered steps to reproduce, the expected result, the actual result, severity and priority, and an attachment — screenshot, video or log — where it helps. The steps are the part that decides whether the bug gets fixed quickly or bounced back to you: a developer who cannot reproduce it will return it. Being able to write one clear, reproducible report is the most practically useful skill you can demonstrate as a fresher, and it is worth having a real example ready to describe.
Severity versus priority — give an example of each combination.
Severity is the technical impact of the defect on the system; priority is how urgently the business wants it fixed. They are set by different people and frequently diverge, which is exactly why interviewers ask. High severity, low priority: the application crashes on a feature nobody uses, or on an obsolete browser — serious, but it can wait. Low severity, high priority: the company name is misspelled on the home page, or a logo is wrong — trivial technically, urgent commercially. High severity and high priority is payment failing at checkout; low and low is a minor alignment issue on a rarely-visited page. Being able to give both crossed examples is what separates a memorised answer from an understood one.
What is smoke testing, and how is sanity testing different?
Smoke testing is a broad, shallow check that a new build is stable enough to test at all — can you launch it, log in, reach the main screens? If smoke fails, the build is rejected and returned rather than tested further. Sanity testing is narrow and deep: after a specific fix or small change, you check that the affected functionality now behaves correctly and nothing obviously adjacent has broken. Smoke is wide and generally scripted; sanity is focused and often unscripted.
What is regression testing, and how is it different from retesting?
Retesting means executing the specific failed test case again on a new build to confirm the reported defect is actually fixed. Regression testing means re-running a broader set of previously passing tests to confirm the change did not break something else. Retesting is always planned — you know which defect you are verifying — while regression is about unintended consequences elsewhere. In practice both happen on the same build: you retest the fix, then run the regression suite around it. Regression is also the first thing teams automate, because it is repetitive and grows with every release.
Functional versus non-functional testing?
Functional testing checks what the system does against requirements — login works, an order is placed, the total calculates correctly. Non-functional testing checks how well it does it: performance and load, security, usability, compatibility across browsers and devices, reliability, accessibility. A fresher is usually hired into functional work, so the useful thing to add in an interview is one concrete non-functional example you understand — that a page which loads correctly but takes twelve seconds has passed functional testing and failed the user.
Black box, white box and grey box testing?
Black box testing examines behaviour through the interface with no knowledge of the internal code — this is where most manual testing sits. White box testing uses knowledge of the internal structure to design tests, covering statements, branches and paths, and is usually done by developers. Grey box is partial knowledge: you can see the database or the API contract but not the implementation, which lets you design sharper tests — for example checking that a record was actually written correctly rather than only that a success message appeared.
What are the phases of the STLC?
Requirement analysis, test planning, test case design and development, test environment setup, test execution, and test cycle closure. Requirement analysis is where testers identify what is testable and raise ambiguities — the most valuable and most skipped phase, since a requirement nobody questioned is where defects are born. Closure covers metrics, reporting and lessons learned. Interviewers are checking that you know testing is a lifecycle rather than a thing that happens after development finishes.
Describe the bug life cycle.
A defect is logged as New, then Assigned to a developer, moves to Open while being worked on, and becomes Fixed when the developer believes it is resolved. The tester retests: if it passes it becomes Closed, and if it does not it is Reopened and goes back. The states worth knowing beyond the happy path are Rejected — the developer disputes it, often because it is expected behaviour or not reproducible — Deferred, meaning it is genuine but postponed to a later release, and Duplicate. Knowing the non-happy states is what shows you have thought about the real workflow.
Explain equivalence partitioning and boundary value analysis with an example.
Both reduce the number of test cases without losing coverage. Equivalence partitioning divides input into groups that should behave identically, then tests one value from each: for an age field accepting 18 to 60, the partitions are below 18, 18 to 60, and above 60, so you test one value from each rather than every number. Boundary value analysis then tests the edges, where defects cluster because of off-by-one errors: 17, 18, 19, 59, 60, 61. Combining them is standard practice, and being able to work through a concrete field like this out loud is far more convincing than reciting the definitions.
Here is a login page. How would you test it?
This is the question that most often decides a fresher QA interview, and the mark is for structured breadth rather than a long list. Work through categories out loud: functional positives (valid credentials log in and land on the right page), functional negatives (wrong password, wrong username, both wrong, empty fields, only spaces), boundary and validation (maximum and minimum lengths, special characters, SQL-injection-style input, leading and trailing spaces, case sensitivity of email versus password), security-adjacent behaviour (password masked, not exposed in the URL, lockout after repeated failures, session expiry, back button after logout), usability (tab order, error message clarity, error messages that do not reveal which field was wrong), and compatibility (browsers, mobile, screen readers). Say the categories as you go — the interviewer is scoring your method, not counting your cases.
How would you test a pen, a lift, or an ATM?
The same structured approach applied to a physical object, asked to see whether you can think without a requirements document. Cover functional (does it write on paper, does the lift stop at the requested floor), non-functional (how long does the refill last, how much weight before the alarm), boundary and stress (write continuously until it runs out, overload the lift by one person), negative (write on glass or cloth, press two floors at once, press a button while doors are closing), usability (grip, button labelling, whether the display is readable), and safety or recovery (power failure mid-journey, emergency button, what happens when the ATM loses connection mid-transaction). Ask a clarifying question first — "who is the intended user, and what were the requirements?" — because good testers establish scope before generating cases, and interviewers reward that.
What is User Acceptance Testing, and who performs it?
UAT is the final validation stage where the software is checked against real business needs before release, usually by the client, business users or a product owner rather than by the QA team. It answers whether the system supports the actual workflow, not whether it matches the specification — which is why defects still surface there after functional testing has passed. Testers typically support UAT by preparing environments, realistic data and scenarios, and by triaging what comes back. Alpha testing happens in-house before this; beta testing happens with real users in their own environment.
A developer rejects your bug saying it works on their machine. What do you do?
This is a communication question wearing a technical costume, and it is asked often because it is a daily reality. The answer: do not escalate first. Re-verify on your side, capture exactly what differs — build number, environment, browser and version, test data, user role, network conditions — and attach a screen recording with the reproduction steps. Most "works on my machine" disputes are environment or data differences, and finding the difference is your job as much as theirs. If it still cannot be reproduced, sit with the developer and run it together. Escalate to a lead only when reproduction is confirmed and the disagreement is about whether it should be fixed rather than whether it exists.
What does a tester do in an Agile sprint?
Testing runs alongside development within the sprint rather than after it. Practically: refining stories and questioning acceptance criteria during planning, writing test cases while development is in progress, testing each story as it becomes available rather than waiting for a build at the end, raising defects immediately, running regression before the sprint closes, and reporting status at the daily stand-up. The key point interviewers want to hear is that a story is not done until it is tested, and that a tester who waits until the last two days of a sprint has created the bottleneck everyone complains about.
Which testing tools do you know?
Answer honestly at fresher level and be specific about depth. Defect tracking and test management — Jira is near-universal, and TestRail, Zephyr or qTest appear alongside it. API testing — Postman, which is entirely learnable before an interview and increasingly expected. Basic SQL for verifying that data actually landed correctly in the database, which is a genuine differentiator among fresher QA candidates. Automation awareness — Selenium with Java or Python, or Playwright and Cypress, where the honest fresher answer is that you have written a few basic scripts rather than that you are proficient. Never claim tool experience you cannot demonstrate; a two-minute follow-up exposes it and costs you the rest of the interview.
Where does a manual testing career actually lead?
Ask this in the interview if they invite questions, and know the honest answer going in. The common paths are automation and SDET roles, performance testing, security testing, business analysis, and domain specialisation where deep knowledge of insurance, banking or healthcare processes becomes the valuable asset. What makes the difference is deliberate movement: learning a scripting language and an automation framework in your first two years, while doing the manual work well enough that people trust your judgement. Testers who plan that transition make it; testers who wait to be moved frequently do not. In the interview itself, express interest in growing into automation rather than saying you intend to leave testing for development — the first is ambition, the second sounds like you will leave.
Don't just read Manual testing / QA questions — get asked them
Phiny's AI interviews you on exactly these topics, follows up on weak answers, and tells you what a stronger answer looks like. Text interviews are free and unlimited.
Start a free AI mock interviewHow to prepare
- Practise testing something out loud, every day, for a week before the interview. Pick an app you already use — a payment screen, a food delivery cart, a college portal — and generate cases by category until the structure is automatic. This single habit prepares you for the question most likely to decide the outcome.
- Have one real bug report you can describe from memory: what you found, on what build and environment, the steps, and what the fix turned out to be. A concrete example beats every memorised definition of severity you could offer.
- Know severity versus priority with both crossed examples ready. It is the most asked distinction in fresher QA interviews, and answering with a high-severity-low-priority case and a low-severity-high-priority case immediately shows understanding rather than recall.
- Learn basic SQL — select, where, joins, count — and enough Postman to send a request and read a response. These two are the clearest differentiators among fresher QA candidates right now, and both are a weekend of work.
- Ask a clarifying question before generating test cases when handed an open-ended object or feature. Establishing the user and the requirement first is what an experienced tester does, and interviewers score it.
- Never claim automation proficiency you do not have. "I have written basic Selenium scripts and I am still learning the framework" is a respected answer; a claim of proficiency that collapses under one follow-up costs you the whole interview.
- Do not tell the interviewer you plan to switch to development. Even when it is true, it answers the question they are silently asking — will this person stay? — in the way that ends the conversation. Interest in growing into automation says the same ambition without the exit.
Where these questions get asked
- TCS NQT guide and Infosys hiring guide — the two biggest exams these questions appear in.
- All company placement guides — pattern, syllabus and rounds for every mass recruiter.