Manual Testing Interview Questions

"SDLC is the full life cycle of the product, from gathering requirements through design, coding, testing, release and maintenance. STLC is the testing team's own cycle that runs inside it: we analyse the requirements, plan the testing, write test cases and data, get the environment ready, execute and log defects, and then close with a report. The two run in parallel. So testing shouldn't wait for a build. As soon as requirements are written I'm reading them, asking what happens on an empty field or a timeout, and flagging anything I can't turn into a clear expected result. A gap caught in a requirement review costs a conversation. The same gap caught after release costs a fix, a retest and sometimes a customer."

"It starts with requirement analysis. The input is the requirement documents or user stories, and I hand over a list of questions, what's testable, and a first traceability matrix. Next is test planning, where the output is the test plan: scope, approach, effort, schedule, roles and risks. Then test case development, which produces the test cases and the test data they need, reviewed by a peer or the lead. Environment setup runs alongside, and it's done when a smoke test passes on the build. Execution comes next: I run the cases, record pass or fail, raise defects and retest the fixes. Finally test closure, where I write a summary of what was covered, what's still open and what we'd change next time. Each phase has entry and exit criteria so nobody starts on shaky ground."

"Verification asks, are we building the product right? It checks each work product against what was specified, and it's mostly static: requirement reviews, design walkthroughs, code inspections, checking test cases against the requirements. Nothing is executed. Validation asks, are we building the right product? That's dynamic. We run the software, through system testing and especially user acceptance testing, to see it actually does what the users need. You need both. I've seen a feature that matched its spec line by line, so it passed verification, but when users tried it in acceptance testing the workflow didn't fit how they worked, so it failed validation. Verification catches mistakes early and cheaply. Validation catches a spec that was wrong in the first place."

"Unit testing checks the smallest pieces, a function or a class, on their own. Developers write and run those. Integration testing checks that modules work together: data passes correctly across an interface, one service handles another's error. If a module isn't ready, we use a stub or a driver to stand in for it. System testing is where most of my work sits. It's the whole integrated product in an environment close to production, tested end to end against the requirements, both functional and non-functional. Then acceptance testing, where the business users or the client confirm it's fit for their purpose before go-live. That can be user acceptance testing, or alpha and beta testing for a product with outside users. Each level catches a different kind of defect, so skipping one just pushes those defects to the next."

"Smoke testing is a quick, wide check on a new build. I touch the critical paths, can I log in, open the main screens, save a record, place an order, without going deep. The question is whether the build is stable enough to spend a full test cycle on. If the smoke fails, the build goes back. Sanity testing is narrow. After a small change or a bug fix, I check that one area in a bit more depth to confirm it behaves sensibly before I do anything heavier. It's often unscripted, and some teams treat it as a small slice of regression. So smoke is wide and shallow, sanity is narrow and a little deeper. I'll add that teams use these terms loosely, and some treat them as the same thing, so in a new team I ask what they mean by each one rather than assume."

"Retesting, also called confirmation testing, is about one defect. The developer says it's fixed, so I rerun the same steps with the same data that failed before and confirm it now passes. If it doesn't, the bug gets reopened. Regression testing is about everything else. A fix or a new feature can break something that used to work, so I rerun tests that previously passed, especially in areas connected to the change. Retesting comes first, because there's no point checking side effects of a fix that doesn't work yet. Retesting is planned, you know exactly which cases, while regression needs a judgement about how wide to go. Regression is also the part that repeats every release, so it's the first place teams look to automate."

"Functional testing checks what the system does against the requirements. For a banking app, one example is a fund transfer: with enough balance it goes through, the balance updates on both accounts, and with too little balance it's refused with a clear message. Another is the statement screen showing the right transactions for the date range I pick. Non-functional testing checks how well it does it. For the same app, security is a big one: the session should time out after inactivity and the app shouldn't show account details in the recent apps preview. Another is compatibility: the app works on the older phone models and OS versions we say we support. Performance and accessibility sit here too. A feature can pass every functional test and still fail users because it's slow or confusing."

"Equivalence partitioning says that if the system treats a group of values the same way, testing one value from that group is enough. For a ticket field that accepts 1 to 10, I see one valid partition, 1 to 10, and I'd test it with something like 5. Then the invalid partitions: less than 1, so 0 or a negative number, and more than 10, say 15. I don't stop at numbers though. What about letters, a decimal like 2.5, a blank field, or special characters? Each of those is its own invalid class, and each should give a clear error, not a crash. So instead of trying every number, I've got about seven tests that cover every class. Then I'd add boundary tests at 0, 1, 10 and 11, because that's where the logic usually breaks."

"Boundary value analysis is based on where mistakes actually happen: a developer writes greater than 18 when the rule means 18 or more. So I test right at the edges. With the two-value approach, I pick each boundary and its nearest neighbour outside: 17 and 18 at the bottom, 60 and 61 at the top. 18 and 60 should be accepted, 17 and 61 rejected. If the field is risky, I use the three-value approach and add 19 and 59 as well. Before any of that I'd confirm with the business whether 18 to 60 includes both ends, because 'between 18 and 60' in a requirement can mean different things to different people. And I'd combine this with equivalence partitioning, so I also have one clearly valid middle value and invalid types like letters or a blank."

"A decision table is useful whenever the outcome depends on a combination of conditions. Here I have two conditions, is the customer a member, and does the cart have more than five items, and one action, free delivery or not. Two yes-or-no conditions give four combinations. Member with six items, free. Member with two items, free. Non-member with six items, free. Non-member with two items, delivery is charged. Each column is one test case, so I know I've covered every combination and not just the obvious happy path. Then I layer boundary thinking on top: 'more than five' means five items should be charged for a non-member and six should be free. That five-versus-six case is where I'd expect a bug. With more conditions the table grows fast, so I'd collapse rules where a condition doesn't change the result."

"A test case needs an ID, a clear title that says what's being checked, the requirement it traces to, preconditions like 'user is registered and logged out', the exact test data, numbered steps, and an expected result. When it's run we add the actual result and the status. What makes it good is that someone who's never seen the feature can run it and reach the same pass or fail I would. So the expected result is specific: 'error message Invalid password appears under the field and the user stays on the login page', not 'it should work'. What makes one bad is vagueness, testing five things in one case so you can't tell what failed, or relying on data that only existed on my machine. I also keep steps short so the case survives small screen changes."

"A traceability matrix maps each requirement to the test cases that cover it, and often to the execution results and any defects. Forward traceability, from requirement to tests, tells me nothing is untested. Backward, from tests to requirements, tells me I'm not spending time on tests nobody asked for. Having both is called bidirectional. Where it really paid off for me was when a requirement changed halfway through a release. The product owner changed how refunds were calculated, and because of the matrix I could see in a few minutes that eleven test cases and two open defects were affected, so I updated exactly those. It also helped at sign-off: when someone asked 'is the export feature tested?', I could show the cases, their results, and the one known issue still open."

"A test plan is for a specific project or release. It says what's in scope and just as clearly what's out of scope, the approach for each area, the test environments and data, entry and exit criteria, suspension criteria for when we stop because the build is too broken, the schedule, who does what, the deliverables, and the risks with what we'll do about each. A test strategy sits above it. It's the general approach the organisation or programme takes: which test levels and types we use, how we decide what to automate, which tools, how defects are classified and handled. It changes rarely. So the strategy says 'we always do risk-based regression before release', and this release's plan says which areas are high risk this time, who covers them and by when. In small teams the two often live in one document, and that's fine."

"You can never test everything, so the real question is whether the remaining risk is acceptable. I decide against exit criteria we agreed in the test plan, not on a feeling. Typically that's: all planned high-priority tests executed, no open critical or high defects unless the business has accepted them, every requirement has at least one passing test, and regression passed on the final build. Then I look at the trend. If we're still finding serious bugs every day, we're not done, whatever the calendar says. If the rate of new defects has flattened and what we're finding is minor, that's a good sign. Sometimes the deadline arrives first. Then my job is to state clearly what wasn't tested and what could go wrong, so the product owner makes the release call knowing the risk."

"I'd use risk-based testing. For each area I ask two things: how likely is it to break, and how bad would it be if it did? Likelihood goes up where the code changed this release, where it's complex, and where we've had bugs before. Impact is highest on core journeys like sign-up, login and checkout, anything that touches money or personal data, and features most customers use daily. So first I run the tests for the changed areas and what they connect to, then the critical end-to-end journeys, then the high-risk areas with a history. Low-risk, stable areas that nothing touched get a light pass or wait. Before I start, I share that list with the lead and product owner, so it's a shared decision that, say, the admin reports won't be fully regressed this time."

"When I log a bug, it starts as New. The lead or triage meeting reviews it and it becomes Assigned to a developer. When they start work it's Open or In Progress, and when they've fixed it, it moves to Fixed and then Ready for Retest once it's on a test build. I retest with the original steps. If it passes, it's Verified, and then Closed. If it fails, I reopen it with a note on what I saw and it goes back to the developer. There are side exits too. It can be Rejected if it's working as designed, marked Duplicate if someone already logged it, Deferred if it's real but planned for a later release, or Cannot Reproduce. The exact names depend on how the team set up their tracker, so I learn their workflow first."

"Severity is the impact on the system: does it crash, lose data, block a feature, or is it cosmetic? Priority is the urgency: how soon the business needs it fixed. The tester usually suggests severity, and the product owner or lead sets priority. They often line up but not always. High severity, low priority: the app crashes when you export a report in an old file format that only a handful of internal users still pick, and there's a working format right next to it. It's a crash, but it can wait a release. Low severity, high priority: the company name is misspelt on the home page banner, or the launch offer shows the wrong end date. Nothing breaks technically, but every visitor sees it, so it's fixed today. Checkout failing for everyone is simply high and high."

"The title does a lot of work. 'Cart total ignores removed item after quantity change' beats 'cart issue'. Then the environment: build number, browser or device, OS, and which test server. Preconditions and the exact test data, like which user account and which product. Then short numbered steps from a known starting point, and a clear expected result next to the actual result. I add how often it happens, every time or three out of ten tries, and attach a screenshot or a short screen recording, plus console or server logs if I can get them. I suggest a severity. I keep it factual, no opinions about the code, and one bug per report so it can be tracked and closed cleanly. Before logging it I search for duplicates and reproduce it once more myself."

"First I write down everything about the two times it happened while it's fresh: the exact time, build, account, data and device, so a developer can match it against the server logs. Then I try to find the pattern by changing one thing at a time. Does it happen with a slow network, after the session has been idle, with two tabs open, with a particular record, right after a deploy, only with a cold cache? Intermittent bugs are often timing or data problems, so those are my first suspects. I record my screen while trying, so if it shows up I've got it. Even if I can't pin it down, I still log it, marked as intermittent with 'seen two times in about twenty attempts' and all the evidence. Then I ask the developer if we can add logging around that area."

"Exploratory testing means learning about the product, designing tests and running them all at once, where each result shapes my next move. It's not random because I give it structure. I start with a charter, a one-line mission like 'explore the coupon field with expired, reused and oddly formatted codes to find pricing mistakes'. I time-box the session, for me usually sixty to ninety minutes, though that's a habit, not a rule, and take notes as I go: what I tried, what I saw, bugs, questions, and ideas for scripted cases later. Afterwards I debrief with the lead or developer. I also use heuristics to guide me, like trying boundaries, interrupting a flow halfway, going back and forth, or using the feature the way an impatient user would. It finds the bugs scripted cases miss, because scripts only check what someone thought of in advance."

"My work starts before the sprint, in refinement. I read the stories, ask the awkward questions, what happens if the upload is too big, what about a user with no permission, and help tighten the acceptance criteria. In sprint planning I make sure testing effort is included in the estimate. Once the sprint starts I write my scenarios and test data while developers build, so I'm ready the moment a story is done. I test each story as soon as it lands, not all at the end, and I'll often sit with the developer to check it on their machine first. Alongside that I run regression on the changed areas and do some exploratory sessions. A story isn't done until it's tested. At the end I help in the sprint review and raise anything that slowed testing in the retrospective."

"I start with the acceptance criteria and turn each one into at least one scenario, usually in Given, When, Then form, so it's clear what the setup is, what the user does and what should happen. For a story like 'as a user I can reset my password by email', one would be: given a registered email, when I request a reset, then I get a link. Then I look for what the criteria don't say, because that's where the bugs are. An unregistered email: does the message give away that the account doesn't exist? The link used twice, or after it expires? A new password that breaks the rules? Two reset requests in a row, which link works? I write those as scenarios too, and anything I can't answer from the story becomes a question for the product owner in refinement."

"I'd group it. Functional first: valid username and password logs me in, wrong password fails, unknown username fails, both fields empty and each one empty give clear messages. Is the password case-sensitive? Are spaces around the username trimmed? Remember me keeps me signed in after closing the browser, and without it I'm signed out. Forgot password sends a reset link. Then security: the password is masked, the error doesn't say which field was wrong, the account locks or slows down after repeated failures, the page is on HTTPS, and after logout the back button doesn't show a logged-in page. I'd also try special characters and very long input to check they're handled safely. Then usability: tab order, Enter submits, labels work with a screen reader. Finally, a few browsers and a phone."

"Before I test anything, I'd ask about the requirements. Is it a cheap pen for offices or a premium gift pen? Is there a spec for ink colour, line width, or how many pages it should write? That changes what 'passing' means. Then functional tests: it writes as soon as I start, the line is smooth with no gaps or blobs, the colour matches the body, the click mechanism or cap works, and the refill fits if it's refillable. Non-functional: is it comfortable to hold for a long time, does the click still work after many hundreds of presses, does it survive a drop, does it leak in a warm pocket or on a plane? Then negative and edge cases: writing on glossy paper, damp paper, at an angle, upside down. Finally the packaging and the printed branding, because customers see those first."

"At my last company we were releasing a new address book in a delivery app. All the scripted cases passed and the demo went well. During an exploratory session I edited a saved address, went back without saving, and then placed an order. The order screen showed the edited address, but the order was sent with the old one. Nobody had tried abandoning an edit, because the test cases all followed the save path. I reproduced it on two devices, recorded it, and logged it with the exact steps and the order IDs so the developer could see it in the data. It turned out a cached copy of the address wasn't being cleared. It was fixed before release, and I added 'abandon an edit halfway' as a standard check for every form we test."

"In one release I logged that the search results ignored the 'in stock only' filter after you changed the sort order. The developer rejected it as 'working as designed'. First I re-read the story and reproduced it again, to make sure I hadn't misunderstood. Then instead of arguing in comments I asked for ten minutes on a call and showed it on my screen next to the acceptance criterion, which said the filter should stay applied. He'd understood the sort as a fresh search. So it was really a requirement question, and I brought in the product owner, who confirmed the filter should persist. It was fixed that sprint. Looking back, what worked was checking myself first and keeping it about the product. I've also had the opposite, where the product owner said it was fine, and I accepted that and moved on."

"On one project we had to test a new approval flow for expense claims, and the story was two lines long. I didn't want to test against my own guesses, so I spent the first morning with the product owner and the developer, and looked at how the old approval screen worked and at the designs. Then I wrote my understanding down as a short list of scenarios and assumptions, like 'a manager can't approve their own claim' and 'a rejected claim can be edited and resubmitted', and sent it round for a yes or no. Half were confirmed, two were wrong and one nobody had thought about. That list became our acceptance criteria. I started with exploratory sessions while it settled, then wrote the scripted cases. The release went out and users didn't raise a single defect on that flow."

"First I'd spend a few minutes making sure it's real: reproduce it, note which data gets corrupted and under what conditions, and check whether it's also in production already. Then I'd raise it straight away with my lead and the product owner, not in tomorrow's stand-up. Data corruption is high severity even if few people use the feature, because it can't always be undone. I'd bring the facts and some options: can the developer fix it tonight and can I retest and regress the area in time, can we switch that feature off or hide it for this release, or do we delay. I'd give my honest view of the risk, but the release decision belongs to the product owner. Whatever we choose, I'd make sure it's written down, and if we ship with the feature off, I'd verify that it really is off."

"I wouldn't just say no, and I wouldn't just agree. I'd ask to see what actually changed. 'Small' changes often touch shared code, like a date helper or a login check that half the app uses. Then I'd offer a middle path: instead of the full regression, a targeted run of the changed area and everything that depends on it, plus a short check of our core journeys like sign-up, login and payment. That might take a few hours instead of two days. I'd lay it out plainly: this is what I'll cover, this is what I won't, and this is what could slip through. If the manager still wants to skip it entirely, that's their call, but I'd ask for the decision in writing in the ticket so the risk is owned, and I'd watch that area closely after release."

"I'd start by owning it. I signed it off, so I don't point at the developer or the requirement. The first job is the customer, so I'd help reproduce it quickly and retest the fix. Then I'd look honestly at why it got through. Maybe we never tested that path, or we tested it with clean data while the customer had old records, or our test environment didn't match production, or the requirement never mentioned that case. Each of those has a different fix. Then I'd come back to my manager with the cause and a concrete change: the case is now in the regression suite, and, for example, we add a set of test data copied in shape from real accounts, with personal details masked. Testing can't prove there are no bugs, but the same kind of miss shouldn't happen twice."