Manual Testing Interview Questions for Freshers

“In my final-year project I ended up being the person who tried to break everyone's screens before the demo, and I found I really liked it. Finding a problem before a user does feels useful. I don't see manual testing and automation as rivals. Someone still has to understand the product, decide what's worth testing and try the new feature the first time, and a script can't tell you a screen is confusing. Automation is good for repeating checks that already pass. So my plan is to get strong at test design and bug reporting first, because that's what makes automated tests good too, and then learn automation on top of that over my first year or two.”

“For me, software testing means checking that the software does what it's supposed to do, and finding the places where it doesn't, before a real user runs into them. It also gives the team confidence to release. Developers do test their own code, and they should, with unit tests. But when you write something, you test it the way you meant it to be used. You know which buttons to press and in what order. A tester comes in without those assumptions and tries what a real user might do, like leaving a field empty, pressing back halfway through, or typing a very long name. In my college project, my teammate's form worked perfectly for him, and I broke it in two minutes by pasting in a name with an apostrophe.”

“An error is a human mistake. A defect, which people also call a bug or a fault, is what that mistake leaves behind in the code or in a document. A failure is when the software actually behaves wrongly because that defect was run. Say a developer misreads the rule and writes greater than instead of greater than or equal to for a discount on orders of five items or more. That misreading is the error. The wrong comparison sitting in the code is the defect. When a customer orders exactly five items and doesn't get the discount, that's the failure. And a defect can sit there for months without causing a failure if nobody ever orders exactly five, which is why testers go looking for those edge cases.”

“The seven are: testing shows bugs are present but can't prove there are none, exhaustive testing is impossible, testing early saves time and money, defects tend to cluster in a few areas, the pesticide paradox, testing depends on context, and the absence-of-errors fallacy. Two I think about a lot are clustering and the pesticide paradox. Clustering means if I find a few bugs in the payment module, I should dig harder there, because problems gather in complex or rushed code. The pesticide paradox means if I run the same test cases every cycle, they stop finding new bugs, like insects getting used to one spray. So I'd keep reviewing and adding new cases, and mix in some exploratory testing, instead of running the same checklist for ever.”

“Quality assurance is about the process. It's the work of making sure the team builds things in a way that prevents defects, like having coding standards, reviewing requirements and agreeing a definition of done. Quality control is about the product. It checks what was actually built and finds the defects that got through. Testing is one part of quality control: running the software to see if it behaves correctly. A simple way I remember it is that assurance stops problems being made, and control catches the ones that were made anyway. In practice, a tester does both. When I point out a vague requirement in a review, that's closer to assurance. When I run test cases on a build, that's control.”

“The difference is how much of the inside you can see. In black box testing I only know what goes in and what should come out. I test from the requirements and the screen, and I don't look at the code. White box testing is done with the code in front of you, checking that each branch and condition runs correctly, and it's mostly developers writing unit tests. Grey box sits in between: I still test from the outside, but I know a bit about how it works, like which database table a form saves to. A manual tester mostly does black box. In my internship I did black box on the screens, but I also ran a simple query to check the saved record, and that's grey box.”

“Static testing means checking something without running it, like reading the requirements, the design or the code to find problems. Dynamic testing is running the software and comparing the actual result with the expected one. Static testing is cheaper because you catch a mistake while it's still a sentence in a document. There are a few kinds of review. An informal review is just a colleague reading it over. A walkthrough is when the author leads the group through the document and explains it, mostly to share understanding. An inspection is the most formal: a trained moderator, set roles, a checklist, and defects logged and followed up. In my project we did a quick review of the requirement document and found that nobody had said what happens when a user's session times out.”

“Acceptance testing is the last level of testing, where the customer or real users check whether the software meets their needs and decide whether to accept it. User acceptance testing is the common kind, done by business users with real tasks. Alpha and beta testing are types of acceptance testing, mostly for products sold to many people. Alpha testing happens at the company that built it, in a controlled setting, by internal people or a small group of invited users, and the team can watch and fix things quickly. Beta testing goes out to real users in their own homes or offices, on their own devices, before the full release. Their feedback catches problems the team never thought of, like odd phones or slow networks.”

“Integration testing checks that separate modules work correctly together, for example that the cart passes the right total to the payment module. Units can each work alone and still fail when joined. In top-down integration you start with the top module, like the user interface, and join lower modules one by one. If a lower one, say payment, isn't ready, you use a stub, a simple dummy that returns a fixed answer like payment success. In bottom-up you start with the lower modules and move up. Then the missing piece is the caller, so you write a driver, a small piece of code that calls the module and passes it data. An easy way I remember it: a stub is called, a driver does the calling.”

“Ad hoc testing is informal testing with no plan or test cases. The tester uses what they know about the app to poke at the areas most likely to break, like doing things out of order or at odd times. Monkey testing is more random. You throw random taps, clicks or keystrokes at the app without any knowledge of how it should work, often with a tool, just to see if it crashes or freezes. So ad hoc uses the tester's brain, and monkey testing uses randomness. Both are useful as extras. Ad hoc finds bugs that formal cases miss, and monkey testing is good at finding crashes. The weakness is that they're hard to repeat, so when I find something I note the exact steps right away.”

“Compatibility testing checks that the product works the same across different browsers, devices, screen sizes and operating systems. You can't test everything, so first I'd ask whether we have analytics showing what our users actually use, and cover the top few browsers plus one or two popular phones on each mobile system. If there's no data, I'd pick the most common desktop browsers and one Android and one iPhone. I wouldn't run every test case everywhere. On each one I'd run the main flows, like sign-up, search and checkout, and look at layout, text overflowing, buttons too small to tap, and pop-ups going off screen. In my college project, the site looked fine on laptops but the menu covered the page on a small phone.”

“Positive testing checks that the system accepts valid input and does the right thing. Negative testing checks that it refuses invalid input properly, with a clear message, and doesn't crash or save bad data. For this password rule, my positive tests would be exactly 8 characters with one number, a longer password with several numbers, and one that also has special characters. My negative tests would be 7 characters with a number, 8 or more letters with no number, only numbers but too short, an empty field, and only spaces. For each negative case I'd check the error message says what's wrong, like needs at least one number, and not just invalid password. I'd also check the password is hidden as I type.”

“A test scenario is the broad idea of what to test, usually one line. For a food order app, a scenario would be check that a user can place an order with cash on delivery. A test case is one detailed path inside that scenario, with a precondition, steps, test data and an expected result. For example: logged-in user with one item in the cart selects cash on delivery, taps place order, and should see an order confirmation with an order number. One scenario usually gives several test cases, like an empty cart or a closed restaurant. A test script usually means the automated code that runs those steps, though some teams use it for very detailed manual steps too. As a fresher I'd mostly write scenarios and test cases.”

“Error guessing is a technique where you use experience, and knowledge of common mistakes, to guess the inputs most likely to cause a bug. It isn't a formal method like boundary value analysis, so it works best on top of those. For a date of birth field, I'd try 29 February in a leap year and in a non-leap year, 31st of a month that has only 30 days, a date in the future, today's date, a date far in the past, and typing the day and month the other way round. I'd also try leaving it empty, pasting letters, and, if there's an age rule, the day someone turns exactly old enough. Dates are a classic place for bugs, so I'd spend extra time there.”

“State transition testing fits here because what happens depends on what happened before. I'd draw the states: waiting for PIN, first wrong attempt, second wrong attempt, card locked, and access granted. The events are entering a right or wrong PIN. Then my tests follow the paths: a right PIN first time gives access, one wrong then right gives access, two wrong then right gives access, and three wrong locks the card. The tests that separate a good tester are the invalid transitions. Once the card is locked, entering the right PIN must not give access. And I'd check the counter resets after a successful entry, so two wrong, then the right PIN, then one more wrong shouldn't lock the card. Whether the count also carries over to the next day is something I'd confirm in the requirement.”

“In the plain waterfall model, the phases run one after another: requirements, design, coding, then testing, then release. Testing is one late phase, so a misunderstood requirement shows up very late and costs a lot to fix. The V-model keeps the same order but pairs every development stage with a test level. The user requirements pair with acceptance testing, the system specification with system testing, the high-level design with integration testing, and the detailed module design with unit testing. The left side goes down as things are built, and the right side goes up as they're tested. For a tester, the big change is that I start designing acceptance and system tests while the requirements are being written, so I'm reviewing and planning from the start.”

“Entry criteria are the conditions that must be met before we start a test cycle, and exit criteria are the conditions for saying it's finished. For entry, I'd expect the requirements to be signed off, the build deployed to the test environment with a smoke test passing, and the test cases reviewed with test data ready. For exit, I'd expect all planned test cases to be run, no open critical or high severity bugs, or any open ones accepted in writing, and a test summary report shared. They matter because without entry criteria testers waste a day on a build that can't even log in, and without exit criteria the team stops testing just because the date arrived. They're agreed in the test plan at the start.”

“I'd split it into three groups. Valid inputs first: a normal address, one with a dot or a plus sign before the @, and one with a subdomain after it, and all of these should be accepted. Then invalid ones: no @ sign, nothing after the @, two @ signs, a space in the middle, and an empty field, and each should show a clear message. Then the things people forget. What happens if the email is already registered? Are spaces at the start or end trimmed? Is an address in capitals treated as the same account as the lowercase one? What's the maximum length? I'd also check that the confirmation email really arrives, because a field can accept an address and the sign-up can still fail later.”

“I'd start with the functional ones: searching an exact product name, a partial word, a category like shoes, a word with no results, a misspelling, and checking filters and sorting on the results. Then input edges: an empty search, only spaces, a very long string, special characters like quotes or angle brackets, and capital letters. Then things beyond function: how fast results load, suggestions appearing as I type, the page on a phone, and whether the price in the results matches the product page. My first five would be an exact product name, a partial word, no results showing a helpful message, a common misspelling, and filters working on results. Those are what most shoppers do every day, and if they break, people can't find anything to buy.”

“First I'd ask a few questions: what's the weight limit, how many people it's rated for, and whether there are special modes like fire service. Then I'd group my tests. Functional: calling it from every floor, going to every floor, the doors opening and closing, the floor display, and what happens when people press several floors at once or press up and down together. Safety: the doors should reopen if a hand or bag is in the way, the overload alarm should sound and the lift shouldn't move above the limit, the emergency button and phone should work, and it should behave safely in a power cut. Usability: buttons a wheelchair user can reach, braille on the buttons, and a clear display. I'd treat safety as the highest priority.”

“In my final year, four of us built a library management web app, and I took on testing alongside some front-end work. I wrote around sixty test cases in a spreadsheet from our requirement document, covering issuing, returning, fines and search. I used boundary values for the fine rules and logged bugs on a shared board with steps and screenshots. The best bug was in the fine calculation: returning a book exactly on the due date still charged one day's fine, because the check used the time as well as the date. Our developer fixed it in an hour, and I retested it and ran the related cases again. Looking back, I'd have started writing tests while the design was still being made, instead of in the last two weeks.”

“In my third year, two days before our project demo, I found four bugs in my friend's booking module. The worst one let two people book the same slot. I didn't want to announce it in the group chat, so I messaged him directly and sat with him that evening. I showed him the exact steps and screenshots and said, "I've found a few things in booking, can we look at them together?" We agreed the double booking had to be fixed before the demo, two smaller ones could wait, and one was actually a gap in our requirements. I retested his fix that night. He told me later he appreciated that it came as a list with steps and not as "it's broken". That's how I'd want to work with developers too.”

“First I'd try to answer it myself. I'd read the user story or requirement for that feature and search the bug tracker to see if someone has already reported it or marked it as by design. Then I'd reproduce it and write down the exact steps, so I'm not asking a vague question. If it's still unclear, I'd ask a senior tester or the product owner, and show them the steps and a screenshot instead of just saying something looks odd. If it's a bug, I log it properly. If it's working as intended but I think users will be confused, I'd still mention it as a usability suggestion. As a new person, I'd rather ask one well-prepared question than stay quiet, because that one might be real.”