Manual Tester interview questions and answers

Title: "Checkout: Pay button does not respond when paying by UPI". Environment: test server, build number, Chrome on Windows 11. Preconditions: logged in as a test user with one item in the cart. Steps: open the cart, click Checkout, choose UPI, click Pay. Expected: the UPI payment screen opens. Actual: nothing happens, no message is shown. Then add the severity and priority, how often it happens (every time, or three out of five tries), and attach a screenshot or screen recording and any browser console error.

Before logging, check whether it happens with other payment methods or browsers, and write that down: it saves the developer time.

Create an issue of type Bug in the right project. Fill the summary, description with steps, expected and actual results, environment, severity and priority, the affected version or sprint, and attach screenshots or logs. Link it to the user story or test case it came from, so anyone can see what it blocks. Assign it as your team's process says, often to the lead for triage.

Then track it through the workflow, for example Open, In Progress, Resolved, Reopened, Closed. When it's marked fixed, retest on the build that contains the fix and add a comment with the result before closing or reopening it. Filters and dashboards help you follow your open bugs.

Don't argue; get more facts. First try it again myself on the latest build, following my own steps exactly. If it still happens, I check what might differ between our setups: the test data or user account, browser and version, environment, cache, and the exact order of steps. I add the missing details to the bug, attach a screen recording, the time it happened and any log or console error, and offer to show it on my machine.

If it happens only sometimes, I note how often and under what conditions. If I can no longer reproduce it either, I say so honestly and agree to close it while watching for it.

It depends on what failed. If the original problem still happens, even partly, I reopen the original bug with a comment showing what I tested and on which build. If the original issue is fixed but the change has broken a different feature, I close the original and log a new bug for the new problem, linking the two so the developer sees the cause.

Mixing two problems in one bug makes tracking and metrics confusing. Finding this kind of side effect is also a sign to run regression around the changed area, so I'd tell the lead and test the related screens before the build goes further.

Group them so nothing is missed. Positive: valid username and password log in and open the home page. Negative: wrong password, unregistered username, both fields empty, one field empty, each showing a clear error that doesn't reveal which field was wrong. Field checks: the password is masked, maximum lengths, leading and trailing spaces, whether the username is case sensitive. Security: the account locks after the allowed number of failed attempts, the password isn't visible in the URL, the Back button after logout doesn't show the account. Usability: Tab order, Enter key submits, the "Forgot password" link works.

Interviewers notice whether you cover negative and security cases, not just the happy path.

Start from the rule, then apply partitions and boundaries. Indian mobile numbers have 10 digits and usually start with 6, 7, 8 or 9. Valid: a 10-digit number starting with 9, and one starting with 6. Length boundaries: 9 digits and 11 digits should be rejected. Invalid starting digits: a number starting with 0 to 5. Invalid characters: letters, spaces, special characters, and a pasted number with spaces in it. Prefixes: +91 or a leading 0, depending on what the requirement allows. Also blank, a number already registered, and whether an OTP is sent to the right number.

Ask which formats the field should accept; it's a good sign of a careful tester.

With several conditions, a decision table makes sure every combination is covered. The conditions are: member or not, order above ₹499 or not, order below ₹5,000 or not. Since an order above ₹5,000 is always above ₹499, some combinations are impossible, which leaves six real ones: member and non-member, each at ₹499 or less, between ₹500 and ₹4,999, and ₹5,000 or more. For each, the table states whether delivery is free and whether COD is offered.

Then add boundary values: ₹499, ₹500, ₹4,999 and ₹5,000, and ask the business analyst whether amounts can include paise, since ₹499.50 is above ₹499. Showing the table on paper impresses interviewers.

First, find out what it's meant to do. I'd spend a short time with the developer, business analyst or product owner to learn the purpose, the main users and the riskiest parts, and write down what I'm told so it becomes the agreed expectation. I'd also look at similar features in the app or competitors' apps.

Then I'd run time-boxed exploratory sessions: main flows first, then invalid inputs, interruptions such as a refresh or going back, different roles and devices. I log bugs as I go and write my questions down. By the end I'd share what was covered, what wasn't and my open questions, and turn the key paths into test cases for next time.

Smoke testing is a quick, broad check of a new build to decide whether it's stable enough to test at all: can you log in, do the main pages open, does the key flow complete? If the smoke test fails, the build goes back without deeper testing.

Sanity testing is a narrow, focused check after a small change or bug fix, to confirm that the change works and the area around it still behaves sensibly, before spending time on full regression. A simple way to remember it: smoke is wide and shallow, sanity is narrow and deep. Teams use the terms loosely, so explain how your team used them.

Integration testing checks that modules work together: when you transfer money, does the transfer module pass the right amount to the accounts module, and does the SMS service get the message? System testing checks the whole application against the requirements, end to end, in an environment like production: log in, view balance, add a payee, transfer, and see the statement updated, including negative cases and different devices.

User acceptance testing is done by business users or the client to confirm the system meets their needs before go-live, often with real-life scenarios. Unit testing, done by developers on individual functions, comes before all three.

A traceability matrix maps each requirement to the test cases that cover it, and usually on to the test results and any defects. Its purpose is to prove that every requirement is tested and to see the impact of a change.

In practice I keep columns for the requirement or story ID, its description, the test case IDs, the execution status and linked defect IDs. During design it shows requirements with no test cases yet; during execution it shows which requirements are failing; and when a requirement changes, it tells me which test cases to update. In Jira, linking test cases and bugs to stories does the same job, and test management tools can produce the matrix as a report.

Acceptance criteria belong to one user story: the specific conditions that story must meet, such as "The user gets an OTP within a minute." The Definition of Done is a checklist the whole team agrees on that applies to every story, such as code reviewed, unit tests passing, story tested with no open high-severity bugs, regression run, and documentation updated.

A story is complete only when it meets both: its own acceptance criteria and the team's Definition of Done. As a tester, I check the acceptance criteria during testing, and I make sure testing items are part of the Definition of Done so a story can't be called done before it's tested.

Given, When, Then states the starting situation, the action and the expected result. For example: "Given a registered user on the login page, when they enter their registered email and click Send link, then a reset link is emailed to them and a confirmation message is shown." "Given an email that isn't registered, when the user clicks Send link, then the same neutral message is shown, so the page doesn't reveal which emails have accounts." "Given a reset link older than its expiry time, when the user opens it, then they see that it has expired and can request a new one."

Each criterion maps directly to a test case, which is why testers like this format.

Test the riskiest parts first and be open about what's left. I'd check the acceptance criteria and the main flow straight away, then the negative cases, and keep the team informed in the stand-up or chat. If I can't finish with confidence, I'd tell the Scrum Master and product owner that the story isn't done rather than pass it untested; it can move to the next sprint.

Afterwards I'd raise the pattern in the retrospective. Fixes that help are splitting stories smaller, developers handing over stories one by one during the sprint, and agreeing a cut-off for development before the sprint ends so testing has time.

Query the users table for the record I just created and compare each column with what I entered: SELECT * FROM users WHERE email = 'test.user1@example.com'; I'd check the name, mobile number, status and created date, and confirm the password isn't stored as plain text. If I don't know the exact value, I can list the latest rows: SELECT * FROM users ORDER BY created_at DESC, adding LIMIT 5 in MySQL or PostgreSQL, or using TOP 5 in SQL Server.

Also check that only one row was created and that related tables, such as an address or audit table, got their entries. Testers usually get read-only access, so SELECT is what you'll use most.

Group the rows by email and keep the groups with more than one row: SELECT email, COUNT(*) AS times FROM customers GROUP BY email HAVING COUNT(*) > 1; GROUP BY puts rows with the same email together, COUNT(*) counts each group, and HAVING filters the groups after counting. WHERE can't do this, because it filters single rows before grouping.

To see the full duplicate rows, use it as a subquery: SELECT * FROM customers WHERE email IN (SELECT email FROM customers GROUP BY email HAVING COUNT(*) > 1). Testers use this to find a bug where the sign-up form allowed the same email twice. Mention case: Test@x.com and test@x.com may need LOWER(email).

Use a LEFT JOIN and keep the orders with no match: SELECT o.order_id FROM orders o LEFT JOIN payments p ON p.order_id = o.order_id WHERE o.status = 'PAID' AND p.order_id IS NULL; The left join keeps every paid order, and the payment columns are NULL where no payment exists.

With NULLs, write IS NULL or IS NOT NULL: a comparison like column = NULL is never true, so it returns no rows. COUNT(column) skips NULLs while COUNT(*) counts every row, and NOT IN with a subquery that returns a NULL gives no rows at all, so NOT EXISTS is safer. Data checks like this find real bugs in payment flows.

Be honest and positive: manual skills are the base, and automation builds on them. "Every automated test starts as a well-designed manual test, and exploratory, usability and new-feature testing still need a person. I want to become strong at test design and finding bugs first. Alongside, I'm learning [Java or Python and Selenium, or API testing with Postman] so I can automate the repetitive regression cases later."

Don't say you'll do manual testing only until something better comes along, and don't claim automation skills you can't show in a technical round.

Give real habits, not just "I'm patient." "I follow the test case steps exactly rather than from memory, and I mark results as I go, not at the end. I take short breaks between long runs and switch between modules so I don't stop noticing details. While running regression I also watch for anything unusual outside the steps, like a slow page or a changed label, and note it. When I see the same cases failing to find anything for months, I suggest reviewing or automating them."

The last point shows you think about improving the work, which interviewers value.

Use STAR and show you relied on facts, not ego. "A developer rejected my bug as working as designed (situation). I needed to know whether the behaviour was really intended (task). I checked the story's acceptance criteria and the requirement document, showed him the line it contradicted, and when it was still unclear, we asked the product owner together instead of arguing in comments (action). The product owner confirmed it was a bug, it was fixed, and the acceptance criterion was reworded so it couldn't be misread again (result)."

End by showing you kept a good working relationship with the developer.

Answer honestly, and show you understand why it happens. "Yes, I understand that releases sometimes need extra hours, and that working with clients in other time zones can mean shifted timings. I'm comfortable with that when it's needed, and I'll plan my work so that testing doesn't pile up at the end in the first place." If you have a real constraint, such as travel or a family commitment, mention it politely and ask how often it happens.

Agreeing to everything and then struggling later is worse than a clear, honest answer now.

Talk about what you're moving towards, not what you're running from. "I've spent [two years] testing [domain] applications, and I've learnt a lot about test design and working in Scrum teams. I'm now looking for [bigger or more complex products, exposure to API and automation testing, a product company], and this role offers that." Keep it short and true.

Never criticise your manager, team or company, even if you had problems: interviewers assume you'll say the same about them. If the reason is salary or relocation, you can say so briefly and calmly.