Manual Testing Interview Questions and Answers

Answer

The first thing I do is refuse the framing. 'Login works' is a claim about one path, and testing is the activity of gathering evidence about whether the product behaves as intended and finding where it does not. So my first thirty minutes are spent building a model of the feature rather than clicking.

I ask three questions: what are the inputs, what are the states, and what is the blast radius. Inputs for a login screen are user identifier, password, an OTP maybe, remember me, and the hidden ones, device, session, network. States are logged out, logged in, locked after failed attempts, password expired, account deactivated, first time user.

Blast radius is what login touches downstream, session token, role based menus, deep links, analytics events. Then I do a ten minute smoke pass on the happy path to confirm the build is even testable, and spend the rest on negative and state cases: wrong password five times, correct password on the sixth attempt, back button after logout, two tabs logging in as different users, session behaviour after the token expires. The distinction I would state to the panel is verification versus validation.

Verification asks whether we built the thing per the specification, validation asks whether the thing solves the user's problem. A login screen can pass every written test case and still be wrong if it locks out users after three attempts in a market where people routinely fat finger passwords on a 5 inch screen. Follow up the panel usually asks: 'if it passed, would you say it is bug free?' The correct answer is no, testing shows the presence of defects, never their absence, and I would state what I did not cover.

Answer

A test scenario is a one line statement of what needs to be verified, written at the level of user intent. 'Verify that a user can pay a merchant using UPI.' It exists so that a business analyst or a client can read the coverage without drowning in detail, and it is the unit you count when you say 'we have 42 scenarios for the payments module'.

A test case is the executable expansion of a scenario: preconditions, test data, numbered steps, expected result, actual result, status. One scenario usually explodes into eight to twenty test cases because the scenario says nothing about a wrong UPI PIN, an amount above the daily limit, a bank server timeout or a duplicate submit. A test script, in manual testing vocabulary, is the step level instruction set, and in automation vocabulary it is the code that performs the same steps.

In most Indian service company templates the terms test case and test script are used loosely and the interviewer is checking whether you can still keep the hierarchy straight: scenario is what, test case is how with data, script is the mechanical sequence. The practical reason this matters is estimation and traceability. You map requirements to scenarios in the RTM, you map scenarios to cases for execution counts, and you report progress at case level because 'scenario 40 percent done' is meaningless.

Follow up you should expect: 'how many test cases would you write for this one scenario and why not more?' The answer is bounded by risk, I stop adding cases when a new case does not test a new equivalence class, a new boundary or a new state transition.

SCENARIO
  TS_PAY_01  Verify a user can pay a merchant via UPI

TEST CASES DERIVED FROM IT
  ID          Title                                   Type
  ==========  ======================================  ========
  TC_PAY_001  Pay 100 to a valid VPA, correct PIN     Positive
  TC_PAY_002  Pay 1 (minimum allowed amount)          Boundary
  TC_PAY_003  Pay 100000 (daily cap)                  Boundary
  TC_PAY_004  Pay 100001 (above cap)                  Negative
  TC_PAY_005  Wrong UPI PIN entered 3 times           Negative
  TC_PAY_006  Bank timeout mid transaction            Negative
  TC_PAY_007  Double tap on Pay button                Negative
  TC_PAY_008  Insufficient balance                    Negative

TEST SCRIPT (step level, TC_PAY_001)
  1. Launch app, log in as seeded user 9876543210
  2. Tap Pay > Enter UPI ID
  3. Enter merchant VPA test.merchant@icici
  4. Enter amount 100, tap Proceed
  5. Enter UPI PIN 1234, tap tick

Answer

The test that a case is well written is simple: hand it to someone who has never seen the product and see whether they can execute it and reach a confident pass or fail. That requires six things. First, a precondition block that states the exact starting state including the login used, the environment, the build number and any data setup, not 'user is logged in' but 'logged in as seeded user qa_buyer_01 on QA2, build 4.18.2, with an empty cart'.

Second, concrete test data written into the case, not 'enter a valid mobile number' but 'enter 9876543210'. Vague data is the single biggest cause of an unrepeatable case. Third, one action per step, numbered, in imperative voice.

Fourth, an expected result that is observable and specific: 'order status changes to Confirmed and a confirmation SMS is received on the registered number within 60 seconds', not 'order should be placed successfully'. Fifth, a stated postcondition or cleanup, because the next case in the suite often assumes a state. Sixth, a single verification intent per case, so the pass or fail is unambiguous.

If a case checks the discount calculation and the SMS content and the invoice PDF, a failure tells you nothing about which of the three broke. What I also add in practice is the negative expectation, what should NOT happen, because that is where testers silently disagree. Follow up you will get: 'your expected result says the order is placed, where do you verify it?' The strong answer names all three surfaces, UI, backend database row, and the downstream notification, so the case is verifying the outcome and not just the screen.

TEST CASE  TC_CHK_014
===============================================================
Module        Checkout > Coupon
Priority      High
Precondition  Logged in as qa_buyer_01 on QA2, build 4.18.2
              Cart has SKU SHOE_9981, MRP 2499, qty 1
              Coupon FIRST200 is active, min order 2000
Test Data     Coupon code: FIRST200

Steps
  1. Open Cart from the header
  2. Enter FIRST200 in the Apply Coupon field
  3. Tap Apply

Expected Result
  a. Discount row shows 'FIRST200 applied  200'
  b. Payable amount changes from 2499 to 2299
  c. Apply button is replaced by a Remove link
  d. No error toast appears

Postcondition  Coupon remains applied on page refresh
Negative check Coupon cannot be applied a second time

Answer

Smoke testing is a shallow and wide check that the build is stable enough to accept for testing at all. It is a fixed, documented, small suite, typically 20 to 40 cases covering the critical paths end to end: app launches, login works, search returns results, add to cart works, checkout reaches the payment page, logout works. If smoke fails, I reject the build and it goes back to dev, no further testing happens, and I log that as a build rejection because repeated rejections are a real quality signal to raise in the retrospective.

Sanity testing is narrow and deep, and it is not a fixed suite. It is the targeted check you do after a specific fix or a small change: dev says 'I fixed the GST rounding on invoices', so I sanity check invoices with the exact scenarios around GST rounding and its immediate neighbours. Sanity is usually unscripted or lightly scripted and it answers 'is this specific change sane enough to justify running the regression suite'.

So on release day the order is smoke first on the whole build, then sanity on the specific fixes in the release notes, then regression on the impacted areas, then the release candidate sign off. Two things interviewers push on. First, who runs smoke, and the honest answer in most Indian teams in 2026 is that smoke is the first suite that gets automated, so QA owns the suite but CI runs it on every build.

Second, they will ask whether smoke is a subset of regression. It usually is, the smoke suite is drawn from the highest priority regression cases, but its purpose is different: regression asks 'did we break something old', smoke asks 'is this build worth my afternoon'.

Answer

Retesting, also called confirmation testing, is running the exact failing steps from the defect on the build that claims the fix, using the same data and the same environment, to confirm the defect is gone. It is always planned, always on a specific build number, and it can never be automated away as a decision because someone has to confirm the reported symptom is actually the symptom that disappeared. Regression testing is running other cases around the change to confirm the fix did not break anything that used to work.

Both happen, in that order, and conflating them is a classic interview trip. Concretely: the defect says 'coupon FIRST200 not applied when cart has exactly 2000'. On build 5.2.1 I first reproduce the original steps precisely, then I widen slightly, 1999 and 2001, because a boundary fix very often shifts the boundary by one instead of fixing it.

If it passes I move the defect to Verified or Closed with the build number and a note on what I checked. If it still fails I reopen the same defect rather than raising a new one, and I add the new build number and the fresh evidence. Reopening matters because reopen counts are a metric that surfaces a dev or a requirement problem.

Then regression: coupons in general, cart totals, GST on the discounted amount, and the invoice, because the fix touched pricing. The follow up almost every panel asks is 'how much regression, you cannot run everything'. That is an impact analysis question, and I answer it with the changed module, its direct integrations, and any shared component the developer names in the commit or the pull request.

Answer

Severity is the technical impact on the system and is set by the tester. Priority is how urgently it must be fixed and is set by the product owner or a triage call, informed by the tester. They are independent axes, which is exactly why panels ask for cross combinations.

High severity and low priority: the app crashes when the device language is set to Kannada and the OS locale is a specific older Android build, crashing is severe but the affected user base is 0.2 percent, so it can wait a sprint. Another: a data loss bug in an admin bulk upload screen used by two internal users once a quarter. Low severity and high priority: the company logo on the login screen is the old pre rebrand logo, or the pricing page shows 'Rs 499' where the marketing campaign launching tomorrow promises 449.

Cosmetically trivial, but it is the first thing a customer sees or it creates a legal and trust problem, so it ships today. High severity and high priority is the obvious one, payment succeeds at the bank but the order is never created, money leaves the customer and there is no order. Low and low: a tooltip is misspelt on a settings page.

What the panel is really checking is whether you will fight for a low severity, high priority bug, because that is the one testers under report. I would also mention that in most JIRA setups these are two separate fields and QA is only allowed to edit severity, priority is changed in triage, which is why the argument has to be made verbally with evidence about user impact.

SEVERITY x PRIORITY MATRIX WITH REAL EXAMPLES
=================================================================
              HIGH PRIORITY                 LOW PRIORITY
  HIGH SEV    Payment debits but no order   App crashes only when
              is created. Money lost,       device locale is set to
              no record. Fix now.           Kannada on Android 9.
                                            Severe but 0.2% of users.

  LOW SEV     Login screen shows the old    Tooltip on Settings page
              pre rebrand logo the day      reads 'Notifcations'.
              the campaign launches.        Fix whenever.
              Trivial code, urgent optics.

WHO SETS WHAT
  Severity  set by QA, based on technical impact
  Priority  set by PO or triage call, based on business urgency

Answer

The canonical life cycle: New, when the tester logs it. Assigned, when the lead or triage routes it to a developer. Open, when the developer accepts it and starts work.

Fixed, when the code change is done and the developer marks it, usually with a target build. Pending Retest, when the fix is in a build available to QA. Retest, when the tester is actively confirming.

Verified, when the fix is confirmed. Closed, the terminal state. The branches are where the real answers live.

Rejected happens when the developer disagrees, usually as Not a Bug, Works as Designed, or Cannot Reproduce, and it goes back to the tester who either provides more evidence and reopens, or accepts and closes it as Not a Bug with a note. Duplicate is when the same defect already exists, and the correct handling is to link the two rather than silently close, because the duplicate often has better reproduction steps. Deferred means the team agrees it is a real defect but it will not be fixed in this release, and it must carry a target release and a reason, otherwise the deferred bucket becomes a graveyard.

Reopened is what a defect becomes when a retest fails, and the reopen count on a defect is a signal worth watching. Cannot Reproduce is technically a rejection but should trigger a joint session rather than a close, because it usually means an environment or data difference. The follow up to prepare for is 'what is the difference between Closed and Verified', and the answer is that Verified means QA confirmed the fix while Closed means the defect is administratively finished, which also covers defects closed as duplicate, deferred at end of life, or not a bug.

BUG LIFE CYCLE
===================================================================
  NEW
   |
   v
  ASSIGNED  >>>>>>>>>>>>>>>  DUPLICATE (link to original, close)
   |         >>>>>>>>>>>>>>  REJECTED  (Not a Bug / Works as Designed)
   |         >>>>>>>>>>>>>>  DEFERRED  (real, not this release)
   v
  OPEN  (dev accepts, work starts)
   |
   v
  FIXED  (code done, target build noted)
   |
   v
  PENDING RETEST
   |
   v
  RETEST  by QA on the stated build
   |            |
   | pass       | fail
   v            v
  VERIFIED     REOPENED  >>> back to ASSIGNED
   |
   v
  CLOSED

CANNOT REPRODUCE is a rejection, but the right move is a joint
session with the developer, not an immediate close.

Answer

Cannot Reproduce almost always means the report is missing environment or data context, and Works as Designed almost always means the report asserts a bug without citing what defines correct. A bounce proof report fixes both. It carries: a title that states the symptom, the condition and the impact in one line, so triage can prioritise without opening it.

Environment as a precise triple, build number, platform and version, and account, for example build 5.2.0 (1841), Android 14 on Redmi Note 13, user 9876543210 on QA2. Preconditions and exact test data, because 'a user with a saved card' hides that the card was an expired one. Numbered steps that start from app launch, not from step four of a flow you happened to already be in.

Actual result and expected result stated separately, with the source of the expectation named, the acceptance criterion from the user story, a line from the BRD, the behaviour of the previous release, or a screenshot of the design. Evidence: a screen recording is worth more than three screenshots for anything sequential, plus the request and response from the network tab or the relevant log lines with a timestamp, and the correlation id if the app exposes one. Reproducibility rate, four out of five attempts is a very different bug from one out of twenty.

Severity, module and the release you found it in. Add a 'first bad build' note when you know it, because that hands the developer a bisect range. The follow up: 'what if it is genuinely intermittent'. Then I say so explicitly, give the observed frequency, attach logs from a failing run, and describe what varied between passes and failures rather than pretending it is deterministic.

BUG REPORT TEMPLATE
=================================================================
Title       Payment succeeds at bank but order is not created when
            the app is backgrounded during the UPI PIN screen

Environment Build 5.2.0 (1841) | Android 14, Redmi Note 13 Pro
            (MIUI 15) | QA2 | user 9876543210

Precondition Cart has SKU SHOE_9981, payable 2299
             UPI app: PhonePe, bank: HDFC test rail

Steps
  1. Launch app, open Cart, tap Pay
  2. Choose UPI, select PhonePe, tap Proceed
  3. On the UPI PIN screen press the Home button (background app)
  4. Complete the PIN entry in PhonePe, return to the app

Actual      App shows 'Payment failed, try again'. Bank SMS confirms
            2299 debited. No order in My Orders. No refund after 24h.
Expected    Order is created in Confirmed state, or the amount is
            auto reversed within the window promised in FAQ section 4.

Evidence    screen_rec_5.2.0_1841.mp4, bank SMS screenshot,
            logcat 14:22:07 to 14:22:41, txn id T2608171422071
Repro rate  4 of 5 attempts
Severity    Critical      Module  Payments      Found in  5.2.0
First bad build  5.1.9 (was passing on 5.1.8)

Answer

The rule set first, because the test design is only as good as the rule I extract: an Indian mobile number is exactly ten digits, the first digit is 6, 7, 8 or 9, and the field may or may not accept a leading +91 or 0. If nobody has documented that last point I raise it as a question before I write a single case, because it decides half the suite. Equivalence partitioning splits the input domain into classes where every member should be treated identically, so I test one representative from each instead of a thousand numbers.

Valid classes: a ten digit number starting with each of 6, 7, 8, 9. Invalid classes: fewer than ten digits, more than ten digits, starts with 0 to 5, contains alphabets, contains special characters or spaces, empty, and the formatting variants +919876543210 and 09876543210. Boundary value analysis then attacks the edges of the length rule, since off by one errors cluster there: nine digits, ten digits, eleven digits, and if you use the three value form, also the value just inside each side.

I add real world classes that pure theory misses: a number pasted with a trailing space from WhatsApp, a number typed with the Indian numbering copy format 98765 43210, an emoji or Devanagari digits, and a repeated digit number like 9999999999 that some backends silently blacklist. The follow up is always 'how many test cases is that' and then 'which do you drop if you have thirty minutes'. I drop the exotic formatting classes and keep one valid representative, the two length boundaries, the invalid first digit, and empty, because those four catch the overwhelming majority of real defects in this field.

FIELD  mobile_number  (10 digits, must start 6/7/8/9)
=================================================================
EQUIVALENCE CLASSES
  Class                        Representative     Expected
  ===========================  =================  ==============
  Valid, starts 9              9876543210         Accepted
  Valid, starts 6              6012345678         Accepted
  Invalid first digit          5876543210         Error shown
  Contains alphabet            98765abcde         Blocked/Error
  Empty                        (blank)            Required error
  With +91 prefix              +919876543210      Per spec (ASK)
  With leading 0               09876543210        Per spec (ASK)

BOUNDARY VALUE ANALYSIS on length
  Length  Value               Expected
  ======  ==================  =========================
  0       (blank)             Required field error
  9       987654321           Invalid, too short
  10      9876543210          Valid, accepted
  11      98765432101         Invalid or truncated at 10

REAL WORLD CLASSES THEORY MISSES
  '9876543210 '   trailing space pasted from WhatsApp
  '98765 43210'   Indian display format with a space
  '९८७६५४३२१०'   Devanagari digits
  '9999999999'    repeated digit, often blacklisted server side

Answer

Two value boundary analysis tests the value at each boundary and the value just outside: 17, 18, 60, 61. Three value analysis adds the value just inside: 17, 18, 19, 59, 60, 61. I use three value form when the field guards something consequential like eligibility or pricing, and two value form when time is short, because the just inside value catches fewer bugs than the just outside one.

To that I add the invalid classes: 0, negative numbers, a blank field, a non integer like 18.5, a non numeric like 'eighteen', a very large number like 999 that may overflow a small integer column, and a leading zero form like 018. What pure numeric boundary analysis misses is everything about how the value arrives and what it means. Is age typed, or derived from a date of birth picker?

If it is derived, the real boundary is not 18, it is the date arithmetic: a user who turns 18 today, a user born on 29 February, and the timezone the server computes against, because a server in UTC will consider an Indian user under 18 for five and a half hours after their birthday. Is the field on the client only, or is it enforced server side too? A tester who only tests through the UI misses that the API accepts 15 when the browser control is bypassed, which for an age gate is a compliance defect, not a cosmetic one.

Also, what happens on edit, does an existing 61 year old record now fail validation on save? The follow up is usually 'so which boundary is the risky one', and for eligibility fields it is always the lower one, because that is where the legal exposure lives.

FIELD  age  (valid range 18 to 60 inclusive)
=================================================================
THREE VALUE BOUNDARY SET
  Value  Class            Expected
  =====  ===============  ===============================
  17     just below min   Rejected, 'must be 18 or above'
  18     min              Accepted
  19     just above min   Accepted
  59     just below max   Accepted
  60     max              Accepted
  61     just above max   Rejected, 'must be 60 or below'

INVALID CLASSES
  0, -1, blank, 18.5, 'eighteen', 999, '018', '1 8'

WHAT NUMERIC BVA MISSES
  DOB derived    user turns 18 today (server TZ vs IST)
  Leap day       born 29 Feb, non leap current year
  API bypass     POST /signup {"age": 15} without the UI
  Edit path      existing 61 year old record fails on save
  Storage        999 into a TINYINT column, silent truncation

Answer

The boundaries are 0, 1, 2 at the low end and 99999, 100000, 100001 at the high end, and because this is currency the decimal boundary matters as much as the integer one: 0.99 should be rejected, 1.00 accepted, and 1.005 or 100.999 tell you whether the app rounds, truncates or rejects a third decimal place. Rounding behaviour on money is a genuine defect source, so I always write a case for a three decimal input and check what reaches the backend, not just what the UI shows. Negative and format classes: a negative value, zero, blank, a value with a comma like 1,000 which is how an Indian user reads it, a value pasted with a rupee symbol, a leading zero like 0100, exponential notation like 1e5 which some numeric inputs happily accept, a very long digit string to see whether the field caps input length, and non numeric characters.

Then the classes that only exist because it is UPI and not a generic number box. Per transaction limits are set by NPCI and the bank, so 100000 may be the app's cap while the user's bank caps at 25000, and the app must surface the bank's rejection cleanly rather than a generic failure. Daily cumulative limits mean the tenth transaction of 10000 in a day must fail even though each individual amount is valid, which is a stateful test no boundary table captures.

Amount above balance, amount exactly equal to balance, and amount that leaves the account below a minimum balance requirement are three different cases. The follow up: 'where do you verify the amount'. On the screen, in the request payload, in the bank's debit SMS, and in the orders or transactions table, because a UI that shows 100 while sending 10000 is the exact bug this field exists to catch.

FIELD  upi_amount  (min 1, max 100000)
=================================================================
BOUNDARY TABLE
  Value       Class              Expected
  ==========  =================  ==========================
  0           below min          Rejected
  0.99        below min, dec     Rejected
  1           min                Accepted
  1.00        min, 2 decimals    Accepted
  2           just above min     Accepted
  99999       just below max     Accepted
  100000      max                Accepted
  100001      above max          Rejected, cap message

FORMAT / NEGATIVE CLASSES
  -100    0100    1,000    Rs 500    1e5    1.005
  100.999    (blank)    'abc'    99999999999999

STATEFUL UPI CLASSES (no table catches these)
  Bank per txn cap lower than app cap  (app 100000, bank 25000)
  Daily cumulative cap: 10 x 10000 in one day
  Amount == available balance
  Amount leaves account below minimum balance

VERIFY IN FOUR PLACES
  UI display | request payload | bank debit SMS | txn table row

Answer

Requirement analysis: QA reads the BRD, FRS or the user stories, raises ambiguities, and identifies what is testable and what is not. Artifact is the clarification or query log and a first cut of the RTM. Sign off is informal, the BA or product owner closes the queries.

Test planning: the test lead defines scope, in scope and out of scope, approach, environments, tools, roles, schedule, risk and mitigation, and entry and exit criteria. Artifact is the test plan and the effort estimate. Sign off is the project manager and often the client in a services engagement.

Test case design: writing scenarios, cases and test data, plus a peer review. Artifacts are the test cases, the test data sheet and the updated RTM. Sign off comes from the test lead through a review, and in regulated projects from the client.

Test environment setup, which runs in parallel: build deployment, test data seeding, third party sandbox access such as a Razorpay test key or a bank test rail. Artifact is the environment readiness checklist. Test execution: run cases, log defects, retest, track daily status.

Artifacts are the execution report, the defect log and the daily status report. Test closure: exit criteria evaluation, the test summary report, defect metrics, deferred defect list and the lessons learned. Sign off is the project manager and the client.

In a two week agile sprint these phases compress rather than disappear, requirement analysis happens in grooming, planning happens in sprint planning, design and execution overlap daily, and closure is the sprint review plus a release note. Follow up you will get: 'in agile do you still write a test plan'. The honest answer is you write one lightweight test approach per release or per epic, not a forty page document per sprint, and the entry and exit criteria live in the definition of done.

Answer

Entry criteria are the conditions that must be true before test execution starts, and they exist to stop QA absorbing the cost of an unready build. Typical set: requirements are baselined and the RTM is complete, test cases are written and peer reviewed, the test environment is up with the correct build deployed, test data is seeded, third party sandboxes are reachable, unit testing is done and the build passes smoke, and the release notes list what changed. Exit criteria are the conditions that must be true before testing is declared complete: planned test case execution reached the agreed threshold, usually 100 percent of high priority cases and 95 percent overall, zero open critical and high severity defects, all medium and low defects either fixed or formally deferred with an owner and a target release, requirement coverage in the RTM at 100 percent, regression suite passed on the release candidate build, and the test summary report signed.

What matters more than the list is what you do when the criteria are not met on the date, and that is what the panel is testing. You do not silently pass the build. You produce a written risk statement: here are the 4 open high severity defects, here are the 60 cases not executed and which modules they cover, here is the user impact if we ship, here is the mitigation, feature flag it, restrict the rollout to 5 percent, keep a rollback plan ready.

Then the go or no go decision belongs to the product owner and the delivery manager, not to QA. QA owns the evidence, the business owns the risk. The follow up is 'have you ever signed off a release with open defects', and the answer they want to hear is yes, with the conditions documented, because a candidate who says never has probably never been near a real release date.

Answer

Static testing is examining artifacts without executing the software: requirements, design documents, user stories, test cases, code, and configuration. Dynamic testing is running the software. Static testing finds defects earliest and therefore cheapest, and the classic curve every panel expects you to reference is that a defect caught in requirements costs a fraction of the same defect caught in production.

Concretely, when a BRD arrives I do a requirement review looking for six defect types. Ambiguity, 'the system should respond quickly', which is untestable until it says 95th percentile under 2 seconds at 500 concurrent users. Incompleteness, a screen that specifies the success path and never says what happens on a failed payment or an expired session.

Inconsistency, section 4 says the OTP is valid for 5 minutes and section 9 says 10. Untestability, 'user friendly interface'. Missing negative rules, what the maximum, minimum and mandatory constraints of each field are.

And missing non functional requirements, load, security, browser and device support matrix, accessibility, and language support, which in an Indian product means asking whether the app must render Devanagari and Tamil. I log these as review comments or defects in a requirement review log, each with the section reference and a proposed rephrasing, because a comment that just says 'unclear' gets ignored. Alongside the review I start the RTM and draft high level scenarios, which itself surfaces gaps, you cannot write a scenario for a rule that does not exist.

Formal review types worth naming: informal review, walkthrough, technical review and inspection, which is the most formal with defined roles, a moderator, a reader and a scribe. The follow up: 'give me one ambiguous requirement you actually found', so keep a real example ready from your project.

Answer

That is grey box testing. Black box treats the system purely through its external interfaces, using techniques derived from specification, equivalence partitioning, boundary values, decision tables and state transitions. White box works from the internal structure, statement and branch coverage, and is normally the developer's territory.

Grey box is the middle position most working manual testers actually occupy in 2026: you cannot read the code but you can see the API contract, the database schema, the logs, the queue and the feature flags. That changes your test design in three ways. First, you can verify the outcome rather than only the screen.

When an order is placed, black box testing checks the confirmation page, grey box checks the row in the orders table, the status column, the payment reference, and the event that got published. That distinction catches the bugs where the UI lies. Second, you can design tests from structure the specification never mentions: seeing that a status column is an enum with nine values immediately hands you a state transition test set, and seeing a unique constraint tells you exactly which duplicate submission to try.

Third, you can triage. A failure with a 500 in the network tab and a stack trace in the log goes to the backend team with the trace attached, a failure with a 200 and wrong rendering goes to frontend, and that halves the round trip time on a defect. The trap the panel is watching for is a tester who starts testing the implementation instead of the requirement, writing cases that assert a specific SQL result the product never promised. The rule is that internal knowledge should generate test ideas and evidence, but the expected result must still trace back to a requirement.

Answer

A test plan is project specific and time bound. The sections I would write: objective and scope, with an explicit out of scope list which is the section that saves you later; the test approach, which levels of testing apply, unit, integration, system, UAT, and which types, functional, regression, compatibility, performance, security, accessibility; test environment and data requirements including third party sandboxes; entry and exit criteria; suspension and resumption criteria, the conditions under which you stop testing entirely, for example smoke failing or the environment being down more than four hours; deliverables, test cases, RTM, defect reports, summary report; roles and responsibilities with named people; schedule and effort estimate; tools; risks and mitigations; and the approval block. A test strategy is organisation level, largely static across projects, and describes how the company tests, standards, defect severity definitions, automation policy, tool stack, documentation templates.

In practice in Indian service companies the strategy exists as an account level or delivery level document, and each project's test plan references it rather than repeating it. In product companies the strategy is often just a wiki page and the plan is a section in the epic. The section panels probe hardest is risk, because it is the one candidates skip.

Concrete risk entries look like: the bank test rail is shared with two other vendors and may be unavailable, mitigation is to book slots and keep a stubbed payment path; only one iOS device is available for a release supporting iOS 15 to 18, mitigation is BrowserStack sessions for the older versions. Follow up: 'who writes and who approves the test plan'. The test lead or manager writes it, the project manager approves, and in a services engagement the client signs it.

Answer

It should be exploratory testing, and the difference is not formality, it is whether learning feeds design. Ad-hoc testing is unplanned and unstructured, you poke around based on instinct, you keep no record, and you cannot tell anyone afterwards what you covered. It has a legitimate narrow use, a five minute gut check on a build, but it is not a strategy.

Monkey testing, sometimes called random testing, is feeding random or chaotic input, random taps, random strings, random navigation order, with no expectation of correctness beyond 'it should not crash'. It is genuinely useful for robustness and is usually automated, an Android monkey run at a fixed seed, and it finds crashes rather than logic defects. Exploratory testing is simultaneous learning, test design and execution, with a documented mission.

It is structured, it just is not scripted in advance. In two hours before a demo, that means I write a charter, spend the time in timeboxed sessions, take notes as I go, and come out with three things: a list of what I covered, a list of defects, and a list of areas I did not touch, which is what lets the product manager decide what to demo and what to avoid. That last output is the reason exploratory beats ad-hoc, an ad-hoc session ends with 'seems fine', which tells the demo owner nothing.

The follow up is usually 'so is exploratory testing unstructured', and the answer is no, it is unscripted but structured, and the structure comes from charters, timeboxes and session notes. Interviewers at product companies especially value candidates who can name session based test management here rather than treating exploratory as a synonym for winging it.

Answer

Error guessing is designing tests from an expectation of where defects are likely, based on experience with similar systems, past defects in this product, and knowledge of common developer mistakes. It is explicitly experience based rather than specification based, and it is in the ISTQB syllabus alongside exploratory testing and checklist based testing for exactly that reason. The criticism is fair: as pure intuition it is unrepeatable, and it dies when the person leaves.

The way to make it durable is to write the intuition down as a defect taxonomy or a bug hunting checklist that the whole team uses. My working checklist for any Indian consumer app: empty and null and whitespace only inputs; the boundary at exactly the limit and one past it; duplicate submission from a double tap on a slow network; the back button and the browser refresh in the middle of a multi step flow; two tabs or two devices with the same account; special characters and apostrophes in names, which breaks naive SQL and naive string handling, and a name like D'Souza is common enough that this is not a contrived case; dates around month end, financial year end on 31 March, and daylight saving in any integration with a US or EU system; timezone, because a server on UTC and a user on IST is a five and a half hour bug generator; long strings in a field with no visible max length; and the session expiring exactly while a form is open. A second source is your own defect history: mining the last six months of production escapes gives you a taxonomy specific to this codebase, which is far better than a generic list.

Follow up: 'give me an error guess you made that found a real bug'. Have one ready with the reasoning, not just the outcome.

Answer

A decision table is the right technique whenever the outcome depends on a combination of conditions rather than a single input, because equivalence partitioning tests each field in isolation and will happily miss the case where two individually valid inputs combine into a rejection. I build it in four steps. List the conditions: applicant age between 21 and 58, net monthly income at least 25000, CIBIL score at least 700, and existing EMI to income ratio at or below 50 percent.

List the actions the system can take: approve at full requested amount, approve at a reduced limit, send to manual underwriting, reject. Then enumerate the condition combinations. Four binary conditions give 16 combinations, which is small enough to test in full, and I would test all 16 rather than collapsing them because loan eligibility is a money and compliance surface.

When a table gets large, for example seven conditions giving 128 rules, I collapse it using don't care entries: if age fails, nothing else matters and the outcome is reject, so all eight rows where age is false collapse into one rule. Where the technique earns its keep is in exposing rules nobody wrote down. Building this table forces the question 'what happens when income is fine and CIBIL is 690', and often the BA has no answer, which is a requirement defect found before a line of code runs.

It also forces the borderline definition question: is CIBIL exactly 700 approved or rejected, and is a CIBIL of minus 1, meaning no credit history, treated as a failure or as a separate manual review path? The follow up: 'how do you combine this with boundary values'. You run the decision table for the combinations and boundary values for each individual condition, 20 and 21 for age, 24999 and 25000 for income, 699 and 700 for CIBIL.

DECISION TABLE  personal loan eligibility
===================================================================
CONDITIONS               R1   R2   R3   R4   R5   R6   R7   R8
  Age 21 to 58           Y    Y    Y    Y    Y    Y    Y    N
  Income >= 25000        Y    Y    Y    Y    N    N    N    X
  CIBIL >= 700           Y    Y    N    N    Y    Y    N    X
  EMI ratio <= 50%       Y    N    Y    N    Y    N    X    X
===================================================================
ACTIONS
  Approve full           X
  Approve reduced             X         .    X
  Manual underwriting              X              .
  Reject                                .         X    X    X

X in a condition row = don't care (rule already decided)

BOUNDARY VALUES PER CONDITION (run alongside the table)
  Age     20 / 21 / 58 / 59
  Income  24999 / 25000
  CIBIL   699 / 700   plus -1 (no credit history) as its own class
  EMI     49% / 50% / 51%

QUESTIONS THE TABLE FORCED THE BA TO ANSWER
  Is CIBIL exactly 700 approved?
  Is 'no credit history' a rejection or a separate manual path?
  Does a co applicant income get added before the 25000 check?

Answer

State transition testing is the technique for any workflow where the same event produces different results depending on the current state, and an order lifecycle is the textbook case. I start by drawing the state transition diagram, then converting it to a state transition table with one row per state and one column per event, filling in either the resulting state or 'invalid'. That table is the test suite.

Valid transition coverage, sometimes called 0-switch coverage, means testing every valid transition at least once: Created to Confirmed on payment success, Confirmed to Packed on warehouse pick, and so on. That is the baseline. The defects, though, live in the invalid transitions, and those are the cells most teams never test.

Can you cancel an order that is already Delivered? Can a Shipped order go back to Payment Pending because a webhook arrived late and out of order? Can a Refunded order be refunded a second time by a retry?

Those are real production incidents, and each is one cell in the table. 1-switch coverage means testing every valid pair of consecutive transitions, which catches the bug where the transition itself is fine but the sequence corrupts state, for example Cancel then Return. I also test the triggers, not just the states, since in a real system these transitions are driven by external events, a payment webhook, a courier API callback, an ops admin action, and the same transition triggered by ops versus by the courier may take different code paths. The follow up: 'how do you test an invalid transition when the UI does not offer the button'. Through the API, or by manipulating the state through the admin tool and then firing the event, which is why a manual tester needs Postman and a database view.

STATE TRANSITION TABLE  (order lifecycle)
===================================================================
CURRENT STATE      pay_ok    cancel     ship     deliver   refund
  CREATED          CONFIRMED CANCELLED  invalid  invalid   invalid
  CONFIRMED        invalid   CANCELLED  SHIPPED  invalid   REFUNDED
  PACKED           invalid   CANCELLED  SHIPPED  invalid   invalid
  SHIPPED          invalid   invalid    invalid  DELIVERED invalid
  OUT_FOR_DELIVERY invalid   invalid    invalid  DELIVERED invalid
  DELIVERED        invalid   invalid    invalid  invalid   invalid
  CANCELLED        invalid   invalid    invalid  invalid   REFUNDED
  RETURNED         invalid   invalid    invalid  invalid   REFUNDED
  REFUNDED         invalid   invalid    invalid  invalid   invalid

EVERY 'invalid' CELL IS A NEGATIVE TEST CASE

HIGH RISK INVALID TRANSITIONS SEEN IN PRODUCTION
  DELIVERED + cancel        (ops tool bypasses the guard)
  SHIPPED + pay_ok          (late duplicate payment webhook)
  REFUNDED + refund         (retry causes double refund)
  CANCELLED + ship          (warehouse never got the cancel event)

1-SWITCH PAIRS WORTH TESTING
  CREATED > CONFIRMED > CANCELLED > refund
  CONFIRMED > SHIPPED > DELIVERED > return > REFUNDED

Answer

Pairwise testing, also called all pairs or 2-way combinatorial testing. The underlying empirical claim is that the large majority of combinatorial defects are triggered by a single parameter or an interaction between just two parameters, so covering every pair of values at least once catches most of them at a fraction of the cost. For 4x3x3x2x5x4 the pairwise set comes out around 20 to 25 tests instead of 1440, roughly a 98 percent reduction.

I do not generate that by hand, I use a tool, Microsoft PICT is the usual choice, ACTS from NIST is the other, and both take a parameter file and emit a covering array. What makes this an intermediate answer rather than a basic one is the three things you have to add around the generated set. First, constraints: some combinations are illegal, for example City equals Bengaluru with State equals Maharashtra, or Job Type equals Internship with Experience equals 10 plus years.

PICT supports IF THEN constraints and you must encode them or half your generated cases will be invalid input rather than useful tests. Second, seeding: pairwise gives no guarantee about specific business critical combinations, so I seed the combinations we know matter, the default filter set that 70 percent of users hit, and the combination from last quarter's production incident, and the generator includes them. Third, awareness of the limit: pairwise will not catch a defect that only appears when three specific values coincide, so for genuinely high risk areas I raise the order to 3-way for those parameters only. I would also say plainly that reducing the count is not free, and the way I justify it to a lead is with the coverage numbers, all 143 pairs covered in 24 tests, rather than a vague claim of efficiency.

PICT MODEL FILE  (search_filters.txt)
===================================================================
City:        Bengaluru, Mumbai, Delhi, Pune
JobType:     FullTime, PartTime, Internship
Experience:  0-2, 3-5, 10+
Remote:      Yes, No
Salary:      0-3L, 3-6L, 6-10L, 10-20L, 20L+
SortBy:      Relevance, Date, Salary, Rating

IF [JobType] = "Internship" THEN [Experience] = "0-2";
IF [JobType] = "Internship" THEN [Salary] IN {"0-3L"};

RUN
  pict search_filters.txt > cases.tsv

RESULT
  Full cartesian    4 x 3 x 3 x 2 x 5 x 4 = 1440 combinations
  Pairwise output   ~24 test cases, all 143 value pairs covered
  Reduction         about 98%

SEED FILE (force must have combinations into the output)
  Bengaluru  FullTime  3-5   No   6-10L   Relevance   << default set
  Mumbai     PartTime  0-2   Yes  0-3L    Salary      << INC-4471 repro

LIMIT
  Pairwise misses defects needing 3 specific values to coincide.
  Raise to 3-way (pict /o:3) for the highest risk parameters only.

Answer

Session based test management, SBTM, is the framework that makes exploratory testing accountable and reportable. The unit is a session: an uninterrupted, timeboxed block of testing against a single charter. Timeboxes are conventionally short at around 45 minutes, normal at 90, and long at 120, and the point of the box is that it forces you to stop, write up, and decide whether the area deserves another session.

A charter is a one to three line mission statement, and the standard form is 'Explore TARGET with RESOURCES to discover INFORMATION'. For example: explore the coupon engine at checkout with expired, exhausted and stacked coupons to discover incorrect discount calculations. A good charter is narrow enough to finish in one session and open enough that you are not just executing prewritten cases.

During the session I keep notes in a fixed shape: what I tested, bugs found, issues and questions, and any setup or environment friction. At the end I produce a session sheet with the charter, the start time, the duration, and the task breakdown metrics that make SBTM reportable to a manager, the split of time between test design and execution, bug investigation and reporting, and setup, usually written as a rough percentage. That split is the number leads actually want, because a team spending 50 percent of session time on setup has an environment problem, not a testing problem.

I also record coverage and, crucially, what I did not cover, so the risk picture is honest. The follow up: 'how does this appear in a status report next to scripted execution counts'. Answer with sessions completed, charters outstanding, bugs per session, and the setup versus testing ratio, which sits alongside pass and fail counts rather than replacing them.

SESSION SHEET
===================================================================
CHARTER    Explore the checkout coupon engine with expired,
           exhausted and stacked coupons to discover incorrect
           discount and GST calculations.

TESTER     R. Iyer
BUILD      5.2.0 (1841), QA2
START      17 Aug 2026, 10:15 IST
DURATION   90 min (normal session)

TASK BREAKDOWN
  Test design and execution   55%
  Bug investigation and report 30%
  Session setup and data       15%

AREAS COVERED
  Expired coupon, usage limit exhausted, min order not met,
  coupon + wallet stacking, coupon on a partially returned order

NOT COVERED (risk)
  Coupon behaviour on EMI orders, coupon in the iOS app

BUGS
  BUG-4471  GST recalculated on pre discount amount (High)
  BUG-4472  Exhausted coupon shows a generic error (Low)

ISSUES / QUESTIONS
  Is stacking wallet + coupon intended? No AC covers it.
  QA2 coupon seed data resets nightly, cost 12 min of setup.

Answer

You never answer this with 'I run the high priority ones', because that begs the question of how priority was assigned. I select on four inputs. First, change impact: I read the release notes, the merged pull requests and the commit list, and map the changed modules to the test suite.

If pricing changed, everything touching price, cart, coupon, GST, invoice and refund is in. Second, dependency and shared component analysis: I ask the developers which shared services or components the change touched, because a change to a common date utility affects modules nobody would guess from the release notes. Third, defect history: the modules with the most defects historically and the modules with the most reopens are the modules most likely to break again, and a query on the defect tracker gives me that in five minutes.

Fourth, business criticality and usage data: login, search, checkout and payment run regardless of what changed, because their failure cost dominates. On top of that selection I apply two multipliers. Anything automated runs anyway since it costs machine time, not my time, which usually means the smoke and core regression suites are already covered and my two days go to what automation cannot reach.

And I run the highest risk 20 percent first, so that if we lose half a day to an environment failure I have executed the cases that matter rather than the cases that were alphabetically first. Finally I document the skip list, because the deliverable at the end is not just a pass rate, it is a pass rate plus a stated risk. The follow up: 'a critical bug is found on day two in an area you skipped, what do you say'. You say you had documented the skip and the risk in writing before execution started, which is the only defensible position.

Answer

Suite rot is a real and common problem and the fix is a deliberate audit, not more execution. I attack it on five fronts. Duplicates: after three years of different testers adding cases, the same behaviour is often covered five times with slightly different wording.

Deduping against the RTM typically removes 10 to 20 percent. Obsolete cases: features that were removed, flows that were redesigned, cases still referencing a screen that no longer exists. These are worse than useless, because a tester spends time deciding whether the failure is real.

Cases with no traceability: if a case maps to no requirement and nobody can say why it exists, it either gets a requirement or gets deleted. Low value cases: a case that has passed on every run for two years and covers a static screen is a candidate for a lower frequency tier rather than every release. And unclear cases: any case whose expected result is 'should work properly' produces inconsistent results between testers, which is exactly why nobody trusts the pass rate.

Then I restructure into tiers rather than one flat suite: a smoke tier of about 40 cases on every build, a core regression tier of maybe 200 cases run every release, a full regression tier run before major releases or quarterly, and a legacy tier run on demand. Selection then becomes a policy rather than a negotiation each time. Alongside that I push the stable, repetitive, data driven cases toward automation, because those are precisely the ones that waste a human's time and that a human executes carelessly by the fourth day.

Follow up: 'who owns suite maintenance'. The honest answer is that it has to be a scheduled activity with an owner, usually a few hours per sprint, because if it is 'whenever we get time' it never happens.

Answer

An RTM maps requirements to test artifacts so that coverage is a fact rather than a claim. The minimum useful matrix has requirement ID, requirement description, the test scenario and test case IDs that cover it, execution status, and the defect IDs raised against it. Forward traceability runs requirement to test case and answers 'is every requirement covered', which is the client's question and which immediately exposes requirements with zero cases, usually the non functional ones and the error handling paths.

Backward traceability runs test case to requirement and answers a different and equally important question: 'why does this test case exist'. Any case that traces to nothing is either testing an undocumented behaviour, in which case the requirement is missing, or it is obsolete, in which case it should be deleted. That is the check that keeps a suite from rotting.

Bidirectional traceability is both together and it is what audited or regulated projects require. The third use is impact analysis: when a requirement changes in sprint 9, the RTM tells you in seconds which 14 cases must be updated and which defects were previously raised in that area, instead of a tester grepping a spreadsheet. In tooling terms, in JIRA with Zephyr Scale or Xray the RTM is not a separate spreadsheet, it is a coverage report generated from issue links, requirement issue linked to test issue linked to execution and defect.

In smaller teams it genuinely is a spreadsheet, and the risk is that it drifts out of date, which is why I update it at case design time rather than at the end. Follow up: 'what does 100 percent RTM coverage actually prove'. It proves every requirement has at least one test case. It does not prove the cases are good, which is why review of the cases matters as much as the coverage number.

REQUIREMENT TRACEABILITY MATRIX
===================================================================
Req ID   Requirement            Test Cases        Status  Defects
=======  =====================  ================  ======  =========
FR-01    User logs in with      TC_001, TC_002,   Pass    -
         mobile + OTP           TC_003
FR-02    OTP expires in 5 min   TC_004, TC_005    Fail    BUG-4402
FR-03    Account locks after    TC_006 to TC_009  Pass    BUG-4390
         5 failed attempts                                (closed)
FR-04    Coupon min order 2000  TC_014, TC_015    Pass    -
NFR-01   Login p95 < 2s at      (none)            NOT     -
         500 concurrent users                     COVERED

FORWARD    requirement > test case  : is everything covered?
           NFR-01 has zero cases, that is the finding.
BACKWARD   test case > requirement  : why does this case exist?
           TC_022 traces to nothing, either a missing
           requirement or an obsolete case.

IMPACT ANALYSIS
  FR-02 changes from 5 min to 10 min in sprint 9
  > update TC_004, TC_005, retest, reopen BUG-4402 if needed

Answer

JIRA is the default in Indian teams and panels ask this to separate people who log tickets from people who run a defect process. On workflow: the out of the box scheme is rarely what a QA team uses, so most projects add a QA specific transition set, To Do, In Progress, Ready for QA, In QA, Reopened, Done, with a screen on the Reopened transition that forces a comment. The thing to know is that a status and a resolution are different fields, and closing a bug without setting a resolution is what produces the classic 'closed but still shows as unresolved' mess in every report.

Custom fields I expect on a defect project: severity, since JIRA ships with priority only, environment or build found in, found in phase which lets you compute defect leakage later, root cause which is filled by the developer at fix time, and reproducibility. On JQL, the queries I keep as saved filters and put on a dashboard: my open defects, defects awaiting retest on the current build, defects rejected in the last week so nothing gets quietly buried, reopened defects which is a quality signal, defects with no linked test case which is a process hygiene check, and stale bugs untouched for 14 days. I also use ORDER BY and the updated field a lot, because the useful triage question is usually 'what changed since yesterday'.

Follow up you should be ready for: 'how do you report QA status from JIRA to a manager'. Not by screenshotting the board. By a dashboard with the open defect count by severity, the trend over the sprint, the reopen rate, and the test execution progress from Zephyr or Xray, which is a different plugin from the issue tracker itself.

SAVED JQL FILTERS FOR A QA DASHBOARD
===================================================================
Open defects assigned to my team, worst first
  project = SHOP AND issuetype = Bug AND statusCategory != Done
  AND "Severity[Dropdown]" in (Critical, High)
  ORDER BY "Severity[Dropdown]" ASC, created ASC

Waiting for my retest on the current build
  project = SHOP AND issuetype = Bug AND status = "Ready for QA"
  AND "Fix Build[Short text]" ~ "5.2.1" AND reporter = currentUser()

Rejected in the last 7 days (nothing gets buried)
  project = SHOP AND issuetype = Bug AND resolution in
  ("Cannot Reproduce", "Works as Designed", "Duplicate")
  AND resolved >= -7d ORDER BY resolved DESC

Reopened defects this release (quality signal)
  project = SHOP AND issuetype = Bug AND status changed TO Reopened
  AFTER startOfMonth() ORDER BY updated DESC

Defects with no linked test case (process hygiene)
  project = SHOP AND issuetype = Bug AND issueLinkType != "tests"

Stale, untouched for 14 days
  project = SHOP AND issuetype = Bug AND statusCategory != Done
  AND updated <= -14d ORDER BY updated ASC

Answer

JIRA alone tracks issues, it does not manage tests, which is why teams add Zephyr Scale, Zephyr Squad or Xray. The mental model in Xray is that tests, preconditions, test sets, test plans and test executions are all JIRA issue types, so everything is linkable and queryable with JQL plus a JQL extension. Zephyr Scale keeps test cases in its own tree with folders and versions but still links to JIRA issues.

Either way the working loop is the same. You author test cases against a folder or a test set, link each case to the requirement or story it covers, which gives you the coverage report that replaces a manual RTM. You then create a test cycle or a test execution for a specific build and environment, add the selected cases to it, and execute, marking each Pass, Fail, Blocked, Work in Progress or Not Executed.

Blocked is the status people misuse: it means you could not execute because of an external reason, an environment down or a dependency defect, and keeping it distinct from Fail is what stops the pass rate from lying. When a case fails, you raise the defect from within the execution so the link between the test run and the bug is created automatically, and that link is what later powers 'which requirement is at risk' rather than just 'which case failed'. The reports that matter to a lead are the traceability report, the execution progress per cycle, and the coverage per requirement status.

Two practical points to raise: test cases should be versioned against a release so a case updated in sprint 9 does not silently rewrite the evidence of a sprint 6 execution, and re executing a cycle should create a new execution rather than overwriting the old one, because audit trails matter in services and regulated work. Follow up: 'have you used TestRail or qTest', so name whichever you actually used and describe the same loop.

Answer

This is a bug advocacy question and the panel is testing temperament as much as technique. The wrong answers are escalating immediately and dropping it silently. My sequence: first, re read my own report honestly and check whether the rejection is my fault.

Missing steps, wrong environment, an expectation I assumed rather than sourced. In my experience a real share of rejections are earned. Second, find the authority for the expected behaviour and cite it precisely: the acceptance criterion on the story, a line and section in the BRD, the Figma frame, the behaviour of the previous production release, or a screenshot from the competitor the product manager benchmarked against.

'Works as designed' is only refutable by pointing at the design. Third, if no authority exists, and this is common, then I stop arguing correctness and reframe to impact, because when the specification is silent the question is not 'is this a bug' but 'is this what we want to ship'. I quantify: this affects the 34 percent of users on Android who pay with UPI, it produces a support ticket per occurrence, and here is the money at risk.

Fourth, take it to a conversation rather than ticket comments. Ticket comment threads escalate tone and slow everything down, a five minute call with the developer and a shared screen resolves most of them, and if it does not, the disagreement goes to triage with the product owner, who owns the decision. Fifth, whatever the outcome, record it.

If it is genuinely working as designed, I raise the requirement gap as a separate item, because the same confusion will recur. The follow up: 'what if the product owner also disagrees'. Then it is not a defect, it is my opinion, I document the risk once and move on. Testers who cannot do that last part become unemployable regardless of technical skill.

Answer

I never give a single number without stating the basis. Three techniques are worth naming. Work breakdown, where I decompose each story into test design, test data setup, execution, defect logging and retesting, and estimate each, which is the most defensible because every line can be challenged individually.

Three point estimation, where each task gets an optimistic, most likely and pessimistic figure and the estimate is (O + 4M + P) divided by 6, which is useful when the story has unknowns because it makes the uncertainty explicit rather than hiding it in padding. And historical or velocity based estimation, where I use what similar stories actually cost in the last few sprints, which is the most accurate input if the team has been tracking. In practice I combine: break down the story, use history for the per task figures, and use three point on the one or two tasks that are genuinely novel.

The parts juniors forget and panels check for: retest and regression time, not just first pass execution, and a realistic defect rate, if history says this module produces four defects per story, that is four retests plus the investigation time. Environment and test data setup, which on a payments or integration story is often larger than execution. Buffer for build rejections and redeployments.

And the fact that a tester is not available eight hours a day, ceremonies, triage and support eat two. So I usually plan on five to six productive hours. I also flag dependencies explicitly: if the third party sandbox is only available in week two, my estimate is conditional and I say so in planning rather than discovering it on day eight.

Follow up: 'the sprint has 34 points and your estimate does not fit'. Then the conversation is about reducing scope or accepting stated risk, and it happens in planning, not on the last day.

Answer

That acceptance criterion is untestable, and the professional move is to fix it early and cheaply rather than to refuse the story. My approach has three stages. Before the sprint, in grooming or the three amigos session, which is the single highest leverage meeting a QA attends, I ask the questions that turn intent into criteria: which fields are filterable, do filters combine with AND or OR, what happens when a filter returns zero results, are filters preserved on back navigation and on refresh, is there a maximum number of selections, is the filter applied client side or server side, and what is the expected behaviour on a slow network.

Each answer becomes a testable criterion, and the standard Given When Then form is worth using because it forces observability. If the product owner cannot answer, that itself is a finding and better surfaced in grooming than in UAT. During the sprint, when a gap surfaces mid development, I do not open a debate in a ticket.

I write my assumption explicitly, 'assuming filters combine with AND, tested accordingly', confirm it with the product owner in a message, and test against the assumption. That keeps the sprint moving while creating a record. If the assumption is later wrong, the record shows the decision point rather than a tester's error.

Third, I use the definition of done as the structural fix, so 'acceptance criteria are testable and reviewed by QA' is a condition for a story entering the sprint, which prevents the same argument every two weeks. The follow up: 'what if the PO says just use your judgement'. Then I document my judgement as the specification, share it, and treat silence as agreement, which is far better than testing against an unstated standard.

Answer

Two days means I cannot document my way to safety, so I work outside in and prioritise ruthlessly. Half day one is information gathering from every source except the missing document. The application itself: I walk the form and build a field inventory, and this is the artifact that makes the rest possible, one row per field with its type, whether it is mandatory, its visible constraints, its default, and what it depends on.

The system: page source and the API payload tell me the actual field names, types and validation the backend enforces, and the database schema tells me column types, lengths, nullability and enum values, which is a free specification. Column varchar(30) on a name field is a boundary case handed to me for free. History: the defect tracker for this module tells me where it broke before, and support tickets tell me what users complain about.

People: 20 minutes with the business user or the underwriter who actually processes these proposals is worth more than a day of reading, because they will tell me the three fields that cause every rework. Day one afternoon and day two are timeboxed exploratory sessions in risk order, with notes as I go. Risk order for an insurance proposal is money and eligibility fields first, premium calculation, sum assured, date of birth and age derivation, nominee details, pre existing condition declarations, then document uploads, then cosmetic fields.

I write cases as I go for what I find, not before, so the output at the end of day two is a field inventory, a set of maybe 60 high value cases concentrated on the risky third of the form, a defect list, and an explicit uncovered list. The follow up: 'how do you know your expected results are right without requirements'. I do not, fully, so every inferred rule is marked as an assumption and sent to the business user for confirmation.

Answer

Backlog grooming or refinement is where a QA has the most leverage, because this is where you make acceptance criteria testable, raise edge cases the product owner has not considered, and flag stories that cannot be tested with the current environment or data. A story that arrives in planning already carrying QA's questions is a story that will not slip. Sprint planning is where you give the testing estimate, raise dependencies such as third party sandbox availability, and push back if the testing load is stacked at the end of the sprint, which is the structural problem in most teams: eight stories all landing on day nine gives QA no time.

The fix is arguing for staggered delivery and for testing to start on the first story on day three. Daily standup is where you report blockers precisely, 'blocked on QA2 since 4 pm, three stories cannot progress', rather than reciting what you tested. Sprint review or demo is where you may demo the feature and you certainly should surface known issues honestly, because a demo that hides a defect creates a much worse conversation later.

Retrospective is where you raise systemic issues with evidence: build rejection counts, the percentage of session time lost to environment setup, defect leakage from the last release. On the definition of done, the testing entries I argue for: acceptance criteria verified, test cases written and linked to the story, functional testing complete on the target browsers and devices, regression on the impacted area passed, zero open critical and high defects, no medium defect open without an explicit deferral, and test evidence attached. Follow up: 'who tests in agile'. The whole team is responsible for quality, but a dedicated tester still owns the design of the testing, and saying 'developers test their own work so QA is not needed' is not an answer any Indian panel wants.

Answer

UAT is validation by the business or the end user that the system solves their problem, run against real business scenarios rather than against test cases, and typically on a separate UAT environment with production like data. QA does not execute UAT, but QA makes it possible, and doing that well is a substantial part of a senior manual tester's job in Indian service projects. My role: prepare the UAT environment and confirm the correct build is deployed, prepare and mask realistic data, because business users will not test with 'Test User 1' and a 1 rupee policy, write UAT scenarios in business language rather than system steps, conduct a walkthrough session so users know how to log a defect and where, and then act as the triage layer during the cycle, because most UAT 'defects' are user error, environment issues, data issues or change requests rather than defects.

Separating those four categories quickly is the whole game, and the failure mode when nobody does it is that a UAT cycle produces 60 tickets, the team panics, and it turns out 40 are training issues. Other common failures: business users have no time and start on day four of a five day window, so I ask for named users and booked calendar slots in advance; the UAT environment drifts from production or has a stale build; and change requests arrive disguised as defects, which need to go to a change control conversation, not a bug fix. Sign off means the business accepts the system for release, and it should be explicit, in writing, listing the known open defects and the agreed deferrals.

A sign off that pretends there are no open issues is the one that becomes a dispute later. Follow up: 'what if a UAT defect is really a missed requirement'. Then it is a change request and it goes through change control with an impact and effort assessment, and pretending otherwise destroys the schedule.

Answer

First I stop treating the support matrix as a given and rebuild it from data. Analytics tells me the actual distribution: if 78 percent of sessions are Chrome on Android and 9 percent are Safari on iOS, and 0.3 percent are Edge, the matrix should not treat all of them equally. In the Indian market the distribution is usually heavily Chrome on Android, with a long tail of Xiaomi, Samsung, Vivo, Oppo and Realme devices, mid range hardware, and a meaningful share still on 4 to 6 GB RAM devices, which matters for performance testing far more than the browser version does.

Then I tier: tier one combinations get full functional coverage on real devices, tier two gets a smoke plus visual pass, tier three gets a best effort check and a stated support caveat. For the devices I do not own, cloud device farms are the answer, BrowserStack and LambdaTest being the two most used in Indian teams, both giving real device sessions plus manual interactive testing, a device log and network throttling. Sauce Labs and Perfecto appear in larger enterprises.

What I would say about the practical limits, because this is where an experienced answer shows: cloud devices are excellent for layout, rendering, browser specific behaviour and OS version differences, and poor for anything involving real hardware conditions, real SIM behaviour, incoming calls, actual network handover from 4G to 2G, camera and biometric hardware, and battery. So real devices stay in the loop for those. I also use responsive mode in DevTools for fast layout iteration but never as evidence, because emulation is not the same rendering engine as an actual iPhone.

Follow up: 'how do you decide the tier one list'. Analytics for the last 90 days plus the devices your highest value customers use, not the devices the team happens to own.

Answer

The whole category of environmental and lifecycle conditions that a browser tab is insulated from. Interrupt testing first: an incoming call, an alarm, a WhatsApp call, a low battery warning, a system update prompt, or a notification arriving while the user is on the OTP screen or the payment screen. The app must survive the interrupt and return to the same state with the same data, and the payment screen is the highest risk place for this because the interrupt often coincides with a real money transaction.

App lifecycle: background the app for 30 seconds, for 30 minutes, and overnight, then resume. Does the session persist, does it re authenticate, does it lose form data, does it show stale cached data. Kill the app from the recents list mid flow and reopen.

Network conditions matter far more than on desktop: switching from wifi to 4G mid upload, dropping from 4G to 2G which is a genuine daily condition on Indian intercity travel, going into airplane mode and back, and the worst case, a connected but non functional network where requests hang rather than fail fast. Permissions: denying camera, location, storage or notifications at install and then granting later, revoking a permission from system settings while the app is running, and the behaviour on a fresh install versus an upgrade. Installation and upgrade: install over an older version and confirm local data and login survive, which is the upgrade path that breaks silently.

Then device specifics: low storage, low memory kills, screen rotation, dark mode, system font scaling at 130 percent which breaks layouts constantly, and split screen. Plus push notification behaviour when the app is foreground, background and killed. Follow up: 'which of these have you actually caught a bug with'. Interrupt on the payment screen and the upgrade path are the two that find real defects most often.

MOBILE CONDITIONS CHECKLIST (run per critical flow)
===================================================================
INTERRUPTS
  Incoming call during OTP entry
  WhatsApp call during payment PIN entry
  Alarm / system update prompt mid checkout
  Low battery warning, then battery saver mode ON

LIFECYCLE
  Background 30 sec, 30 min, overnight, then resume
  Kill from recents mid flow, reopen
  Device reboot with a pending transaction

NETWORK
  Wifi to 4G mid upload
  4G to 2G (intercity train condition)
  Airplane mode ON then OFF mid request
  Connected but dead network (request hangs, no failure)

PERMISSIONS
  Deny at install, grant later from settings
  Revoke camera / location while app is running
  Fresh install vs upgrade permission state

INSTALL / UPGRADE
  Install over previous version, verify login and local data
  Downgrade attempt, low storage during install

DEVICE STATE
  Low storage, low memory kill, rotation, dark mode
  System font size at 130%, split screen, gesture nav vs buttons

PUSH
  Notification received with app foreground / background / killed
  Deep link from a notification to a specific order

Answer

First I stop calling it a Redmi bug and isolate the variable, because at least four things differ between those devices: the OEM skin, the Android version, the hardware including RAM and chipset, and the device settings. So I fix one at a time. Is it reproducible on another MIUI or HyperOS device with a different Android version, is it reproducible on a Pixel running the same Android version as the Redmi, is it reproducible on the same Redmi after a factory reset with default settings.

That last one matters because a large share of 'OEM bugs' are actually aggressive settings the user or the OEM enabled. The behaviours I have learned to expect in the Indian device landscape: MIUI and HyperOS on Xiaomi, Redmi and Poco are the most aggressive about background process killing and require the user to enable autostart and disable battery optimisation for the app, which is why push notifications and background sync 'do not work' on Xiaomi far more than on other brands. Samsung One UI has its own battery optimisation and a Deep Sleeping Apps list with similar effects, plus a different default font and display scaling that exposes layout truncation.

Vivo Funtouch OS, Oppo ColorOS and Realme UI have their own equivalents. Beyond battery, the recurring differences are default font size and display scale, gesture navigation implementations that conflict with a swipe gesture in your app, permission dialog flows and extra OEM level permission layers, WebView version differences on older devices, and default keyboard behaviour which affects input fields and autofill. What I document when I raise the bug is the full device fingerprint, brand, model, Android version, skin version, RAM, and the relevant settings state, because 'Redmi Note 13' alone is not enough for a developer to reproduce.

Follow up: 'how do you test this without owning ten phones'. Cloud device farms for the skin and OS matrix, and a small real device set for the battery and background behaviours the farms cannot simulate.

Answer

Payment testing is different from other functional testing because the failure mode is not a broken screen, it is money in the wrong place, and the system is distributed across your app, a payment gateway such as Razorpay, PayU, Cashfree or Paytm, the NPCI rails and the bank, with asynchronous callbacks between them. The edge cases that cost money are almost all timing and state cases. Deemed success or late success: the bank debits, the callback to your server is delayed or lost, and your app shows failure while the money is gone.

This is the single most expensive UPI defect class and the correct behaviour is a reconciliation job plus a status polling fallback, so I test it by simulating a dropped callback and confirming the order eventually reconciles rather than staying failed. Double debit from a double tap or a retry on a hung request, which requires idempotency keys, so I test the same idempotency key twice and confirm one charge. Callback replay: the gateway retries a webhook, and if your handler is not idempotent you create two orders or refund twice.

Out of order callbacks, where the success webhook arrives after the timeout job already marked the transaction failed. Then the amount and state cases: partial refund, refund of an already refunded transaction, refund after the order is delivered, a coupon applied then the order partially returned, and the GST recomputation on the discounted rather than the pre discount amount. Plus limits: per transaction bank cap below the app cap, daily cumulative cap, and mandate or autopay flows.

Testing without a real bank is done in the gateway's sandbox with their test VPAs and test cards, each mapped to a forced outcome, success, failure, timeout, insufficient funds, and by firing webhooks manually at your own endpoint from Postman with a valid signature. Follow up: 'how do you verify a payment truly succeeded'. Four places, gateway dashboard, your payments table, the order state, and the customer facing artifact, invoice or SMS. Any two disagreeing is a defect.

PAYMENT EDGE CASE MATRIX
===================================================================
CASE                       HOW TO SIMULATE          MUST HAPPEN
=========================  =======================  ==============
Deemed success (debit,     Block the callback URL   Reconciliation
no callback)               with a firewall rule     marks order paid

Double tap on Pay          Two rapid submits with   One charge only
                           the same idempotency key

Webhook replay             Re POST the same payload Single order,
                           from Postman             no double credit

Out of order callback      Fire success AFTER the   Success wins,
                           timeout job runs         order recovers

User aborts on PIN screen  Press back in the UPI    Txn cancelled,
                           app                      no pending debit

Bank cap below app cap     Test VPA capped at 25000 Clear bank
                           send 50000               message, not
                                                    'Something went
                                                    wrong'

Refund of a refund         Call refund twice        Second rejected

SANDBOX TOOLS
  Razorpay test VPAs: success@razorpay / failure@razorpay
  Test cards mapped to success, failure, insufficient funds
  Webhook signature must be valid or the handler must reject it

VERIFY IN FOUR PLACES
  gateway dashboard | payments table | order state | invoice or SMS

Answer

The UI shows what the application chose to display, the database shows what actually happened, and the gap between those two is where a whole class of defects hides. Four things I validate in SQL. First, that the write actually happened correctly: after placing an order I check the order row, its status, the amount, the currency, the user id, the created timestamp and the payment reference, because a UI that shows a confirmation while writing a null payment reference is a real and common bug.

Second, data integrity and orphans: an order with no order items, a payment with no matching order, a user with a duplicate mobile number where a unique constraint was supposed to exist. Third, transformations and calculations: the discount, the GST split into CGST and SGST, and the rounding, since a UI rounds for display and hides that the stored value is 2298.9999. Fourth, test data setup and state manipulation, which is the practical everyday use, seeding the exact record you need instead of clicking through eight screens, though in most Indian teams QA has read only access on shared environments and any write goes through a seeding script or a developer.

The SQL a manual tester should be able to write without help: SELECT with WHERE and ORDER BY, JOIN across two or three tables, GROUP BY with COUNT and SUM, LEFT JOIN with an IS NULL check for orphan detection, and date filtering. Beyond that is nice but not expected. Two cautions I would state explicitly in an interview: never write to production, and be careful about asserting on implementation details, since a case whose expected result is an internal column value the product never promised becomes a false failure the moment the schema changes.

Follow up: 'give me a bug you found only through SQL'. Have one ready. Duplicate rows from a double submit and a mismatch between the displayed and stored amount are the two most common.

VALIDATION QUERIES A MANUAL TESTER SHOULD BE ABLE TO WRITE
===================================================================
/* 1. Did the order actually write correctly? */
SELECT o.id, o.status, o.total_amount, o.payment_ref, o.created_at
FROM orders o
WHERE o.user_id = 88421
ORDER BY o.created_at DESC
LIMIT 5;

/* 2. Orphans: orders with no line items */
SELECT o.id, o.created_at
FROM orders o
LEFT JOIN order_items oi ON oi.order_id = o.id
WHERE oi.id IS NULL
  AND o.created_at >= '2026-08-17';

/* 3. Double submit: same user, same amount, within 60 seconds */
SELECT user_id, total_amount, COUNT(*) AS hits
FROM orders
WHERE created_at >= NOW() - INTERVAL 1 HOUR
GROUP BY user_id, total_amount, UNIX_TIMESTAMP(created_at) DIV 60
HAVING COUNT(*) > 1;

/* 4. GST split must equal the tax total, rounding check */
SELECT id, taxable_value, cgst, sgst, total_tax,
       (cgst + sgst) - total_tax AS drift
FROM invoices
WHERE ABS((cgst + sgst) - total_tax) > 0.01;

/* 5. Payment recorded but no order (deemed success detector) */
SELECT p.txn_id, p.amount, p.status, p.created_at
FROM payments p
LEFT JOIN orders o ON o.payment_ref = p.txn_id
WHERE p.status = 'SUCCESS' AND o.id IS NULL;

Answer

Postman turns a UI tester into someone who can test the contract rather than the rendering, and in 2026 it is close to a baseline expectation even for manual roles. What it lets you catch that the UI cannot: validation enforced only on the client, which is the big one, since a browser control that limits age to 18 to 60 tells you nothing about whether the API rejects 15, and for eligibility, pricing or role checks that is a security and compliance defect. Authorisation defects, where user A can fetch or modify user B's order by changing an id in the path, the classic insecure direct object reference, which is invisible through a UI that never renders the other user's link.

Error handling contracts, whether a failure returns a proper 4xx with a machine readable code or a 200 with an error string in the body, which is the shape that breaks clients. Field level behaviours the UI hides: extra unexpected fields, nulls versus missing keys, type coercion where a string '100' is accepted where a number was intended, and response fields the UI never displays but another consumer relies on. And it lets you reach states the UI will not offer, which is how you test invalid state transitions and expired token behaviour.

Practically I organise a collection per module, use environment variables for base URL and token so the same collection runs against QA and staging, chain requests with variables from previous responses, use the Tests tab for basic assertions on status code and key fields, and use the collection runner with a CSV data file to run the same request across 30 rows of data, which is data driven testing without writing automation. The Postman console shows the actual raw request, which settles many arguments with developers. Follow up: 'does this make you an automation engineer'. No, and I would say so, but it makes me able to prove where a defect lives instead of guessing.

POSTMAN WORKING PATTERN FOR A MANUAL TESTER
===================================================================
ENVIRONMENT VARIABLES
  base_url   https://qa2.example.in/api/v1
  token      {{login_token}}   (set by the login request)
  order_id   (set by the create order request)

REQUEST
  POST {{base_url}}/orders
  Authorization: Bearer {{token}}
  {
    "sku": "SHOE_9981",
    "qty": 1,
    "coupon": "FIRST200"
  }

TESTS TAB (assertions, JavaScript)
  pm.test("status is 201", function () {
    pm.response.to.have.status(201);
  });
  pm.test("payable is 2299", function () {
    pm.expect(pm.response.json().payable).to.eql(2299);
  });
  pm.environment.set("order_id", pm.response.json().id);

DEFECTS ONLY THE API REVEALS
  Client only validation   POST age 15 succeeds, UI blocked it
  IDOR                     GET /orders/77441 as another user, 200 OK
  Wrong status code        error returned as HTTP 200 with body error
  Type coercion            "qty": "2" accepted, stored as 2
  Silent extra field       "price": 1 accepted and honoured

DATA DRIVEN WITHOUT AUTOMATION
  Collection Runner + coupons.csv (30 rows) against one request

Answer

Translation correctness is the least interesting part, and a tester who only checks that strings changed will miss almost every real defect. Rendering first. Devanagari for Hindi and Marathi uses conjunct consonants and matras that sit above and below the base character, so a line height tuned for Latin text clips the top matra, and letters like क्ष and त्र render as boxes or broken glyphs if the bundled font lacks the conjunct.

Tamil has its own script with long words that break fixed width buttons. So I check every screen for clipping, truncation with an ellipsis in the middle of a word, overlapping lines, and tofu boxes indicating a missing glyph, and I check on real Android devices from multiple OEMs because the system font differs. Text expansion is the second class: Hindi and Tamil strings are frequently 20 to 40 percent longer than English, which breaks buttons, tabs, table headers and single line labels.

Third, mixed content, since Indian UI is rarely pure, a Hindi sentence with an English brand name, a rupee amount and a date in it, and the layout must handle the mix. Fourth, formatting: the Indian digit grouping is lakh and crore based, so 1234567 should render as 12,34,567 and not 1,234,567, currency symbol placement, date format ambiguity between DD/MM and MM/DD, and whether numerals stay Latin or become Devanagari. Fifth, pluralisation and gendered phrasing, which naive string concatenation gets wrong, and partially translated screens where a fallback English string appears mid sentence.

Sixth, functional behaviour under locale change: switching language mid session, whether the choice persists after logout and reinstall, whether search works with Indic input, whether sorting is correct, and whether SMS, push notifications and PDF invoices are also localised, which is the most commonly missed surface. Follow up: 'how do you test a language you do not read'. With a native speaker or the vendor's glossary for correctness, while I own rendering, layout, formatting and functional behaviour.

Answer

Automated scanners such as axe or Lighthouse catch perhaps a third of WCAG issues, mostly the mechanical ones like missing alt text, missing form labels and colour contrast ratios, so they are a first pass and not a verdict. The manual pass rests on four checks a tester can do without specialist training. Keyboard only navigation: unplug the mouse and complete the primary flow using Tab, Shift Tab, Enter, Space and arrows.

What you find is unreachable controls, custom dropdowns and modals built from div elements that a keyboard cannot operate, focus that disappears with no visible indicator, focus order that jumps around because of CSS positioning, a modal that does not trap focus so tabbing walks behind the overlay, and focus that is not returned to the trigger when a dialog closes. Second, screen reader: NVDA on Windows is free, VoiceOver is built into macOS and iOS, TalkBack into Android. You are not learning to use it like a daily user, you are checking whether elements are announced with a meaningful name and role, whether an icon only button announces anything at all, whether error messages are announced when validation fails, and whether dynamic content updates are announced rather than silent.

Third, zoom and scaling: 200 percent browser zoom and 130 percent system font size on mobile, checking that content reflows rather than clipping or requiring horizontal scroll. Fourth, colour and motion: is any information conveyed by colour alone, for example a red border with no error text, and can motion or autoplaying carousels be paused. Structural checks worth adding: heading hierarchy, image alt text that is meaningful rather than 'image1.png', and a form where every input has a programmatically associated label.

In the Indian market the compliance driver is usually the RPwD Act and government or banking clients requiring WCAG 2.1 AA. Follow up: 'give me one accessibility bug you found', so keep the keyboard trap or the unlabelled icon button example ready.

Answer

This is a risk based testing and communication question, and the panel wants to see judgement, not heroics. First, I stop treating the remaining 30 percent as a uniform block and re rank it by risk, which is likelihood of failure multiplied by impact of failure. Likelihood comes from what changed in this release, defect density history per module and code churn.

Impact comes from usage volume, revenue exposure and regulatory or reputational cost. Payments, login and checkout outrank the settings page regardless of how many cases each has, so I might execute 12 percent of the remaining cases and cover 80 percent of the risk. Second, I stop counting cases as the progress metric and switch to risk coverage, because '70 percent executed' is a number that has misled every manager who has ever received it.

Third, the three open high severity defects each get a decision, not a status: fix now, fix with a workaround documented for support, feature flag the affected path off, or ship with a stated risk. Getting those four options in front of the product owner is my job. Fourth, I look for containment rather than more testing, since two days is not enough to test my way to confidence: can this go out to 5 percent of users first, is there a kill switch, is rollback tested and how long does it take, is there monitoring and alerting on the affected flow so we detect it in minutes rather than from a support ticket on Monday.

A tested rollback plan is worth more than 200 extra executed cases on a Wednesday. Fifth, I write the risk statement, one page, what is covered, what is not, the open defects and their user impact, the mitigations, and my recommendation. Then the business decides.

Follow up: 'do you have the authority to stop a release'. No, and I would not want it. I have the authority to make sure nobody can say they were not told.

Answer

The metrics worth reporting are the ones that describe risk and process health rather than individual output. Defect Removal Efficiency is the headline one: defects found internally divided by the total of defects found internally plus defects found after release, expressed as a percentage. If QA found 180 defects and production surfaced 20 in the support window, DRE is 180 divided by 200, so 90 percent.

Defect leakage is the complement view, defects that escaped to the next phase or to production divided by total defects, and phase wise leakage is more actionable, because knowing that 40 percent of your defects were injected in requirements but caught in system testing tells you to invest in requirement reviews. Defect density per module or per KLOC identifies where risk concentrates. Reopen rate signals fix quality or unclear reports.

Test execution progress and pass rate are for the sprint, not for judging people. Defect ageing and the count of open critical defects by day are what a release manager actually needs. And severity distribution over time shows whether the product is stabilising.

The dangerous ones, which I would say plainly because panels respect it: bug count per tester, which incentivises splitting one defect into five and rewards the tester on the noisiest module; test cases written per day, which produces bloated unreviewable suites; and pass percentage as a target, which quietly discourages finding defects. Any metric that becomes a target for an individual stops measuring what it measured. I would also caution that DRE needs a defined production window, usually 30 or 90 days, or the number is not comparable release to release.

Follow up: 'your DRE dropped from 92 to 78 this quarter, what do you investigate'. Not tester performance. Release scope and churn, whether regression coverage kept up with new features, environment differences between QA and production, and whether escaped defects cluster in one module or one defect type, because the cluster names the fix.

QA METRICS WORTH REPORTING
===================================================================
Defect Removal Efficiency (DRE)
  DRE = internal defects / (internal + post release) x 100
  Example: 180 / (180 + 20) x 100 = 90%
  Needs a fixed production window (30 or 90 days) to compare.

Defect Leakage
  Leakage = defects found in later phase / total defects x 100
  Phase wise leakage is the actionable version:
    injected in requirements, caught in system testing = 40%
    > invest in requirement reviews, not in more execution

OTHERS
  Defect density        defects / module (or per KLOC)
  Reopen rate           reopened / total fixed
  Defect ageing         days open, by severity
  Open criticals by day the release manager's real number
  Severity distribution over time, is the product stabilising

DANGEROUS METRICS (say this out loud in an interview)
  Bugs found per tester      > rewards splitting one bug into five
  Test cases written per day > produces bloated unreviewable suites
  Pass percentage as target  > discourages finding defects

Answer

The framing matters: the question is not 'who missed it' but 'why was it possible to miss it', and any RCA that ends with a person's name has failed. I run it in five parts. First, the timeline: when the defect was introduced, which build and which change, when it reached production, when it was detected, and how, by monitoring or by a customer, because detection by a customer is itself a finding.

Second, the technical cause: what the code or configuration actually did wrong. Third, the escape analysis, which is the QA specific part and the one people skip. There are only a handful of reasons a defect escapes, and naming which one applies is the whole value of the exercise: the scenario was not in scope because the requirement never existed, the case existed but was not selected in the regression cut, the case existed and was executed but the expected result was wrong or ambiguous, the case could not be executed because the environment or data could not represent the production condition, or it was a genuinely unforeseeable combination.

Each of those has a different fix, and they are not interchangeable. A missing requirement is fixed by better grooming, a bad regression cut is fixed by changing selection criteria, an environment gap is fixed with test data or infrastructure investment, not by telling testers to be more careful. Fourth, five whys or a fishbone to get past the first plausible answer, because 'the tester did not test it' is never a root cause.

Fifth, the actions, and each must be specific, owned and dated: add the scenario to the regression suite, which is the minimum and often the only action a weak RCA produces, plus the systemic change, and a check for the same defect class elsewhere in the product, because if one date field mishandles the financial year end, the other eleven probably do too. Follow up: 'what if the RCA says QA did miss it'. Then say so, and still identify what made missing it likely.

Answer

You scale by changing what you spend your time on, not by working faster. Five moves, roughly in order of impact. First, shift left: the highest return hour I spend is in grooming, making acceptance criteria testable and raising edge cases before code exists, because a defect prevented there costs nothing to retest.

If eight developers each build from vague criteria, my week is spent on rework I could have prevented in an hour. Second, push testing into the team: developers write and own unit and integration tests, and I review the test cases in the pull request the same way they review code, which is a far better use of my time than manually re executing what a test could cover. I also run a bug bash before major releases so eight people test for an hour instead of one person testing for a day.

Third, automate the repetitive layer, or get it automated: the smoke suite in CI so no build reaches me broken, and the stable data driven regression cases. If I cannot write it myself, I specify it precisely and a developer implements it, and specifying it well is a QA skill. Fourth, invest in test data and environment, because in most small teams the single largest hidden cost is setup, and a seeding script or a reset endpoint that turns 20 minutes of clicking into 20 seconds pays for itself in a week.

Fifth, be explicit about coverage rather than pretending to cover everything: a risk based cut, published, with what is not covered stated. The failure mode for a solo QA is quietly absorbing the gap until something escapes, and then owning the blame for a structural problem. Follow up: 'what do you stop doing'.

Exhaustive documentation of everything I test, per sprint test plans, and manual re execution of anything stable and automatable. Those go first.

Answer

The honest position: repetitive scripted execution is being automated, and that is a good thing, but the activity being replaced was never the valuable part. What automation cannot do is decide what is worth testing, judge whether a behaviour is acceptable to a user, explore a system with a hypothesis, understand that an insurance product's premium rounding has a regulatory implication, or argue a severity call with a product owner. Automation executes checks that a human decided on.

In 2026 AI tools have added real capability, generating test cases from a user story, self healing locators, visual comparison, and log clustering to triage failures. They have also produced a specific new failure mode: plausible looking generated test cases that miss the domain rules entirely, which means reviewing and correcting generated tests is now a genuine part of the job. The roles that are shrinking are the ones that were only click and compare.

The roles growing are the ones that combine domain judgement with enough technical range to work at the API and data layer. On the transition, the sequence that works in the Indian market: keep your domain depth, which is your actual differentiator, and add technical skills in order, SQL first because it pays off immediately in your current job, then API testing with Postman, then a programming language, Java or Python or JavaScript depending on what your company uses, then a framework, Selenium with TestNG remains the default in service companies while Playwright and Cypress dominate product companies, then CI with Jenkins or GitHub Actions. Do it on your current project, automating your own regression suite, because a portfolio built on real work beats a certificate. On money: the automation premium in India is real, commonly 30 to 60 percent over the same experience level in manual, and the jump usually comes with a company change rather than an internal role change, so time the switch after you have shipped a working suite you can talk about in detail.