Manual Testing Interview Questions and Answers: 60 Questions from Easy to Hard
This guide is for freshers in India preparing for their first QA or software testing job, and for manual testers with one to ten years of experience preparing for a switch. It has 60 questions with answers in three levels: easy covers the basics every fresher is asked, medium covers real project work such as test design techniques, API checks, JIRA and agile, and hard covers test strategy, risk, metrics and release decisions. The answers are written the way a strong candidate would say them, with examples from everyday Indian apps such as UPI payments and OTP logins. Read a question, answer it aloud first, then compare with the answer, and take the mock test to check yourself against the clock.
- 60 questions, 3 levels
- Updated
- CoreHRx Jobs
What manual testing interviews cover
- Basics: SDLC and STLC, verification and validation, the levels of testing (unit, integration, system, acceptance) and the main types, such as functional, non-functional, smoke, sanity and regression.
- Test design techniques: equivalence partitioning, boundary value analysis, decision tables, state transition and pairwise testing, usually asked as a small field or business rule on the spot.
- Writing skills: test scenarios, test cases and bug reports, with severity, priority and the defect life cycle.
- Process: test plans, entry and exit criteria, traceability, the tester's role in Scrum, JIRA workflows and test metrics.
- For two years and more: API testing with Postman or curl, risk-based testing, estimation, and how you handled real release pressure.
How to prepare (freshers and experienced)
- Freshers: pick an app you use every day, such as a food delivery or bus booking app, and write 20 test cases and five bug reports for one of its screens. Interviewers often ask you to test a screen or an object on the spot.
- Practise each test design technique on simple fields and rules until you can list the partitions, boundary values or decision-table rules in about a minute.
- Learn Postman basics: send GET and POST requests to a public practice API, read the status codes and check the JSON body against what you expected.
- Experienced testers: prepare two or three real stories with numbers, such as a bug that would have cost money, a regression suite you cut down, or a process you improved.
- Learn JIRA well enough to explain your team's bug workflow, write a simple JQL filter and walk through your project's test process from requirement to release.
Interview-day tips and common mistakes
- When asked to test a pen, a lift or a login page, ask a few clarifying questions first (who uses it, what are the rules), then group your tests into functional, negative, non-functional and usability.
- Do not mix up severity and priority, or smoke and sanity testing. Have one clear example ready for each.
- Never say that testing proves software has no bugs. Say that it reduces risk and gives the team facts for a release decision.
- Talk about the user and business impact of a bug, not only the steps to reproduce it.
- If you do not know a term, say so and explain how you would handle the situation, instead of guessing a definition.
Manual Testing interview questions: Easy questions (freshers)
20 questions1. What is software testing, and why do companies need testers if developers already test their own code?
Software testing is checking a product against what it is supposed to do, and against what users really need, so that problems are found before customers find them. Developers do test their code, but they test what they meant to build and tend to miss what they never thought of. A tester brings an independent view: unclear requirements, unusual inputs, other devices and complete flows across modules. Testing cannot prove there are no bugs; it reduces risk and gives the team facts to decide whether to release.
2. What is the difference between verification and validation?
Verification asks whether we are building the product right: does each piece of work match its specification? It is mostly done without running the software, through reviews of requirements, designs, code and test cases. Validation asks whether we are building the right product: does the running software meet the user's real need? It is done by executing the software, as in system testing and UAT. Finding in a review that the screen design says an OTP is valid for 10 minutes while the spec says 5 is verification; a shop owner finding billing too slow at the counter is validation.
3. Explain the difference between an error, a defect and a failure.
An error is a human mistake, such as a developer misreading a requirement or typing the wrong condition. That mistake can leave a defect (also called a bug or fault) in the code, a document or a configuration. A failure is what you observe when the defective part runs and the system behaves differently from what is expected. Example: a developer types > instead of >= (error), the code rejects anyone aged exactly 18 (defect), and the sign-up page tells an 18-year-old Not eligible (failure). A defect can sit unnoticed for years if its code path never runs.
4. What is the SDLC, and at which stage should a tester get involved?
The Software Development Life Cycle is the set of stages a product goes through: requirements, design, development, testing, deployment and maintenance. Models arrange them differently: Waterfall runs them one after another, the V-model pairs each build stage with a matching test level, and Agile repeats all of them in short sprints. A tester should join at the requirements stage, not only at the testing stage, because a gap caught in a requirement review costs one meeting, while the same gap found after release costs a fix, a retest and unhappy customers.
5. What is the STLC, and what are its phases?
The Software Testing Life Cycle is the order of testing activities within a project. Most teams describe six phases: requirement analysis (what is testable, what is unclear), test planning (scope, approach, effort, schedule), test case development (cases, data, traceability), test environment setup, test execution (run tests, log defects, retest), and test closure (summary report, metrics, lessons learned). Each phase has entry and exit criteria; for example, execution starts only after the build passes a smoke test. In Agile the phases overlap inside each sprint, but the activities stay.
6. What are the levels of testing?
There are four common levels. Unit testing checks the smallest pieces, such as one function, and is usually done by developers. Integration testing checks that modules or services work together, for example that the cart passes the right amount to the payment service. System testing checks the complete application against the requirements in an environment close to production; most QA effort goes here. Acceptance testing checks whether the business or customer is ready to accept the product. Each level finds different kinds of bugs, so passing one level does not replace the next.
7. What is the difference between functional and non-functional testing?
Functional testing checks what the system does: for a given input, is the output or behaviour correct as per the requirement? Login, adding to cart and generating an invoice are examples. Non-functional testing checks how well it does it: performance, load, security, usability, accessibility, compatibility and reliability. A fund transfer that moves the right amount passes a functional test; if it takes 40 seconds when thousands of users log in on salary day, it fails a non-functional one. Non-functional needs are often left unstated, so testers should ask for real numbers.
8. What are black-box, white-box and grey-box testing?
In black-box testing you test through inputs and outputs without looking at the code, working from the requirements; most manual testing is black-box. In white-box testing you design tests from the internal structure, such as making sure every branch of a function runs, which developers usually do. Grey-box testing sits in between: you test from the outside but use some inside knowledge, such as the database tables, API calls or logs. A manual tester who places an order and then checks that the correct row appeared in the orders table is doing grey-box testing.
9. What is a test case, and what fields should a well-written one have?
A test case is a set of preconditions, inputs, steps and an expected result that checks one specific condition. Useful fields are a unique ID, a clear title, preconditions, test data, numbered steps, the expected result, the actual result and status, priority and a link to the requirement. The expected result matters most: it must be exact enough that two testers would mark the same pass or fail. A common mistake is writing "Login should work" as the expected result, which nobody can judge. Keep one main check per case, so a failure points to one cause.
ID : TC_LOGIN_007
Title : Login fails with a wrong password
Precondition : User 9876500011 exists and is active
Test data : Mobile 9876500011, password Wrong@123
Steps : 1. Open the login page
2. Enter the mobile number and password
3. Tap Login
Expected : "Incorrect mobile number or password" is shown;
user stays on the login page; no session created
Actual/Status : (filled in during execution)
Priority : High
Req ref : REQ-AUTH-0310. What is the difference between a test scenario and a test case?
A test scenario is a one-line statement of what to test, such as "Check that a user can reset the password with an OTP". A test case is a detailed, step-by-step check under that scenario, with exact data and an expected result. One scenario usually becomes several cases: a valid OTP, an expired OTP, a wrong OTP three times, a resent OTP and so on. Scenarios are quick to write and good for reviewing coverage early; detailed cases are needed when work is handed over, when an audit needs evidence, or when a new team member must run them exactly.
11. What is equivalence partitioning? Apply it to an age field that accepts 18 to 60.
Equivalence partitioning splits the possible inputs into groups that the system should treat the same way, then tests one value from each group, on the idea that if 35 is accepted, 36 will be too. For a field that accepts whole numbers from 18 to 60 there are three numeric partitions: 17 and below, 18 to 60, and 61 and above, plus invalid types such as letters or a blank. That is four tests instead of hundreds. Pick a value well inside each partition; the edges are covered by boundary value analysis. Test invalid inputs one at a time, so each rejection has a single cause.
Age field: accepts whole numbers 18 to 60
Partition Range Valid? Sample value
P1 below range 17 and less No 12
P2 inside range 18 to 60 Yes 35
P3 above range 61 and more No 70
P4 not a number letters, blank No abc12. What is boundary value analysis? Which values would you test for the same 18 to 60 age field?
Boundary value analysis tests the edges of each partition, because off-by-one mistakes, such as > typed instead of >=, live there. For a field that accepts 18 to 60, the two-value approach tests each boundary and its nearest neighbour outside it: 17, 18, 60 and 61. The three-value approach also adds the neighbour just inside: 17, 18, 19, 59, 60 and 61. Expected: 17 and 61 are rejected, the rest accepted. Always use the field's smallest step: for an amount in rupees and paise, the neighbours of Rs 500.00 are Rs 499.99 and Rs 500.01.
Age field: accepts whole numbers 18 to 60
Two-value BVA : 17, 18, 60, 61
Three-value BVA : 17, 18, 19, 59, 60, 61
Expected : 17 and 61 rejected, all others accepted13. What is the difference between positive and negative testing? Give examples for a mobile number field.
Positive testing checks that the system does the right thing with valid input. Negative testing checks that it handles invalid input or wrong actions safely: a clear message, no crash and no bad data saved. For an Indian mobile number field, positive tests are a valid 10-digit number such as 9876543210, and the same number with +91 if the requirement allows it. Negative tests are 9 and 11 digits, letters, spaces, special characters and a blank field. Negative tests often find more bugs, because developers usually code the happy path first.
14. What is the difference between severity and priority? Give an example of high severity with low priority, and the reverse.
Severity is how badly a defect affects the system; priority is how soon it must be fixed. The tester usually proposes severity from the technical impact, and the product owner or lead sets priority from business need. High severity, low priority: the app crashes while exporting a report for a financial year ten years ago, which one internal user opens once a year. Low severity, high priority: the brand name is misspelt on the home page banner a day before a big sale. A common mistake is treating the two as the same thing and marking everything critical.
15. Explain the defect life cycle.
The defect life cycle is the set of states a bug moves through from logging to closure. The tester logs it as New, a lead assigns it to a developer, and it is Open while the fix is made, then Fixed when a build with the fix is ready. The tester retests it: if the fix works it becomes Verified and then Closed; if not, it is Reopened and goes back to the developer. A bug can also leave early as Rejected, Duplicate, Deferred to a later release or Cannot reproduce. State names differ between tools and companies, so learn your team's workflow on day one.
New -> Assigned -> Open (in progress) -> Fixed
-> Ready for retest -> Verified -> Closed
Retest fails : Ready for retest -> Reopened -> Assigned
Early exits : Rejected, Duplicate, Deferred, Cannot reproduce16. What makes a good bug report?
A good bug report lets a developer reproduce the problem without asking you anything. It has a short, specific title that says what fails and where, the environment and build number, exact steps with test data, the expected result, the actual result, and evidence such as a screenshot, a screen recording or a log. Say how often it happens if it is not every time. Report one problem per bug, keep the tone factual and avoid guesses such as "the API is broken" unless you checked. A vague title like "Checkout not working" wastes triage time and often gets the bug rejected.
Title : Checkout - Pay button stays disabled after a valid
coupon is applied (Android 14, app v4.2.1)
Env : Staging, Android 14 phone with 4 GB RAM, Wi-Fi
Steps : 1. Log in as test user 9000011122
2. Add any item over Rs 500 to the cart
3. Apply coupon SAVE50 at checkout
Expected : Total drops by Rs 50 and Pay is enabled
Actual : Total drops by Rs 50 but Pay stays disabled
Repeats : 5 out of 5 tries
Severity : High Priority : High
Attach : screen recording, app log from 14:32 IST17. What is the difference between smoke testing and sanity testing?
Smoke testing is a quick, broad check of a new build's most important flows, such as app launch, login, search and checkout, to decide whether the build is stable enough for detailed testing. If smoke fails, the build goes back and nobody wastes a day on it. Sanity testing is a quick, narrow check after a small change or bug fix, to confirm that the specific area now works and nothing obvious around it broke. Think of smoke as wide and shallow and sanity as narrow and focused. Companies use the two terms loosely, so confirm what your team means.
18. What is the difference between retesting and regression testing?
Retesting means running the exact test that failed, after the fix, to confirm the defect is gone. Regression testing means re-running a wider set of tests to confirm that the fix or a new change did not break something that used to work. If a developer fixes a wrong tax total on invoices, re-running that invoice case is retesting; re-running checkout, discounts, refunds and reports that share the same tax calculation is regression. Retesting covers only the failed cases, while regression is needed after every change, which is why regression suites are automated first.
19. What is user acceptance testing, and how are alpha and beta testing different?
User acceptance testing (UAT) is the final level, where business users or the customer check that the system supports their real work and decide whether to accept it. It uses real-life scenarios rather than every edge case and usually starts after system testing passes. Alpha testing is done by internal people, such as staff outside the project team, at the developer's site or in a controlled environment. Beta testing gives the product to a limited group of real users in their own setting, such as a beta version of an app, to collect feedback before the full release.
20. Why is exhaustive testing impossible, and what do testers do instead?
Exhaustive testing means trying every possible input and every combination, and for real software that number is far too large. A password field that takes 8 characters from 62 letters and digits alone has 62 to the power 8, about 218 trillion, values; at one test per second that is about 6.9 million years, before any other field. So testers choose tests by risk and by technique: partitions and boundaries for inputs, decision tables for rules, pairwise for configurations, and the flows customers use most. The aim is enough confidence to release, not proof of zero bugs.
Ready to check yourself? Take the free Manual Testing mock test
Manual Testing interview questions: Medium questions (1-3 years)
20 questions21. How do you use a decision table? Show it for a loan pre-approval rule with three conditions.
A decision table lists every combination of conditions with the action expected for each, so no combination is forgotten. Three yes-or-no conditions give 2 x 2 x 2 = 8 rules. In the assumed rule, missing KYC means ask for KYC whatever the score and income, so those four rules collapse into one column with dashes for the other two conditions. The four KYC-complete rules all lead to different actions, so they stay. That leaves five test cases, R1 to R5. The table also exposes gaps: if nobody can say what a low score with high income should do, you found a requirement question before any code.
Assumed rule of the bank (example only)
Conditions R1 R2 R3 R4 R5
KYC complete N Y Y Y Y
Credit score >= 750 - Y Y N N
Income >= Rs 40,000 - Y N Y N
Actions
Ask for KYC X
Approve full limit X
Approve lower limit X
Manual review X
Reject X
(- = does not matter; R1 stands for 4 of the 8 rules)22. What is state transition testing? Apply it to a PIN screen that locks the card after three wrong attempts.
State transition testing models a feature as states, the events that move it between them and the expected result of each move, and then tests those moves. Here the states are S0, S1 and S2 (0, 1 or 2 wrong tries), Locked and Access. Covering all six moves out of S0, S1 and S2 needs at least four tests, because each of the three correct-PIN moves and the third wrong PIN ends a test: T1 to T4 in the table. Then add negative tests: a correct PIN on a locked card must still be refused, and check that the wrong-try count resets after a success if the requirement says so.
State Correct PIN Wrong PIN
S0 (0 wrong) Access S1
S1 (1 wrong) Access S2
S2 (2 wrong) Access Locked
Locked Refused Refused
Minimum tests to cover the 6 moves out of S0, S1, S2:
T1: correct
T2: wrong, correct
T3: wrong, wrong, correct
T4: wrong, wrong, wrong23. Your app must work on Android, iOS and web, in English, Hindi and Tamil, with UPI, card and net banking. How do you cover the combinations without testing all of them?
All combinations would be 3 x 3 x 3 = 27 runs. Pairwise testing picks a smaller set in which every pair of values from any two parameters appears together at least once, because most configuration bugs come from a single value or from two values interacting. For three parameters with three values each, 9 runs are enough, and 9 is also the minimum, since Platform and Language alone form 9 pairs. A table like this can be built by hand or with a pairwise tool. Then add the combinations that carry the most users or past bugs, such as Android with Hindi and UPI.
Run Platform Language Payment
1 Android English UPI
2 Android Hindi Card
3 Android Tamil Net banking
4 iOS English Card
5 iOS Hindi Net banking
6 iOS Tamil UPI
7 Web English Net banking
8 Web Hindi UPI
9 Web Tamil Card24. What goes into a test plan?
A test plan is the agreement on how a release will be tested: what, how, by whom, with what and by when. The key sections are scope (including what is out of scope), approach, entry and exit criteria, environments and data, roles, schedule, risks and deliverables. The out-of-scope list and the risks matter most, because they record decisions that someone may question after release. Keep the plan short and alive: a two-page plan that is updated when scope changes is worth more than a 30-page template copied from the last project that nobody reads.
1. Scope: features in scope and out of scope
2. Approach: levels, types, techniques, manual vs automated
3. Entry, exit, suspension and resumption criteria
4. Environments, devices and test data
5. Roles and responsibilities
6. Schedule and effort estimate
7. Risks and how each is handled
8. Deliverables: test cases, defect reports, summary report
9. Defect process: tool, severity definitions, triage25. What are entry and exit criteria, and how do you decide when to stop testing?
Entry criteria are conditions that must be true before a phase starts, such as requirements signed off, the build deployed, smoke passed and test data ready. Exit criteria say when the phase is complete, such as all high-priority cases executed, no open critical or high defects, and the remaining defects reviewed and accepted by the product owner. You never stop because no bugs are left; you stop when the exit criteria are met, or when the remaining risk is known and the business accepts it. Also agree suspension criteria, such as pausing when one blocker stops most of the tests.
26. What is a requirement traceability matrix, and how does it help?
A requirement traceability matrix maps each requirement to the test cases that cover it and, during execution, to their results and defects. It answers three questions quickly: is every requirement tested, which requirements are hit by a failed test, and which tests must be rerun when a requirement changes. In the example, REQ-PAY-03 has no test case, a gap you can raise before execution starts. Keep the matrix in your test management tool or as links in JIRA rather than in a separate spreadsheet that goes out of date after the first change request.
Req ID Requirement Test cases Status
REQ-PAY-01 Pay by UPI TC_101, TC_102 Pass
REQ-PAY-02 Pay by card with OTP TC_103-TC_106 1 failed
REQ-PAY-03 Refund in 5-7 days - Not covered27. How would you test the login page of a mobile banking app that uses a mobile number and an OTP?
Start with the main flow: a valid number and OTP lead to the home screen. Then inputs: 10-digit validation, a blank field, an unregistered number. Then OTP rules: wrong OTP, expired OTP, reused OTP, the resend timer, the attempt limit, auto-read on Android, and whether an older OTP still works after a resend. Then security: the OTP never appears in an API response or log, repeated requests are limited, the session times out and logout ends it, even with the back button. Then non-functional checks: slow network, app sent to background, screen reader labels.
28. A hotfix must go live tonight and you have two hours for regression. How do you choose what to test?
Use impact and risk, not the full suite. First, retest the fix itself. Second, ask the developer which modules, APIs and shared functions changed, and test those plus the flows that call them. Third, run the critical-path smoke set: login, the main money or order flow and anything regulatory. Fourth, add areas with a history of bugs. Record what you skipped and tell the release owner in writing, so the decision about the remaining risk is shared. Afterwards, run the full regression in the next cycle, and keep a tagged quick-regression set ready for the next emergency.
29. A developer marks your bug Cannot reproduce. What do you do?
First reproduce it again yourself in a fresh session, because the bug may depend on data or state you did not note. Then compare environments: build number, device, OS version, browser, user role, feature flags, test data and network. Add what was missing to the report: exact data, timestamps, a screen recording, and logs or the request and response from the browser developer tools. If it is intermittent, say how often, such as 3 out of 10 tries. Offer to show it on a call. Do not simply reopen it with no new information; that turns a bug into an argument.
30. How do you handle a bug that is rejected as working as designed, marked duplicate, or deferred?
For working as designed, check the requirement or ask the product owner. If the design really is what users want, close it; if the design seems wrong for users, raise it as a change request or usability issue instead of reopening. For duplicate, confirm that the other ticket has the same root cause, not just the same screen, link them and add any new steps or data to the original. For deferred, make sure the severity, the workaround and the target release are recorded and that the product owner agreed. Review deferred bugs before each release so they are not forgotten.
31. What does a tester do during a Scrum sprint?
In sprint planning the tester questions each story, helps make the acceptance criteria testable and estimates test effort with the team. During the sprint they write scenarios early, test each story as soon as it is ready instead of at the end, and work closely with developers, often in a three amigos discussion with the product owner and a developer before coding. They log bugs, retest and keep the regression suite current. In the review and retrospective they share quality observations. The tester does not own quality alone: the whole team does, and the definition of done includes testing.
32. How do you turn a user story into testable acceptance criteria? Show the Given-When-Then style.
Acceptance criteria are the conditions a story must meet to be accepted, written so that each can be checked as pass or fail. The Given-When-Then style states the starting situation, the action and the expected result, which removes vague words such as fast or user-friendly. In the example, the second scenario uses a cart of Rs 998, just below the Rs 999 minimum, so a boundary test is already built in. Write the criteria with the product owner and a developer before coding starts; they become your first test cases, and the automated checks too if the team uses a BDD tool such as Cucumber.
Feature: Apply coupon at checkout
Scenario: Valid coupon on an eligible cart
Given the cart total is Rs 1,200
And coupon FEST100 is active with a minimum cart of Rs 999
When the user applies coupon FEST100
Then the payable amount is Rs 1,100
And the message "Coupon applied" is shown
Scenario: Cart just below the minimum
Given the cart total is Rs 998
When the user applies coupon FEST100
Then the coupon is refused
And the message "Add Rs 1 more to use this coupon" is shown33. As a manual tester, how do you test a REST API, and what do you check in each response?
Send requests with a tool such as Postman or curl, using the API documentation as the specification. In each response check the status code, the body values and their types against the schema, required headers such as Content-Type, and the response time. Then check the side effect: was the order really created with qty 2, as seen in the app or the database? Test the negative cases too: a missing or expired token, wrong data types, missing required fields, a qty of 0 or -1, and an item_id that does not exist. Each should return a clear 4xx error, never a 500 or a stack trace.
curl -i -X POST https://api.example.com/v1/orders \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{"item_id": 4521, "qty": 2}'
HTTP/1.1 201 Created
Content-Type: application/json
{"order_id": 98012, "item_id": 4521,
"qty": 2, "status": "PLACED"}34. An API returns 200 OK with an error message in the body when the token is missing. Is that a bug, and which status codes should you expect in common cases?
Usually yes: the status code is part of the contract, and apps, monitoring and retry logic rely on it. A missing or invalid token should give 401 Unauthorized. A logged-in user without permission, such as an employee calling an admin report, should get 403 Forbidden. Bad input gives 400 Bad Request, or 422 if the team uses it for validation errors; an unknown record gives 404 Not Found; a duplicate gives 409 Conflict. A 500 Internal Server Error caused by bad input is always a bug, because the server should validate input. Check the API spec, since teams set their own conventions.
35. What do GET, POST, PUT, PATCH and DELETE mean, and why does idempotency matter when testing a payment API?
GET reads data and must not change anything. POST creates a resource or triggers an action. PUT replaces a resource, PATCH changes part of it and DELETE removes it. GET, PUT and DELETE are idempotent: sending the same request twice leaves the server in the same state as sending it once. POST is not, so if a payment request times out and the app retries, the customer may be charged twice. Test this on purpose: send the same payment request twice, double-tap Pay and cut the network mid-request. A well-built API accepts an idempotency key and returns the first result for a repeat.
36. How do you track bugs in JIRA? Write a JQL filter for the open high-priority bugs in the current sprint.
In JIRA a bug is an issue of type Bug that moves through a workflow, such as To Do, In Progress, Ready for QA and Done, and fields like priority, component, fix version, labels and links to stories make it searchable. JQL (Jira Query Language) builds the filters behind dashboards and stand-ups. The filter shown lists unfinished bugs of Highest or High priority in project PAY's open sprint, most urgent first. Using statusCategory instead of a list of status names keeps it working when someone adds a status to the workflow. Save the filter and share it with the team.
project = PAY AND issuetype = Bug
AND sprint in openSprints()
AND priority in (Highest, High)
AND statusCategory != Done
ORDER BY priority DESC, created ASC37. Which test execution metrics would you report daily, and how do you calculate them?
Report planned, executed, passed, failed, blocked and not run, plus open defects by severity. With the numbers shown, execution is 216 of 240, which is 90%, and the pass rate is 91.7% of executed cases but only 82.5% of planned ones, so always state the denominator. The 10 blocked cases need an owner and a reason, such as a missing payment sandbox, because they hide risk. A trend over several days says more than one snapshot: a pass rate that stays flat while new defects keep arriving tells you the build is not stabilising.
Planned test cases : 240
Executed : 216 (198 passed, 18 failed)
Not executed : 24 (10 blocked, 14 not run yet)
Execution % = 216 / 240 x 100 = 90.0
Pass % of executed = 198 / 216 x 100 = 91.7
Pass % of planned = 198 / 240 x 100 = 82.538. What are the approaches to integration testing, and what are stubs and drivers?
Big bang integrates all modules at once and tests them together; it is simple, but failures are hard to locate. Incremental approaches add modules step by step. Top-down starts with the upper modules, such as the UI and the order service, and replaces lower modules that are not ready with stubs: simple stand-ins that return fixed answers. Bottom-up starts with the lower modules, such as a tax calculator, and uses drivers: small callers that feed them input. Sandwich combines both. In service-based systems the same idea appears as mock servers standing in for a payment or SMS provider.
39. What is exploratory testing, and how do you keep it disciplined rather than random clicking?
Exploratory testing means learning the product, designing tests and running them at the same time, using each result to choose the next test. It finds bugs that scripted cases miss, because a person follows hunches and odd behaviour. To keep it disciplined, use session-based testing: a written charter that says what to explore and why, a fixed time box, and notes on what was tried, bugs found and open questions, followed by a short debrief with the lead. It works best alongside scripted tests, especially for new features, unclear requirements and areas that recently produced bugs.
Charter : Explore bulk upload of employee records with messy
CSV files to find data-handling bugs
Time box : 60 minutes
Ideas : blank rows, duplicate employee IDs, Hindi names,
dates as 05/11/2025 and 2025-11-05, a 10,000-row file
Notes : what was tried, bugs found, questions, gaps left40. How do you test the usability of a screen, and what problems do you look for?
Usability testing checks whether real users can finish their tasks easily, quickly and without errors. The best evidence comes from watching five or so target users do real tasks, such as a shop owner creating a GST invoice, while you take notes and do not help. As a tester you can also review the screen against common usability principles: clear labels, consistent buttons, error messages that say how to fix the problem, no data lost on a back press, readable text on small phones and the languages users speak. Report each issue with the task, what the user struggled with and a suggestion.
Ready to check yourself? Take the free Manual Testing mock test
Manual Testing interview questions: Hard questions (experienced)
20 questions41. What is the difference between a test strategy and a test plan? How would you write a strategy for a new product?
A test strategy is the long-lived approach for a product or organisation: which levels and types of testing are used, how risk decides depth, what is automated, environments, tools, defect handling and quality gates. A test plan applies that strategy to one release or project, with its scope, dates, people and specific risks. For a new product, start from business risk: which failure would hurt customers, money or reputation most? Then decide the test mix for each risk, the release gates and who owns what. Review it with engineering and product, and revise it when the architecture changes.
42. How do you do risk-based testing? Show how you would rank the features of an e-commerce app.
Risk-based testing spends effort where failure is most likely and would cost most. Score each feature's likelihood of failure from complexity, size of change and bug history, and its impact from money, users affected, legal exposure and reputation. Multiplying the two gives a score that ranks features: UPI payment at 20 gets the deepest testing and profile photo at 2 a light check. Use the ranking to set test depth, order and regression priority, not to skip testing altogether. Agree the scores with product and development, and score again each release, because risk moves with every change.
Feature Likelihood (1-5) Impact (1-5) Risk score
UPI payment 4 5 20
OTP login 3 5 15
Product search 3 3 9
Order history 2 3 6
Profile photo 2 1 243. How do you estimate testing effort? Explain three-point estimation with an example.
First break the work into tasks, such as test design, data and environment setup, execution cycles, retesting and reporting, and estimate each one. Three-point estimation asks for an optimistic, a most likely and a pessimistic figure and combines them; the PERT formula weights the most likely value four times. With 6, 9 and 18 days the estimate is 10 days, and the standard deviation of 2 days lets you give a range, such as 10 days with 12 as a safer commitment. Always state the assumptions, such as two retest cycles and a stable build, so the estimate can be revised openly when one breaks.
Optimistic (O) = 6 days
Most likely (M) = 9 days
Pessimistic (P) = 18 days
Estimate E = (O + 4M + P) / 6 = (6 + 36 + 18) / 6 = 10 days
Std. dev. = (P - O) / 6 = 12 / 6 = 2 days44. What is defect removal efficiency, and what does the leakage figure tell you?
Defect removal efficiency (DRE) is the share of all known defects that were found before release. With 152 defects found in system testing, 28 in UAT and 20 in the first 90 days of production, DRE is 180 of 200, or 90%, and leakage to production is 10%. System testing alone caught 76%, so it is worth asking why UAT found 28 that QA did not. Fix the production window, such as 90 days, so releases can be compared fairly. Look at what leaked, not only how much: one payment bug matters more than ten typos. Use the figure to improve the process, never to blame people.
Defects found in system testing : 152
Defects found in UAT : 28
Defects found in production (90 days) : 20
Total : 200
DRE before release = (152 + 28) / 200 x 100 = 90%
Leakage to prod = 20 / 200 x 100 = 10%
System testing DRE = 152 / 200 x 100 = 76%45. Which QA metrics can mislead management, and what would you report instead?
Counts without context mislead. Bugs found per tester rewards logging trivial bugs and splitting one bug into five. Test cases executed per day rewards shallow cases. A 98% pass rate means little if the 2% that failed are in payments, or if the suite does not cover the new feature. Full requirement coverage only says each requirement has a test, not that the tests are good. Report instead the coverage of critical flows, open defects by severity and age, and escaped defects with their causes. Pair every number with one line of interpretation, so readers do not draw the wrong conclusion.
46. A serious bug reached production. How do you run a root cause analysis, and what do you change afterwards?
First contain it: reproduce it, test the hotfix and check whether other data is affected. Then look for causes without blame, asking why repeatedly: why did the code fail, why did review miss it, why did no test cover it? The answers usually point at the process, such as a requirement that never mentioned partial refunds, test data with no long names, or a regression set that skipped a shared module. Fix at the right level: add the missing test, update the checklist or requirement template, add a monitoring alert. Track escaped defects by cause, so you fix patterns, not single incidents.
47. The release is tomorrow and three high-severity bugs are still open. What do you recommend?
A tester's job is to give clear facts and a recommendation, not to make the business decision alone. For each bug state the impact, who is affected, the workaround and the fix estimate. If a bug can lose money or data, expose personal data or block a main flow for many users, recommend no-go, or a release with that feature switched off. If the impact is limited and a workaround exists, going live with known issues can be fine, with the product owner's written sign-off, a note for support and a fix date. Also report any regression still pending, because unknown risk is worse than known bugs.
48. How would you test a UPI payment flow in an e-commerce app?
Cover the money states, not just the happy path. Success, failure and cancel in the UPI app are the basics. The hard cases are a pending status, a timeout after the bank has debited the money, the app killed or offline while the UPI app is open, a double tap on Pay, and the payment callback arriving late or twice. In each case check that the order state, the payment record and the customer's message agree, that no duplicate order or charge is created, and that a refund starts when an order fails after a debit. Check the reconciliation report too, and test in the gateway's sandbox.
49. How can a manual tester find concurrency bugs, such as two people booking the last seat on a bus?
Create the race on purpose. Set up a trip with one seat left, open the booking on two browsers or devices with different users, reach the Pay step on both and submit as close together as you can. Repeat it several times, because races do not show up every time. Expected: one booking succeeds and the other gets a clear sold-out message and no charge, or an automatic refund if money was taken. Also try the same user in two tabs, a double click, the back button after payment and an expired seat hold. Check the database or admin panel for double bookings, not just the screen.
50. An order can be Placed, Paid, Shipped, Delivered or Cancelled. How do you design state-based tests for it, including invalid moves?
Draw the state model and list each valid transition; here there are 5. Testing each once gives transition coverage, and testing each valid two-step sequence, here 3, catches bugs that depend on the previous state. The bigger risk is invalid moves: with 5 states there are 20 possible moves between different states, so 15 must be refused, such as Delivered to Cancelled or Shipped back to Paid. The UI usually hides those buttons, so try them through the API, an admin screen or two tabs left at different steps, and check that a refused move changes nothing, including stock and refunds.
Valid transitions (5):
Placed -> Paid Placed -> Cancelled
Paid -> Shipped Paid -> Cancelled
Shipped -> Delivered
Valid two-step sequences (3):
Placed -> Paid -> Shipped
Placed -> Paid -> Cancelled
Paid -> Shipped -> Delivered
Moves between different states: 5 x 4 = 20, so 15 are invalid51. How do you test integration in a system of many microservices when some services are owned by other teams?
Test in layers. Each service's API is tested against its contract: the fields, types and errors its consumers depend on. Contract tests, written from the consumer's expectations and run in the provider's pipeline, catch a breaking change before it is deployed. Mock servers stand in for unstable or costly third parties, such as an SMS provider. On top of that, keep a small set of end-to-end tests through the real services for the critical flows. Watch asynchronous parts: a message queue can deliver late, twice or out of order, so check the final state, not only the first response.
52. How do you decide which tests to automate and which to keep manual?
Automate tests that run often, have stable behaviour, matter to the business and are slow or error-prone by hand: regression of critical flows, API checks, data-heavy calculations and checks across many browsers. Keep manual the tests that need human judgment or change often: exploratory sessions, usability, a feature still being designed and one-off checks. Count the cost too: a test that runs twice a year and breaks with every UI change may never repay the effort of automating it. Automating a poor manual case only gives you a fast poor test, so review cases before you automate them.
53. What is static testing, and how do you review a requirement to find defects before any code exists?
Static testing finds defects without running the software, through reviews of requirements, designs, code and test cases, and through tools such as linters. In a requirement review, look for ambiguity, missing cases and contradictions. Ask what happens at the limits, what the error message says, who is allowed to do this and what happens on failure. For example, "Users can cancel an order before shipping" leaves open whether a partial cancel is allowed, when the refund is made and what happens if payment is still pending. Every question answered here is a bug that never gets coded.
54. The team wants to copy production data into the test environment. What are the risks, and what do you recommend?
Production data holds personal data such as names, phone numbers, PAN and bank details, and a test environment is seen by more people and protected less. A leak from staging is still a personal data breach under data protection law such as India's DPDP Act, 2023, and a test system may send real SMS or emails to customers. Recommend synthetic data where possible and, where real patterns are needed, a masked copy: fake but valid-looking names, phones and IDs, with formats and links kept so tests still work, and restricted access. Turn off outgoing messages in test and delete copies when done.
55. Your manual regression suite has grown to 1,800 cases and takes eight working days. How do you fix it?
Treat the suite as a product. Remove duplicates and cases for retired features, merge cases that check the same thing with trivial data changes, and rewrite the vague ones. Tag every case by module, priority and risk, so that you can build a one-day critical set, a three-day standard set and the full set for major releases. Move stable, repeated cases to automation with the developers, starting with the API layer. Use history: low-risk cases that have not found a bug in years can run less often. Review the suite every release so that it does not grow back.
56. Your team releases several times a week behind feature flags. How does testing change?
Testing moves earlier and continues after release. Each story is tested before it is merged, with quick automated regression in the pipeline, since there is no long test phase. With feature flags you test both states, on and off, and the switch itself: users in the middle of a flow when the flag changes, and the old path still working for users outside the rollout. Ask how a flag is turned off in an incident, and test that. After release, watch monitoring, error logs and support tickets for the rollout group, such as 5% of users. Push to remove old flags, since each adds paths to test.
57. What would you include in the test approach for a mobile app used across India?
Choose devices from your analytics, not the team's own phones: low-RAM Android phones, several Android versions, small screens, and older iPhones if iOS matters. Test on poor networks: switching between Wi-Fi and mobile data, slow connections, offline use and network loss in the middle of a payment. Test interruptions: calls, an OTP SMS arriving, the app moved to the background and battery savers killing it. Test languages, including long Hindi or Tamil labels and large font settings. Check installation, upgrade from the previous version with data kept, denied permissions and app size.
58. How do you test a web application for accessibility?
Accessibility testing checks that people with disabilities can use the product, for example with a screen reader, a keyboard only or screen zoom. Many teams test against WCAG 2.2 level AA. Manual checks matter most: do every task with the keyboard alone and check that focus is visible and in a logical order; use a screen reader such as NVDA or TalkBack and check that buttons and fields announce clear names; zoom to 200%; check text contrast; and make sure errors are not shown by colour alone. Automated scanners catch only part of the problems, so they support manual checks, not replace them.
59. How do you run a bug triage meeting, and how do you stop old bugs from piling up?
Triage is a short, regular meeting where QA, a developer lead and the product owner review new and disputed bugs: confirm each is valid, set severity and priority, assign an owner and a target release, or reject, merge or defer it with a reason. The tester comes prepared with clear reports and reproductions. To stop old bugs piling up, review an ageing filter like the one shown, which lists unfinished bugs older than 14 days, oldest first within each priority. Agree rules, such as high-priority bugs fixed within the sprint, and close bugs that no longer matter instead of carrying them forever.
project = PAY AND issuetype = Bug
AND statusCategory != Done
AND created <= -14d
ORDER BY priority DESC, created ASC60. You are the first QA hire at a 20-person startup with no testing process. What do you set up in your first 60 days?
Start by learning the product, the customers and where it breaks: read support tickets and recent incidents. Then add the basics in small steps: a bug workflow in the tool the team already uses, with clear severity definitions, a smoke checklist for every release and a regression list for the top revenue flows. Join story discussions so that acceptance criteria are written before coding. Add a staging environment and test data if missing. Show value early, then push for API automation with the developers. Avoid heavy templates: a process the team follows beats a perfect one it ignores.
Practice questions for November 2026
New every month3 questions from the Manual Testing mock test, the way they appear in it. A new set comes on the 1st of every month. Pick your answer, then open it.
-
Which statement best describes system testing?
- Testing only the interfaces between two modules, taking one pair of them at a time
- Testing one class in isolation, with mocks in place of all its dependencies
- Testing done by customers at their own site just before the final release
- Testing the complete, integrated application against its specified requirements
Show the answer
Answer: Testing the complete, integrated application against its specified requirements. System testing treats the whole integrated product as one system and checks it end to end against functional and non-functional requirements. Isolated classes are unit tests, module pairs are integration tests and customer checks are acceptance.
-
Which statement about severity and priority is true?
- Priority must always equal severity for every defect in the tracker
- Only a defect with high severity can ever be given a high priority
- They are independent: a defect can be high on one and low on the other
- Severity changes every sprint, but priority can never be changed
Show the answer
Answer: They are independent: a defect can be high on one and low on the other. Severity measures impact and priority measures urgency, and they often differ: a misspelt brand name is low severity but high priority. Both can also change as the release situation changes.
-
A product owner wants to skip testing a "small" story to fit it into the sprint. What is the best response?
- Agree at once, since product owners decide everything that happens in the sprint
- Explain the risk and agree a right-sized test effort
- Test it secretly after the sprint ends, without telling anyone in the team
- Refuse to test any other story in the sprint until this one has been dropped
Show the answer
Answer: Explain the risk and agree a right-sized test effort. Small changes can still break important flows. The tester can propose a light but real check based on risk, and make any accepted risk visible. Silent skipping and ultimatums both damage trust in the team.
Ready to apply?
Browse the open jobs on CoreHRx. Create a free profile once and apply with it.