Software Testing Interview Questions and Answers

Answer

Verification failed to catch nothing here, verification succeeded. Validation is what failed. Verification asks 'are we building the product right', meaning does the software match the documented requirement, the design and the specification.

Validation asks 'are we building the right product', meaning does the software actually solve the user's problem. A suite that passes 100 percent proves the build matches the spec you were given. If UAT rejects it, the spec itself was wrong, incomplete, or the business changed its mind and nobody updated the BRD.

Verification activities are largely static: requirement reviews, design walkthroughs, code reviews, checking a test case against an acceptance criterion. Validation activities are dynamic: executing the system, UAT, beta testing, usability sessions with actual users. A practical example from an Indian ecommerce project: the requirement said 'display delivery date on product page'.

You verify the date renders, formats correctly, matches the API. Validation catches that the business wanted the date in the local pin code context, and Bengaluru users are seeing a Delhi warehouse promise. The verification passed, the product is still wrong.

What the interviewer is probing is whether you treat requirements as infallible. The senior follow up is almost always 'so how do you catch a validation gap earlier than UAT'. The answer is requirement review with the three amigos before development starts, asking 'how will a user actually do this' at grooming, and demoing to a real business stakeholder at the end of every sprint rather than at the end of the release.

Answer

Black box testing means you work only from the requirement and the interface. With a payments API and no source, you design from the contract: valid and invalid amounts, missing fields, wrong content type, expired tokens, duplicate idempotency keys, currency mismatches. Your techniques are equivalence partitioning, boundary value analysis, decision tables and state transition, because those are the only ways to cover a large input space without seeing the code.

White box testing means you can see the implementation, so you test structure: statement coverage, branch coverage, path coverage, exception handlers that nobody ever triggers, and the specific if condition that checks a refund window. Unit tests written by developers are white box by definition. Grey box is the practical middle ground and it is what most working QA engineers actually do.

You have partial knowledge: the database schema, the API contract, the log format, maybe the state machine. That lets you design smarter black box cases and then verify the side effects nobody sees from the UI. On a payment flow, grey box means clicking pay in the app and then checking that the transactions table wrote a single row with status PENDING, that the webhook handler flipped it to SUCCESS, and that a retry did not create a second row.

What the panel is checking is whether you understand that these are levels of information, not job titles. The follow up is usually 'give me a bug only grey box would find'. Orphaned rows after a failed transaction, a stale Redis cache still serving the old wallet balance, and a log that silently swallows an exception are all good answers.

Answer

Smoke testing is a wide and shallow check that the build is stable enough to test at all. It touches every critical path once: app launches, login works, search returns results, add to cart works, checkout page loads, payment gateway opens. It is not looking for defects, it is answering a single question, do we accept this build.

If smoke fails you reject the build back to the developer rather than spending the evening logging thirty defects from a broken deployment. Sanity testing is narrow and deep. A specific fix or a small change has landed, so you verify that area and its immediate neighbours in detail, then stop.

Sanity is usually unscripted and done by whoever knows that module. In the 6pm to 10pm window the honest sequence is: run smoke first, ten to fifteen minutes, ideally automated in CI so it runs the moment the build is deployed. If smoke passes, run sanity on whatever changed in this build, then a risk targeted subset of regression on the modules that touch the change.

You do not run the full regression pack in four hours if it takes eight. What the panel is really testing is whether you can sequence work under time pressure and whether you know when to reject a build instead of absorbing the pain. The follow up question is often 'smoke passed but the payment module is broken, what went wrong with your smoke suite'. The answer is that the smoke suite was checking that the page loads rather than that a transaction completes, so the check was too shallow for a revenue path.

Smoke suite, build acceptance, target under 12 minutes
1. App launches on Android 11 low end device, no crash
2. Login with valid credentials, session token issued
3. Home feed renders at least one job card
4. Search returns results for a common keyword
5. Open job detail, Apply button enabled
6. Checkout page loads and Razorpay widget initialises
7. Logout clears session
Result gate: any failure equals build REJECTED, no further testing

Sanity, after a fix lands on the coupon module
1. Apply valid coupon, discount correct
2. Apply expired coupon, correct error text
3. Apply coupon then remove it, total recalculates
4. Coupon plus wallet combination, precedence correct
Scope stops at the coupon module and the cart total it feeds

Answer

Retesting means executing the exact steps from the defect report on the new build to confirm the fix works. It is targeted, it always uses the same data and environment described in the ticket, and it can never be skipped, because the whole point of moving a defect to Verified is that someone reproduced the original failure and now cannot. Retesting is also never automated first, since the case may not exist in the suite yet.

Regression testing means checking that this fix did not break anything else. It is broad, it uses existing test cases, and it is the natural home for automation because the same cases run over and over across builds. The difference matters in scheduling: retesting is always on failed cases, regression is always on passed cases.

A concrete example. You logged that the coupon discount was applied before GST instead of after. The developer changes the order of operations.

Retesting means applying that coupon on that cart and checking the total. Regression means checking the cart with no coupon, with a wallet payment, with a partially refunded order, and the invoice PDF that reads the same total, because the change touched a shared calculation. You can defer regression scope based on risk, but you cannot skip it entirely on a shared component.

What the panel is probing is whether you understand blast radius. The classic follow up is 'how do you decide how much regression a one line fix needs'. Answer with impact analysis: ask the developer which files and shared modules changed, then map those to features, rather than guessing from the ticket title.

Answer

STLC has six phases and each has real gates, not ceremonial ones. Requirement analysis: entry is a groomed user story with acceptance criteria, exit is a signed off list of testable requirements plus a logged list of ambiguities. If a story says 'search should be fast' you raise it here, not in the last week.

Test planning: entry is the finalised scope, exit is a plan naming scope, out of scope, effort estimate, environment needs, roles and the risk list. In a sprint this is often half a page, not an IEEE document. Test case design: entry is the approved requirements, exit is reviewed test cases plus test data identified and the requirement traceability matrix updated.

Peer review of test cases matters here, an unreviewed suite is where coverage gaps live. Test environment setup: entry is hardware, build and access requests raised, exit is a smoke test passing on the environment. This phase runs in parallel with design and is the single most common cause of a delayed test start on Indian service projects, because access and data provisioning go through a ticket queue.

Test execution: entry is a build deployed and smoke passed, exit is all planned cases executed, all high severity defects closed or formally deferred, and the RTM showing full coverage. Test closure: entry is exit criteria met, exit is a summary report with metrics such as defect density, defect leakage and pass percentage, plus a lessons learned note. The follow up a panel asks is 'what do you do when entry criteria are not met but the manager insists you start'. You start with a written risk note listing what is untestable, and you record it in the daily status mail.

Phase | Entry criteria | Exit criteria
Requirement analysis | Groomed story with acceptance criteria | Testable requirement list, ambiguities logged
Test planning | Scope frozen for the sprint | Plan with scope, estimate, risks, environment needs
Test case design | Requirements approved | Cases peer reviewed, RTM updated, test data ready
Environment setup | Access and build requests raised | Environment smoke passes
Test execution | Build deployed, smoke green | All cases run, S1 and S2 closed or deferred with sign off
Test closure | Exit criteria met | Summary report, metrics, retro actions

Answer

In Waterfall, testing is a phase at the end. Requirements, design, build, then test, then release. QA is idle for weeks then compressed into a squeeze at the end, and every defect found is expensive because the design is frozen.

Waterfall still exists in Indian projects with government clients and in banking maintenance work where the change window is regulatory. In the V-model, testing is not a phase, it is a mirror. Every development stage on the left has a corresponding test stage on the right: business requirements map to acceptance testing, system requirements map to system testing, high level design maps to integration testing, low level design maps to unit testing.

The key insight, and the one interviewers want, is that the test planning for each level starts at the same time as the corresponding development stage, so acceptance test planning starts while the BRD is being written. It is still sequential in execution, so the same late feedback problem applies, but test design happens early. In Agile, testing is continuous and lives inside the sprint.

Testers are in grooming, they write acceptance criteria with the developer and the product owner, automation runs on every commit, and Definition of Done includes tested. There is no separate test phase, and the tester is judged on preventing defects, not just finding them. Most Indian teams in 2026 run a hybrid: Agile ceremonies with a hardening or regression sprint before a big release, and a UAT phase that is basically waterfall because the client insists. Answer honestly about what you have worked in, because the follow up is always a specific ceremony question, and inventing Agile experience falls apart at 'what did you say in your last three amigos session'.

Answer

The happy path is New, Assigned, Open, Fixed, Retest, Verified, Closed. You log a defect as New. A lead or triage call assigns it, so it becomes Assigned.

The developer starts work and it goes to Open or In Progress. Once code is pushed it moves to Fixed, which means fixed in the developer's opinion, not verified. QA picks it up on the next build in the Retest state, and if the original steps no longer reproduce the failure it becomes Verified, then Closed.

If it still fails, you move it to Reopened rather than logging a new defect, because reopen counts are a real quality signal about the fix rate. The states people forget are where the interesting conversations happen. Deferred means the defect is valid but will not be fixed in this release, usually a low priority cosmetic issue, and it must have an owner and a target release or it becomes permanent backlog.

Rejected means the behaviour is as designed, and if you get rejections often it usually means you are testing against an outdated requirement. Duplicate means the same root cause is already tracked, and you link rather than close silently so the reporter can follow the original. Cannot Reproduce means the developer could not recreate it, which is not a rejection, it is a request for better information.

There is also Not a Bug or As Designed, and Needs More Info. What the panel is checking is whether you know who moves each state. QA logs, reopens, verifies and closes.

Developers move to Fixed. Only the triage call, product owner or lead should defer or reject, and QA should never close a defect it did not retest.

New
  to Assigned (lead or triage call)
    to Open or In Progress (developer)
      to Fixed (developer, code pushed)
        to Retest (QA, on next build)
          to Verified then Closed (QA)
          or to Reopened, back to Assigned

Side branches from Assigned or Open:
  Rejected or Not a Bug   works as designed, needs requirement proof
  Duplicate               link to the original ticket, do not close silently
  Deferred                valid, not this release, needs owner and target release
  Cannot Reproduce        needs logs, build number, device, video, exact data
  Needs More Info         clock stops until the reporter responds

Ownership: QA logs, retests, reopens, verifies, closes.
Developer moves to Fixed. Only triage defers or rejects.

Answer

Severity is the technical impact of the defect on the system. Priority is the business urgency of fixing it. They are set by different people: QA sets severity because it is an objective assessment of impact, and the product owner or business sets priority because it is a scheduling decision.

The classic high severity low priority case: the application crashes when a user changes the system date to the year 2038, or a report crashes for a currency that no live customer uses. The crash is severe, a total loss of function, but almost nobody will hit it, so it does not block the release. Another real one from Indian projects is a hard crash on Android 6, which is a total failure but sits under one percent of your device base.

The classic low severity high priority case is a typo in the company name on the payment page. Nothing is functionally broken, no data is lost, severity is cosmetic, but a misspelt brand name next to a card entry form destroys trust and kills conversion, so it must be fixed in the next hotfix. Same category: the wrong logo, a rupee symbol showing as a box on the checkout total, or an incorrect customer care number on the support screen.

What the interviewer is probing is whether you understand these are independent axes rather than a single ranking. The follow up is usually 'the developer wants to downgrade your S1 to S3, what do you do'. You do not argue about the label, you present evidence: how many users hit this path, whether there is a workaround, whether data is corrupted, and whether it is reproducible on the standard configuration. Severity arguments end when someone brings numbers.

Severity: technical impact, set by QA
S1 Critical  system down, data loss, no workaround
S2 Major     core feature broken, workaround is painful
S3 Minor     feature works with a defect, easy workaround
S4 Cosmetic  UI, spelling, alignment

Priority: business urgency, set by product owner
P1 Fix now, blocks release or hotfix today
P2 Fix in this sprint
P3 Fix when convenient
P4 Backlog

High severity, low priority
  App crashes on Android 6.0, 0.4 percent of installs, S1 P3

Low severity, high priority
  Company name misspelt on the payment page, S4 P1
  Rupee symbol renders as a box on the checkout total, S4 P1

Answer

A defect report exists so someone who was not in the room can reproduce the failure. The mandatory fields: a title that states the failure and the context in one line, not 'app not working'. Environment: build number, app version, device model, OS version, browser and version, network condition, and which environment, QA, staging or production.

Preconditions: the account state, the user role, whether the wallet had balance, whether the coupon was already used. Steps to reproduce numbered so tightly that a new joiner can follow them, with the exact test data, including the actual phone number, order ID and amount used. Expected result taken from the requirement, with the requirement or story ID referenced.

Actual result described precisely, including any error text or code. Then evidence: screenshot with the timestamp visible, a short screen recording for anything intermittent, the API request and response, and the relevant log excerpt or trace ID. Finally severity, priority proposal, module and reproducibility rate, meaning how many attempts out of how many reproduced the issue.

That last field is what stops the Cannot Reproduce ping pong. The panel is checking whether you write for the reader or for yourself. The follow up is usually 'what would you add for a mobile only intermittent crash'. Add the crash log from Firebase Crashlytics or the adb logcat excerpt, the device RAM and free storage, whether it happens on cold start or warm start, and the exact time of the crash so the developer can find it in the log aggregation tool.

Title: Checkout, wallet balance not deducted when UPI payment fails and user retries

Module: Payments / Checkout
Build: 4.18.2 (build 2216), QA environment
Device: Redmi 10, Android 11, 3GB RAM, Jio 4G, 1 bar
Severity: S2  |  Suggested priority: P1  |  Reproducible: 4 of 5 attempts

Preconditions:
  Logged in as 98XXXXXX21, wallet balance 250, cart total 899

Steps:
  1. Add job boost plan to cart, total shows 899
  2. Tap Pay, choose Wallet 250 plus UPI 649
  3. On the UPI collect request, let it time out (do not approve)
  4. Return to app, tap Retry payment

Expected: Wallet balance restored to 250 before the retry begins
Actual: Wallet shows 0, retry asks for the full 899

Evidence: video 0:42 to 1:10, API log trace-id a91f22, logcat attached

Answer

Equivalence partitioning divides the input domain into classes where every value in a class should be handled identically by the software, so testing one representative value from a class gives you the same information as testing all of them. For an age field accepting 18 to 60, the partitions are: one valid class, 18 to 60, and two invalid numeric classes, below 18 and above 60. That gives three cases: 35 as valid, 12 as invalid low, 75 as invalid high.

But the domain is not only numeric, and this is where candidates stop too early. You also have non numeric invalid classes: alphabetic input, special characters, decimals such as 25.5, negative numbers, zero, blank, and a value beyond the field length such as a 12 digit number. Each of those is a distinct handling class, so a realistic total is around eight to ten cases rather than three.

The reason not to test more is combinatorial economy. Testing 19, 20, 21, 22 and 23 gives no additional information if they all run through the same validation branch, and a suite full of redundant cases costs execution time forever without raising coverage. The point of the technique is defensible reduction, you can show why a case was left out.

The panel almost always follows with 'so which values are you missing'. The honest answer is the boundaries, because equivalence partitioning alone would happily pick 35, 12 and 75 and never touch 17, 18, 60 or 61, which is exactly where off by one defects live. That is why equivalence partitioning is always paired with boundary value analysis, never used alone.

Field: age, accepts integers 18 to 60 inclusive

Class                     Representative   Expected
Valid range               35               Accepted
Invalid, below range      12               Error: minimum age is 18
Invalid, above range      75               Error: maximum age is 60
Non numeric alphabetic    abc              Error or input blocked
Special characters        @#               Error or input blocked
Decimal                   25.5             Error, integers only
Negative                  minus 5          Error
Zero                      0                Error
Blank                     empty            Error: age is required
Overlong                  123456789012     Truncated or blocked at maxlength

10 cases replace thousands of possible inputs, each one
defensible because it represents a distinct handling class.

Answer

Boundary value analysis exists because defects cluster at the edges of a partition, not in the middle. Developers write greater than instead of greater than or equal, loops run one iteration too many, and validation copies the wrong constant. Two value BVA tests the boundary value and the value just outside it: for a range of 18 to 60 that is 17, 18, 60, 61, four cases.

Three value BVA also tests the value just inside: 17, 18, 19, 59, 60, 61, six cases. Two value is the standard in most commercial projects because it catches the same off by one defects at two thirds the cost. Three value is used in safety critical, medical and avionics work where the extra confidence is worth the cost.

In practice you combine BVA with equivalence partitioning: three representative values from the partitions plus four boundary values gives a suite of around seven to nine cases that is genuinely defensible. The technique generalises well beyond numbers, and that is the part interviewers reward. String length fields have boundaries too: a name field with maxlength 50 needs 0, 1, 49, 50 and 51 characters.

Arrays and lists have boundaries: an empty cart, one item, the maximum item count, one over. Dates have boundaries: the last day of a month, 29 February in a leap year, the financial year rollover on 1 April which matters for GST invoices in India. File uploads have a size boundary: a 5MB limit needs a file at 5MB exactly, one byte under and one byte over.

The follow up you should expect is 'what if the boundary is not documented'. Then you have found a requirement gap and you log it before writing any case.

Range: 18 to 60 inclusive

Two value BVA (4 cases, industry standard)
  17  invalid, just below minimum
  18  valid, minimum
  60  valid, maximum
  61  invalid, just above maximum

Three value BVA (6 cases, safety critical)
  17, 18, 19, 59, 60, 61

Boundaries beyond numeric ranges
  Name field maxlength 50   0, 1, 49, 50, 51 characters
  Cart item limit 10        0, 1, 10, 11 items
  Upload limit 5MB          5MB minus 1 byte, exactly 5MB, 5MB plus 1 byte
  OTP validity 30 seconds   29s, 30s, 31s after issue
  Financial year            31 March 23:59, 1 April 00:00 IST

Answer

A decision table is the right technique when the output depends on a combination of conditions rather than a single input, which is exactly the case for pricing, eligibility and permission logic. You list the conditions as rows, enumerate the combinations as columns, and write the expected action for each column. With three binary conditions you get eight combinations, which is small enough to test exhaustively.

The value of the technique is not the table itself, it is what building the table exposes. Almost every time you draw one for a real requirement you find a combination the specification never mentioned, and that requirement gap is worth more than the test cases. A worked example: conditions are 'is a premium customer', 'cart value above 1000' and 'valid coupon applied'.

When you fill in the actions, the business realises it never decided whether a premium discount stacks with a coupon discount, and you have found the defect before a line of code exists. Once the table is complete you can reduce it. If a condition is irrelevant for some rows, mark it as a dash for do not care and merge those columns, which is how a table with sixteen combinations collapses to nine real cases.

Rules for using it well: keep the conditions independent, express each condition as a true or false or a small enumerated set rather than a free range, and add an infeasible marker for combinations that cannot occur so nobody wastes time trying to create them. The interviewer's follow up is typically 'what if there are eight conditions'. Then a full table has 256 columns, so you either split the table by sub feature or you switch to pairwise testing.

Conditions                    R1  R2  R3  R4  R5  R6  R7  R8
Premium customer              Y   Y   Y   Y   N   N   N   N
Cart value above 1000         Y   Y   N   N   Y   Y   N   N
Valid coupon applied          Y   N   Y   N   Y   N   Y   N

Actions
Premium 10 percent            X   X   X   X
Bulk 5 percent                X   X           X   X
Coupon value applied          X       X       X       X
Free shipping                 X   X           X
No discount                                                X

Gap found while building the table:
R1 and R3, does the premium discount stack with the coupon?
The requirement never said. Raise it before development starts.

Answer

A test scenario is a one line statement of what to test, written from the user's point of view, with no steps. 'Verify a user can apply to a job with an existing resume' is a scenario. It exists so that coverage can be reviewed quickly with a business stakeholder who will never read 200 test cases.

Scenarios are what you map into the traceability matrix against requirements. A test case is the executable unit: an ID, the scenario it belongs to, preconditions, test data, numbered steps, expected result and an actual result column filled during execution. One scenario usually explodes into five to fifteen test cases covering positive paths, negative paths, boundaries and permissions.

A test script is the automated implementation, code in Selenium with Java, Playwright with TypeScript, Cypress, RestAssured or Karate, that performs those steps without a human. Some older services documentation uses script to mean a very detailed manual step listing, so it is worth clarifying which sense the interviewer means rather than assuming. The reason a lead asks for scenarios first is sequencing: scenarios can be reviewed and signed off within a day, and reviewing them catches missing coverage before you invest two days writing detailed cases against a wrong understanding.

The follow up question is usually 'how many test cases per scenario is right'. There is no fixed number, but if a scenario yields one case it was probably written as a case, and if it yields fifty it was probably an epic that should be split. What the panel is checking is whether you understand the review economics, not whether you can recite three definitions.

Scenario TS_APPLY_01
  Verify a jobseeker can apply to a job using a previously uploaded resume

Test cases derived from it
  TC_APPLY_01  Apply with a valid saved resume, application appears in My Applications
  TC_APPLY_02  Apply when no resume is saved, upload prompt appears
  TC_APPLY_03  Apply to the same job twice, duplicate blocked with correct message
  TC_APPLY_04  Apply with an expired job posting, job closed message
  TC_APPLY_05  Apply while logged out, redirected to login and returned to the job
  TC_APPLY_06  Apply with a 5MB resume, accepted at the limit
  TC_APPLY_07  Apply on 2G, spinner state and no double submit on retry

Test script = the automated implementation of TC_APPLY_01
in Selenium, Playwright or Cypress.

Answer

They are different documents with different lifespans. A test strategy is organisation or product level, largely static, and describes how testing is done here: the levels of testing performed, the entry and exit criteria standards, the automation approach and tool stack, the defect severity definitions, the environments, the roles, and the risk approach. It is written once by a test manager or QA head and changes maybe twice a year.

A test plan is project or release specific and derived from the strategy. It answers what, when, who and how much for this release: scope in and out, features to be tested, test approach for this release, deliverables, schedule, effort estimate, resource allocation, environment requirements, entry and exit criteria for this release, suspension and resumption criteria, risks with mitigations, and dependencies. IEEE 829 is the classic structure people quote in interviews and it lists test plan identifier, introduction, test items, features to be tested, features not to be tested, approach, item pass fail criteria, suspension criteria, test deliverables, testing tasks, environmental needs, responsibilities, staffing and training, schedule, risks and contingencies, and approvals.

Naming a few of those sections precisely lands well in a services company interview because the process documentation there really does follow that shape. What the panel wants to hear is that you know features not to be tested is a real section with real value, because writing down what you are not testing is how you protect yourself when a defect surfaces in that area later. The follow up is often 'what changes in Agile'. The plan shrinks to a one page test approach per epic, the strategy survives unchanged, and suspension criteria become a slack message rather than a signed document.

TEST STRATEGY (org level, static, owned by QA head)
  Testing levels performed and by whom
  Standard entry and exit criteria
  Severity and priority definitions
  Automation approach and tool stack
  Environment and test data policy
  Defect management process and triage cadence

TEST PLAN (release level, IEEE 829 style)
  1. Test plan identifier
  2. Introduction and objective
  3. Test items (build, modules, versions)
  4. Features to be tested
  5. Features NOT to be tested (with reason)
  6. Approach
  7. Item pass / fail criteria
  8. Suspension and resumption criteria
  9. Test deliverables
 10. Environmental needs
 11. Responsibilities, staffing, training
 12. Schedule and estimate
 13. Risks and contingencies
 14. Approvals

Answer

An RTM is a table that maps each requirement to the test cases that cover it, and usually onward to the defects raised against it. Forward traceability goes requirement to test case and proves coverage, that every requirement has at least one case. Backward traceability goes test case to requirement and proves relevance, that you are not spending execution time on cases nobody asked for, which is a real problem in long lived maintenance suites.

Bidirectional traceability is both, and that is what an audit or a client quality review actually asks for. The columns you need are requirement ID, requirement description, the test scenario or case IDs covering it, execution status, defect IDs raised, and current defect status. That last pair is what turns the RTM from a documentation exercise into a release decision tool, because you can look at one row and say requirement PAY_03 is covered by six cases, five passed, one failed, and defect BUG_412 is still open, so this requirement is not release ready.

The practical uses that impress a panel: impact analysis when a requirement changes, because you can immediately list which cases must be updated, and gap analysis, because any requirement row with an empty test case cell is uncovered scope. In tooling terms, JIRA with Xray or Zephyr generates this automatically from issue links, and Azure DevOps does it from requirement to test case links, so in a modern shop you are configuring the link types rather than maintaining a spreadsheet. Expect the follow up 'what does an RTM not tell you'.

It does not tell you the tests are good. A requirement covered by one weak happy path case shows as fully covered and is not.

Req ID   Requirement                    Test cases           Status        Defects
PAY_01   User can pay by UPI            TC_101 to TC_106     6 pass         none
PAY_02   User can pay by card           TC_107 to TC_112     5 pass 1 fail  BUG_398 open
PAY_03   Wallet reverses on failure     TC_113 to TC_118     5 pass 1 fail  BUG_412 open
PAY_04   GST shown separately           TC_119, TC_120       2 pass         BUG_377 closed
PAY_05   Invoice emailed within 5 min   (none)               NOT COVERED    gap

PAY_05 with an empty test case column is the finding.
That single blank cell is why the client asked for the RTM.

Answer

Static testing means examining work products without executing them: requirements, design documents, test cases, code and even configuration files. It is the cheapest defect detection there is, because a requirement defect caught at review costs almost nothing and the same defect caught in production can cost a hundred times more in fix, retest, release and reputation. Static testing splits into reviews, which are human, and static analysis, which is tool driven through linters, SonarQube, and security scanners that flag hardcoded credentials or SQL string concatenation.

Review types, from least to most formal. An informal review is a colleague reading your work with no process and no records, useful and very common. A walkthrough is led by the author, who steps the group through the document to build shared understanding and gather feedback, with no formal entry criteria and optional records.

A peer review or technical review is led by a trained moderator or technical peers rather than the author, focuses on technical correctness and alternatives, and produces logged findings. An inspection is the most formal: a defined moderator, defined roles including reader, author, scribe and reviewers, entry and exit criteria, checklists, individual preparation before the meeting, metrics collected on defects found per hour, and a formal follow up on rework. Inspections come from Fagan's method and still appear in regulated Indian projects in banking and defence. The point a panel wants you to reach is that QA participates in requirement reviews, and the defects you prevent there never appear in your defect count, which is why review participation is undervalued and worth mentioning as something you did.

Answer

Positive testing confirms the system works as intended with valid input on the expected path: enter a registered 10 digit Indian mobile number, receive an OTP, enter the correct six digit code within the validity window, land on the home screen with a valid session. Negative testing confirms the system fails gracefully with invalid input and hostile conditions. The obvious negatives are wrong OTP, expired OTP, blank OTP, alphabetic OTP and an unregistered number.

What candidates miss is everything that is not a field value. Rate limiting: request an OTP ten times in a minute and check that the system throttles rather than spending your SMS budget. Reuse: enter a correct OTP, then use the same OTP again for a second session, it must be single use.

Race: request a second OTP and then enter the first one, decide which is valid and test it deliberately. Lockout: enter a wrong OTP five times, the account should lock or a captcha should appear, and you must test the unlock path too. Input handling: paste an OTP with a leading space, autofill from the SMS reader, leading zeros in the OTP surviving as a string rather than being parsed as a number.

Session: complete login on device A, then check whether device B's session is invalidated according to the requirement. Network: kill connectivity mid verify and check for a double submit on retry. Security: is the OTP visible in the API response body, a real defect that shows up in Indian apps more often than it should, and is the mobile number enumerable through a different error message for registered versus unregistered numbers. The follow up is usually 'which of these would you automate', and the honest answer is the deterministic ones, leaving the SMS delivery dependent paths to manual or a test number with a fixed OTP.

Positive
  P1 Registered number, correct OTP within 30s, session created
  P2 OTP autofilled from SMS, login succeeds
  P3 Resend after cooldown, new OTP works

Negative, field level
  N1 Wrong OTP, correct error, attempt counter increments
  N2 Expired OTP (31s), rejected
  N3 Blank, alphabetic, 5 digit and 7 digit OTP
  N4 Unregistered number
  N5 Number with country code, spaces, plus 91 prefix variants

Negative, the ones candidates miss
  N6 Same OTP used twice, second attempt rejected
  N7 10 OTP requests in 60 seconds, rate limit enforced
  N8 Request OTP twice, first OTP now invalid per requirement
  N9 5 wrong attempts, lockout plus a tested unlock path
  N10 OTP present in the API response body (security defect)
  N11 Different error text for registered vs unregistered (enumeration)
  N12 Network drop mid verify, retry does not create two sessions

Answer

Functional testing asks whether the feature does what it should. Non functional testing asks how well it does it, and for a consumer app in India that is often what decides whether the product survives. Performance: response time under expected load, and specifically cold start time on a low end Android device, because an app that takes eight seconds to open on a Redmi with 3GB RAM loses users regardless of features.

Load and stress testing for a sale event or a results day traffic spike. Scalability, whether adding servers actually helps or a database lock is the ceiling. Security: authentication, authorisation, data at rest and in transit, and the OWASP basics such as insecure direct object references where changing an ID in a URL shows another user's data.

Usability: can a first time user in a tier 2 city complete the flow without instructions, and is the tap target reachable one handed. Compatibility: Android versions still in real use, screen sizes from 5 inch to tablets, and the browser mix, which in India still includes a meaningful share of older Chrome builds and in app browsers from within social apps. Reliability and recoverability: what happens when the network drops mid payment, when the app is killed by the OS during a background sync, and whether the app recovers state.

Accessibility: screen reader labels, contrast ratio, font scaling when the user has set a large system font. Localisation: does Hindi, Tamil or Bengali text render without clipping and does the layout survive longer strings. Data volume: does the list still scroll at 60fps with 5000 items. The follow up is 'which one would you cut if you had no time', and the answer that lands is that you never cut security and payment reliability on a transacting app, you cut breadth of device compatibility and cover it with a phased rollout instead.

Answer

Testing shows the presence of defects, not their absence. Decision it changes: you never write 'no bugs found, product is bug free' in a test summary report. You write coverage achieved, defects found, and known risks.

Exhaustive testing is impossible. Decision: you use equivalence partitioning, boundary values and risk based prioritisation instead of trying to test every input combination, and you can defend the cases you left out. Early testing saves time and money.

Decision: you attend requirement grooming and review acceptance criteria, because a defect found in a requirement review costs almost nothing. This is the principle behind shift left. Defects cluster.

Decision: you check the defect history by module, find that payments and search hold 60 percent of past defects, and weight your regression accordingly rather than spreading effort evenly. The pesticide paradox, running the same tests stops finding new defects. Decision: you refresh the regression suite every few releases, add exploratory sessions, and rotate who tests which module.

Testing is context dependent. Decision: your approach for a banking app with regulatory audit differs from a content app, so you do not copy a test strategy between projects. Absence of errors is a fallacy, a system with no defects can still be unusable or wrong.

Decision: you raise usability and requirement mismatch issues even when everything technically passes. What the panel is checking is whether these are memorised or operational. The strongest answer names two or three principles and immediately attaches a decision you made because of them, then offers the rest briefly. Reciting all seven verbatim with no application is a neutral answer at best.

Answer

An error, also called a mistake, is the human action that produced the problem: a developer misreading a requirement, a business analyst writing an ambiguous acceptance criterion, an architect choosing the wrong data type. A defect, also called a fault or a bug, is the resulting flaw sitting in the artefact: the wrong comparison operator in the code, the missing branch, the wrong constant, the ambiguous line in the requirement document. A failure is the observable deviation when that defect is executed under the right conditions: the app crashes, the total is wrong, the payment double charges.

The chain runs error causes defect, defect causes failure, and the last link is conditional. A defect can sit in code for years and never produce a failure because nobody hits the code path, which is exactly what happens with a leap year defect discovered every four years. The distinction matters in root cause analysis because your corrective action attaches to a different level in each case.

If the failure was caused by a coding defect from a misread requirement, adding a test case only catches the next failure, it does not stop the next error. Fixing the error means clarifying the requirement template or adding a three amigos step. That is the difference between a corrective action and a preventive action in a formal RCA, and services companies working under CMMI or ISO processes will expect you to know it.

The follow up is usually 'give me a defect that never became a failure'. Dead code with a divide by zero, an unreachable branch, or a validation that is never triggered because the UI already blocks the input are all good answers, and they lead naturally into why static analysis finds things dynamic testing never will.

Answer

Start from the purpose of each gate rather than from the test list. Smoke answers 'is this build worth anyone's time', so it must run on every commit and finish inside the time a developer will wait, which in practice is under ten minutes and ideally under five. Regression answers 'did we break something we already shipped', and it does not need to block a merge, it needs to run before a release.

So the split is by gate timing, not by importance. To build the smoke suite, take your revenue and access critical paths and pick exactly one end to end case per path: login, search, view item, add to cart, complete a payment with a test gateway, and one API health check per service. Keep it to twenty to forty cases, all fully deterministic, no dependency on external sandboxes that flake, and no data setup that can drift.

Then enforce a hard rule that nothing enters the smoke suite without something leaving, otherwise it grows into a second regression pack within six months, which is the failure mode every team hits. For the 40 minute regression, you do not shorten it by deleting tests, you shorten wall clock time: run in parallel across containers, shard by test file, use a dedicated data set per shard so tests do not collide, and split into a fast tier that runs on every merge and a slow tier that runs nightly and pre release. Add test impact analysis if your tooling supports it, mapping changed files to the tests that touch them.

The senior follow up is 'what if the 40 minutes is one slow test'. Then you profile it, and usually you find hardcoded waits, a Thread.sleep or an unconditional five second wait, and replacing those with explicit conditional waits cuts the suite dramatically without removing coverage.

Gate design

On every commit  (must finish under 5 min)
  Unit tests, static analysis, build

On every merge to main (under 12 min)
  Smoke suite, 30 UI cases plus 40 API cases
  Fast regression tier, deterministic, no external sandbox

Nightly (no time limit)
  Full regression, all browsers, all device profiles
  Long running data volume and soak checks

Pre release
  Full regression plus manual exploratory charters
  Performance baseline comparison

Rule enforced in review: one test in, one test out of smoke.
Parallelisation: 40 min serial becomes 7 min across 6 shards.

Answer

State transition testing models the system as states, events, transitions and guard conditions, then tests both the valid transitions and, more importantly, the invalid ones. Start by drawing the state table: states on rows, events on columns, cells holding the resulting state or an invalid marker. For an order, Placed plus Confirm gives Confirmed, Confirmed plus Ship gives Shipped, Shipped plus Deliver gives Delivered, Delivered plus Return within the window gives Returned, and Placed or Confirmed plus Cancel gives Cancelled.

The cells that matter most are the invalid ones: Shipped plus Cancel, Delivered plus Cancel, Returned plus Ship, and Cancelled plus anything. Those are where the defects are, because developers implement the happy transitions carefully and handle the impossible ones with an unguarded else. Coverage levels have names worth using.

Zero switch or 0 switch coverage means testing every individual valid transition once. One switch coverage means testing every valid pair of consecutive transitions, which catches defects that depend on how you arrived at a state, for example a refund that behaves differently for an order Cancelled from Placed versus Cancelled from Confirmed. Then add guard conditions: return is only valid within 7 days, cancel is only valid before dispatch, and each guard needs a boundary test at the edge of its window.

The real world dimension the panel is waiting for is concurrency and idempotency. What happens if the shipping webhook fires twice, if a cancel request and a ship event arrive within the same second, or if a delayed webhook arrives after the order was already cancelled. Those race conditions are the actual production incidents, and mentioning them separates an intermediate answer from a basic one.

Current state | Confirm | Ship | Deliver | Cancel | Return
Placed        | Confirmed | INVALID | INVALID | Cancelled | INVALID
Confirmed     | INVALID | Shipped | INVALID | Cancelled | INVALID
Shipped       | INVALID | INVALID | Delivered | INVALID | INVALID
Delivered     | INVALID | INVALID | INVALID | INVALID | Returned (within 7 days)
Cancelled     | INVALID | INVALID | INVALID | INVALID | INVALID
Returned      | INVALID | INVALID | INVALID | INVALID | INVALID

0 switch: every valid cell once, 6 tests
1 switch: every valid pair, for example Placed to Confirmed to Shipped
Guards: Return at day 7 accepted, at day 8 rejected
Races: duplicate ship webhook, cancel and ship in the same second

Answer

You use pairwise testing, also called all pairs, backed by an orthogonal array. The empirical basis is that the large majority of configuration defects are triggered by a single parameter or by the interaction of two parameters, and interactions of three or more are rare. So instead of covering every combination, you construct a set of test configurations where every pair of parameter values appears together at least once.

For 6 by 4 by 3 by 2, exhaustive is 144 runs, and a pairwise set is typically around 24 to 30 runs, an 80 percent reduction with most of the defect finding power retained. You do not build the array by hand. Microsoft PICT, ACTS from NIST, or the allpairs generators built into most test management tools take a parameter file and emit the set.

Two refinements matter in practice. First, seed the array with mandatory combinations that business reality demands, for example the single highest volume device on 4G in light theme must be tested regardless of what the algorithm chooses, and your top selling handset should appear more than once. Second, add constraints for infeasible combinations, since a device that cannot run Android 14 must not appear in a row that pairs them, and PICT supports exactly that syntax.

Then triage what pairwise cannot give you. It does not guarantee three way interaction coverage, so if you have a known defect history where a specific chipset plus a specific OS plus 2G caused a crash, you add that combination explicitly as a directed case. The follow up is 'how do you pick the six devices in the first place', and the answer must be data driven: pull the device and OS distribution from Firebase or your analytics, cover the top 80 percent of your actual install base, and add one deliberately weak device as the floor.

Parameters
  Device : RedmiNote12, RealmeC55, SamsungM14, PocoX5, iPhone13, MotoG64
  OS     : Android11, Android12, Android13, Android14
  Network: 4G, 3G, WiFi
  Theme  : Light, Dark

Exhaustive     6 x 4 x 3 x 2 = 144 runs
Pairwise set   around 24 runs, every value pair covered once

PICT model file
  Device: RedmiNote12, RealmeC55, SamsungM14, PocoX5, iPhone13, MotoG64
  OS: Android11, Android12, Android13, Android14
  Network: 4G, 3G, WiFi
  Theme: Light, Dark
  IF [Device] = "iPhone13" THEN [OS] <> "Android11";

Seed mandatory rows before generating:
  RedmiNote12, Android13, 4G, Light   (highest volume config)
  Weakest device, 3G, Dark            (deliberate floor case)

Answer

The gap is real: scripted cases only verify what someone already thought of, so they cannot find the unknown unknowns. Error guessing is experience driven test design where you deliberately attack the places defects historically live: empty and null inputs, zero and negative numbers, leading and trailing spaces, very long strings, special characters and emoji in a name field, duplicate submissions from a double tap, back button after a submit, browser refresh mid transaction, session timeout during a form, two tabs of the same flow, timezone edges around IST midnight, and any field that a developer had to parse by hand. The problem your manager has with exploratory testing is that it looks unaccountable, and the fix is session based test management.

You define a charter, one sentence stating what will be explored and with what mission. You time box it, typically 60 to 90 minutes. You take notes during the session recording what you tested, what you observed, defects logged, and questions raised.

Then you debrief with the lead, using the PROOF structure: past what happened, results what was achieved, obstacles what got in the way, outlook what remains, feelings your gut sense of the risk. This gives you a countable unit of work, session hours, and a coverage report by charter, which is what makes exploratory testing schedulable in a sprint. The metric to quote is defects per session hour, and comparing that against defects per scripted execution hour usually makes the business case for you.

A good split on a mature product is roughly 70 percent scripted regression, mostly automated, and 30 percent exploratory on the newly changed areas. The follow up is 'how do you make exploratory findings repeatable', and the answer is that any defect found in a session becomes a scripted regression case afterwards, so exploration continuously feeds the suite.

CHARTER  Explore the resume upload flow
         with corrupt and oversized files
         to discover parsing and error handling failures

Time box  90 minutes
Tester    A. Kumar        Build 4.19.0, staging

Session notes
  Tested: 0 byte pdf, 51MB pdf, .exe renamed to .pdf, password
  protected pdf, 400 page pdf, Hindi filename, emoji filename,
  double tap upload, upload then background the app

Defects: BUG_502 (0 byte pdf shows infinite spinner)
         BUG_503 (password protected pdf: raw stack trace shown)
Questions: is there a server side page limit? no requirement found

Session breakdown
  Test design and execution 65 min
  Bug investigation 20 min
  Setup 5 min

Metric: 2 defects per 1.5 session hours

Answer

First move: do not silently cut and hope. Make the reduction explicit, written, and signed off, because the point of this exercise is that the business accepts a known risk rather than discovering an unknown one. Then prioritise by risk, where risk equals likelihood of failure multiplied by business impact.

Likelihood is driven by evidence: which modules changed in this release, which modules have the highest historical defect density, which code has the newest developers on it, which areas have the most complex logic, and which have the weakest automated coverage. Impact is driven by money and reputation: payment, login, and anything that can lose or corrupt data sit at the top, followed by the core user journey, followed by admin and reporting, with cosmetic and rarely used settings at the bottom. Score each area on both axes, one to five, multiply, and sort.

Then allocate the three days: day one on the highest risk changed areas with full depth, day two on the critical unchanged paths through the automated regression suite plus a targeted manual subset, day three reserved for retesting fixes and a final smoke on the release candidate. Explicitly do not test the low risk unchanged areas and write that down in the features not tested section. Alongside this you negotiate compensating controls, which is what shows seniority: a phased rollout to five percent of users, a feature flag that lets the change be turned off without a redeploy, extra monitoring and alerting on the changed endpoints, and an agreed rollback plan with a named owner.

Then your test summary states clearly what was covered, what was not, and what the residual risk is, so the go or no go decision is the business making an informed call. The follow up is usually 'what if they refuse to accept the risk'. Then the timeline moves or the scope shrinks, and that is a project decision, not a QA decision.

Risk score = likelihood (1 to 5) x impact (1 to 5)

Area            Changed  Defect history  Likelihood  Impact  Score  Plan
UPI payment     Yes      High            5           5       25     Full depth, day 1
Login / OTP     Yes      Medium          4           5       20     Full depth, day 1
Cart and pricing Yes     High            4           4       16     Full depth, day 1
Job search      No       Medium          2           4       8      Automated regression only
Profile edit    Yes      Low             3           2       6      Happy path plus smoke
Notifications   No       Low             2           2       4      Automated only
Admin reports   No       Low             1           2       2      NOT TESTED, documented

Compensating controls agreed with product:
  5 percent phased rollout, feature flag on the pricing change,
  alerting on payment error rate, rollback owner named.

Answer

Exit criteria must be agreed before execution starts, otherwise the conversation on release night becomes a negotiation about your credibility instead of the product's readiness. A workable set: all planned test cases executed, with an execution percentage of 100 and any deviation explained. Pass rate above an agreed threshold, commonly 95 percent or higher for the release build.

Zero open critical and high severity defects in scope, with every remaining defect either closed or formally deferred with a named owner and target release. Requirement coverage complete in the RTM, no requirement with zero executed cases. Regression suite green on the release candidate build, not on an older build.

Smoke passing on the production like environment, not just on QA. Performance within the agreed baseline, no more than an agreed percentage regression on key transactions. No open showstopper in security scanning.

UAT sign off received from the named business owner. Then the release notes, known issues list and rollback plan exist and have been reviewed. When do you say no: any open critical defect on a money path, a regression suite that has never run green on this exact build, an environment mismatch where you tested a different configuration from what will ship, or a defect whose root cause is unknown even if the symptom disappeared, because an unexplained fix usually means the defect moved rather than went away.

What matters in the answer is the framing. QA does not own the go or no go decision, the business does. QA owns giving an accurate, evidence backed picture of readiness and residual risk, then stating a recommendation clearly. Saying 'I recommend not shipping, here are the three reasons and the risk if we do' is the professional position, and it is exactly what the panel is listening for.

Release readiness checklist

[ ] Planned cases executed        100 percent (deviations listed)
[ ] Pass rate                     >= 95 percent on RC build
[ ] Open S1 / S2 defects          0 in scope
[ ] Deferred defects              owner and target release recorded
[ ] RTM coverage                  no requirement with 0 cases
[ ] Regression suite              green on THIS RC build
[ ] Smoke on prod like env        green
[ ] Performance                   within 10 percent of baseline
[ ] Security scan                 no open high findings
[ ] UAT sign off                  received from named owner
[ ] Known issues + release notes  published
[ ] Rollback plan                 documented, owner named

QA states readiness and residual risk.
The business owns the go or no go call.

Answer

Defect density is defects divided by size, usually per thousand lines of code or per function point or, in a modern Agile team, per story point or per module. It tells you where quality is worst so you can target reviews and regression. Defect leakage, sometimes called defect escape rate, is defects found after release divided by total defects, expressed as a percentage.

It is the single most honest measure of how good your testing was, because it counts what you missed. Defect removal efficiency, DRE, is defects found before release divided by total defects found before plus after release, as a percentage. A mature team runs above 90 percent DRE and a strong one above 95.

Numbers for a release: 180 defects found in testing, 12 found in production in the first 30 days. DRE is 180 divided by 192, which is 93.75 percent. Leakage is 12 divided by 192, which is 6.25 percent.

If the changed code was 15000 lines, density is 180 divided by 15, which is 12 defects per KLOC. All three are gameable, and knowing how is what separates a candidate who has been measured on these from one who has read about them. Density falls if you log fewer defects, so a team punished for high density stops logging small issues and starts fixing them silently, which destroys your data.

DRE improves if you inflate the pre release count by splitting one defect into five tickets, or by logging trivial cosmetic issues in bulk. Leakage improves if production issues get classified as change requests or as enhancements instead of defects, which is extremely common. So always pair the metric with a definitions agreement and a fixed measurement window, typically 30 or 90 days post release, and review the classification of production issues in a joint call rather than letting one side label them.

Release 4.19, changed code 15,000 LOC (15 KLOC)
Defects found in testing        180
Defects found in production/30d  12

Defect density   = 180 / 15 KLOC        = 12.0 per KLOC
Defect leakage   = 12 / (180 + 12)      = 6.25 percent
DRE              = 180 / (180 + 12)     = 93.75 percent

By module, density tells you where to aim
  Payments  62 defects / 3.2 KLOC = 19.4 per KLOC  <- worst
  Search    28 defects / 4.1 KLOC =  6.8 per KLOC
  Profile   18 defects / 5.0 KLOC =  3.6 per KLOC

Gaming to watch for
  Density down because people stopped logging small defects
  DRE up because one defect was split into five tickets
  Leakage down because prod issues were relabelled as CRs

Answer

Treat Cannot Reproduce as a request for information, not as a rejection, and never reopen it with the comment 'it happens on my machine'. First, reproduce it yourself again on a fresh build in a clean environment and record the attempt rate, for example four out of six attempts. If you cannot reproduce it either, say so in the ticket, because credibility is the asset you are protecting across a whole project.

If you can, gather the delta. The usual causes of a genuine reproduction gap are environment differences: different build number, different environment where the developer tested on local with a stubbed gateway while you tested on QA with the sandbox, different data such as an account that already has a saved card, different device or OS, different network profile where your case only appears on a throttled connection, different timing where the defect only appears if you tap within two seconds, and cached state where the developer's browser had cleared local storage and yours had not. Then update the ticket with the missing dimension explicitly and add hard evidence: a screen recording with the timestamp, the exact build and commit hash, the API request and response bodies, the trace ID from your logging tool, the logcat excerpt, and the exact data records used.

Offer a joint session, fifteen minutes screen sharing, which resolves most of these faster than three rounds of ticket comments. If it truly is intermittent and low frequency, propose adding logging or an analytics event around the suspect code path so the next occurrence is captured with context rather than leaving the ticket to be closed by age. What the panel is checking is professional conflict handling. The answer they want is evidence and collaboration, and an explicit statement that you never argue about who is right, you argue about what the logs show.

Reproduction gap checklist, work down this list
  Build number and commit hash identical?
  Environment identical (local stub vs QA sandbox)?
  User account state (saved card, existing order, KYC done)?
  Test data values exactly as in the ticket?
  Device model, OS version, RAM, free storage?
  Network profile (throttled 3G vs office WiFi)?
  Timing dependent (tap within 2s, race with a webhook)?
  Cache and local storage state?
  Feature flag values for that user?
  Time and timezone of the attempt (IST midnight edges)?

Comment template
  Reproduced 4 of 6 attempts on build 4.19.2, QA env,
  Redmi Note 12 / Android 13, network throttled to 3G.
  Trace id a91f22, video attached at 0:42.
  Not reproducible on WiFi, which is likely why it did not
  reproduce locally. Happy to screen share for 15 minutes.

Answer

Triage is a short recurring call, usually daily during a release crunch, with QA, the development lead and the product owner. Each defect gets a decision and the decision has conditions attached. Deferred is right when the defect is valid, reproducible and understood, but the cost of fixing it now exceeds the cost of living with it for one release.

Before you agree to defer you insist on four things: a named owner, a target release, an agreed severity that has not been quietly downgraded to justify the deferral, and a note in the known issues list so support is not blindsided. Deferral without a target release is just a slow close, and you should say that out loud in the call. Rejected, or Not a Bug, is right when the behaviour matches the requirement.

The condition you insist on is a reference: which requirement, which acceptance criterion, which design decision. If nobody can point to it, this is not a rejection, it is an undocumented requirement and someone should write it down. If rejections are frequent in your project, that is a signal about requirement quality, not tester quality, and it is worth raising in the retro with numbers.

Duplicate is right when the root cause is the same, not merely when the symptom looks similar. Two crashes on the same screen from two different null references are not duplicates, and closing them as such loses one of them permanently. Insist on a link to the original so the reporter can follow it, and make sure the newer ticket's evidence gets copied over, since the second report often has better logs.

What the panel is checking is whether you can hold a position in a room where you are outranked. The right posture is that you present evidence and impact, you accept the business decision, and you make sure the decision and its owner are recorded.

Triage decision conditions

DEFERRED requires
  valid and reproducible, severity unchanged
  named owner + target release
  entry in the known issues / release notes
  support and CS informed if user visible

REJECTED requires
  a link to the requirement or acceptance criterion
  if none exists, convert to a requirement clarification, not a close

DUPLICATE requires
  same ROOT CAUSE, not just a similar symptom
  link both ways, merge the better evidence into the surviving ticket

JQL to audit deferrals that have gone stale
  project = APP AND status = Deferred
  AND fixVersion IS EMPTY
  ORDER BY created ASC

Answer

Backlog refinement or grooming, held mid sprint for the next sprint, is where the tester earns the most. You question acceptance criteria, ask for the negative cases, surface the combinations the story does not cover, and flag anything untestable such as 'the page should load fast'. Defects prevented here never appear in your defect count, which is exactly why this contribution gets undervalued and why you should call it out in an interview.

Sprint planning: you give the test estimate for each story, raise environment and test data dependencies early, and push back on stories that arrive without acceptance criteria. During the sprint you write test cases from the acceptance criteria while development is still in progress, share them with the developer before they finish coding so the obvious cases get handled in unit tests, then execute as each story becomes testable rather than waiting for a big drop at the end. Daily stand up: your update is about blockers and testable items, not a list of cases executed.

The three amigos conversation, business analyst plus developer plus tester on a single story, is where ambiguity dies, and it is worth naming since interviewers use it as a marker of genuine Agile experience. Sprint review or demo: you often run the demo because you know the edge cases. Retrospective: you bring the quality data, escaped defects, reopen rate, flaky test count.

Definition of Done should include: acceptance criteria met, unit tests written and passing, code reviewed, functional testing complete, regression impact tested, automation added or a ticket raised for it, no open S1 or S2 defects on the story, documentation updated, and deployed to staging. The follow up that separates candidates is 'what do you do about a story that lands on day nine of a ten day sprint'. The answer is that this is a planning problem to raise in the retro with data on how often it happens, and in the moment you test to the highest risk and state clearly what was not covered.

Answer

Shift left means moving quality activity earlier in the lifecycle instead of concentrating it in a test phase before release. The economic argument is that the cost of fixing a defect rises steeply the later it is found: a requirement ambiguity caught in a review costs a conversation, the same ambiguity caught in production costs a hotfix, a regression cycle, a support load and possibly a refund. Concretely, next Monday it means: you attend requirement grooming and review acceptance criteria before development starts, and you write them in a testable form.

You practise acceptance test driven development, agreeing the acceptance tests in Given When Then form before code is written, so the developer builds against them. You pair with developers on unit test coverage for the tricky branches, and you review their test names rather than their implementation. You add static analysis and linting to the pipeline so entire defect classes are caught at commit time.

You move API level tests to run on every pull request rather than only in the nightly regression, because API tests are fast and stable enough to gate a merge. You add contract tests between services so an integration break is caught by the producing team rather than by you three days later. You give developers a way to run the smoke suite locally before pushing.

What shift left is not: it is not testers writing code instead of testing, and it is not deleting the later stages. You still need exploratory testing, non functional testing and UAT, because those find what earlier stages cannot. The trap in the answer is treating it as a tooling change.

It is primarily a change in when conversations happen. The follow up is often 'how would you measure whether shift left worked', and the answer is a falling defect leakage rate plus a falling average time from defect introduction to detection, not a rising automated test count.

Acceptance criteria agreed BEFORE coding starts

Feature: Wallet reversal on failed UPI payment

  Scenario: UPI collect request times out
    Given a user with wallet balance 250
    And a cart total of 899
    When the user pays 250 by wallet and 649 by UPI
    And the UPI collect request times out after 300 seconds
    Then the wallet balance is restored to 250
    And the order status is PAYMENT_FAILED
    And no duplicate order row is created

  Scenario: user retries immediately after the timeout
    Given the previous payment attempt failed
    When the user taps Retry within 10 seconds
    Then the full amount of 899 is requested
    And the wallet is debited only once on success

Measure of success: falling defect leakage and falling
time from defect introduction to detection.

Answer

One hundred percent automation is not a goal, it is a symptom of someone counting tests instead of counting risk. The cases you should refuse. Tests that will run once or twice, because an automated test costs more to write and maintain than it saves unless it runs many times.

Anything that requires human judgement: visual design quality, whether a layout looks broken to a person, whether an error message actually reads as helpful, whether the flow feels confusing. Usability and exploratory work by definition. Areas under heavy churn, because automating a screen that will be redesigned next sprint is deleting your own work in advance.

Tests that depend on unstable third party sandboxes, since a payment gateway sandbox that fails randomly makes the whole suite untrustworthy and people start ignoring red builds, which is the worst outcome in automation. Anything requiring physical interaction such as a real card tap, a biometric prompt, a real SMS OTP arriving on a physical handset, or a printer. One time data migration validation, where a SQL reconciliation script is the right tool, not a UI test.

Cases whose expected result is genuinely subjective. The justification you give management is economic, not philosophical: automation ROI is the manual execution cost multiplied by the number of runs, minus the script development cost and the ongoing maintenance cost. Put maintenance at a realistic 20 to 30 percent of development effort per year and many candidate tests stop paying back.

Then redirect the ambition somewhere useful: instead of 100 percent UI automation, aim for a healthy pyramid with a large unit layer, a substantial API layer and a thin critical path UI layer, which gives faster feedback per rupee spent. The follow up is 'what percentage should be automated then', and a defensible answer is that you target coverage of the regression suite that runs repeatedly, commonly 60 to 80 percent of stable regression, and you keep exploratory and usability work firmly manual.

Do NOT automate
  runs once or twice only
  visual design and layout aesthetics
  usability and exploratory sessions
  screens under active redesign this quarter
  flows gated by unstable third party sandboxes
  physical device interactions, real SMS OTP, biometrics
  one off data migration checks (use SQL reconciliation)

Automate first
  smoke and build acceptance
  stable high frequency regression
  API and contract level checks
  data driven combinations (100 pricing permutations)
  cross browser and cross device repetition
  setup and teardown for manual testing

ROI
  saving = manual minutes x runs per year
  cost   = build effort + (0.25 x build effort per year maintenance)
  automate when saving exceeds cost within 2 to 3 releases

Answer

Sequence matters more than tool choice. Start with a feasibility assessment: is the application stable enough, is it testable with reliable locators, are there test IDs on elements or will you fight XPaths, is test data creatable through an API, and does a dedicated environment exist. If the application ships a new UI every sprint, start at the API layer instead.

Then pick the first candidates using four criteria: high repetition, meaning it runs in every regression cycle; high business risk, meaning login, search and payment; high stability, meaning the feature has not changed in three months; and high manual cost, meaning cases that are slow or tedious by hand such as 60 pricing permutations. The intersection of repetition and stability is where you start, not the newest feature. Build the smoke suite first and wire it into CI on day one, because an automated suite that nobody runs automatically is a shelfware project, and getting a green or red signal into the merge pipeline is what makes the effort visible.

Then extend into the fast regression tier. On tooling in the Indian market in 2026, Selenium with Java and TestNG remains the most demanded stack in services companies, Playwright has taken over most greenfield web automation for speed and built in waiting, Cypress is common in frontend heavy teams, Appium is the default for mobile, and RestAssured, Karate or plain Postman with Newman cover API. Choose based on the team's existing language, not on benchmarks, because a suite nobody on the team can maintain dies within two quarters.

To prove value, baseline first: record manual execution hours per regression cycle before automation, then track hours saved per cycle, defects caught by automation before manual testing started, feedback time from commit to result, and the flakiness rate. Present those four numbers to management every release. The follow up is 'what if the ROI is negative in the first quarter', and the honest answer is that it always is, automation pays back across releases, so you commit to the metric over three to four cycles.

Answer

Never copy a production dump into a test environment unmasked. Under the Digital Personal Data Protection Act obligations that Indian companies now work under, personal data in a non production environment is a compliance exposure, and practically it is how a marketing test ends up sending real SMS to real users. There are three sourcing strategies and mature teams use all three.

Synthetic generation for volume: libraries such as Faker with an Indian locale, or a custom generator, produce structurally valid data. Structural validity is the part people get wrong, and interviewers probe it. A masked PAN must still match the pattern of five letters, four digits, one letter, or your validation logic rejects it and you have not tested anything.

A masked Aadhaar must remain twelve digits and should pass the Verhoeff checksum if your application validates it, and it must never be a real number, so use the documented test ranges rather than random digits. Phone numbers should stay ten digits starting with 6 to 9 and should sit inside a reserved non routable block so no SMS ever reaches a real person. IFSC codes must keep the four letter bank code plus zero plus six characters shape.

Second, masking or anonymisation of a production subset: deterministic masking so the same input maps to the same masked output across tables, which preserves joins between a users table and an applications table. Format preserving masking so lengths and patterns survive. Full removal of anything you do not need at all.

Third, a curated golden data set for regression: a small fixed set of accounts in known states, seeded through APIs before the run and reset afterwards. The engineering rules that follow: each automated test creates and cleans up its own data so tests can run in parallel, never share a single login account across a parallel suite, and refresh the environment on a schedule so drift does not accumulate. The follow up is 'how do you test something that only reproduces with real production data', and the answer is a controlled shadow or read only production trace with logging, never a copy.

Format preserving, non routable synthetic data

Field      Real shape              Test data rule
PAN        ABCDE1234F              5 letters, 4 digits, 1 letter
                                   use prefix AAAPZ, never a real PAN
Aadhaar    12 digits, Verhoeff     use the documented test series only
Mobile     10 digits, starts 6 to 9  reserved block, no SMS gateway route
Email      user@domain             route to a catch all test inbox domain
IFSC       AAAA0123456             keep 4 letters + 0 + 6 chars
UPI VPA    name@bank               use the gateway sandbox VPA list
DOB        date                    shift by a fixed offset, keep age band

Deterministic masking keeps joins intact
  mask(9876543210) always returns 7000000123
  so users.mobile and applications.mobile still join

Automation rule: each test seeds its own data via API in setup
and deletes it in teardown, so the suite can run in parallel.

Answer

UAT is validation by the business, not another round of system testing by QA. The users execute real business scenarios in a production like environment with production like data to confirm the system supports their actual work. Your role is to enable and facilitate, not to execute: prepare the UAT environment, ensure the build is the release candidate, prepare and mask the test data, write the UAT scenarios in business language with no technical jargon, run a walkthrough session so users know how to log defects, triage what they report, and maintain the UAT defect log.

You do not run their test cases for them, because if QA runs UAT it is not UAT. Sign off comes from the named business owner, which is the product owner in a product company and the client stakeholder or business sponsor in a services engagement, and it must be a named individual with authority, agreed at the start of the project. The most common things that go wrong.

Nobody agreed who signs off, so the release stalls while three people point at each other. Users report enhancement requests as defects, and you need a pre agreed rule that anything not in the signed requirement is a change request, with a separate log, or scope explodes in the last week. The UAT environment differs from production in configuration, so issues found there are noise and real issues get missed.

Test data is inadequate, so users cannot run their real scenarios and sign off on a hollow pass. Users are not available, because in Indian client projects the business users have day jobs and UAT competes with month end closing, which is why the UAT window must be booked with their manager weeks earlier. And defects arrive on the last day because users started late.

The follow up is usually 'what if the client refuses to sign off over a low severity issue'. You quantify the impact, offer a documented workaround plus a committed fix release, and escalate through the project manager rather than negotiating it yourself.

Answer

For a two hour turnaround the practical options are work breakdown structure with historical rates, or analogy based estimation against a similar past release. Work breakdown: list the deliverables, test case design, execution, retesting, regression, non functional checks, reporting, then apply a rate from your own history such as cases designed per day and cases executed per day. If your team designs 15 detailed cases per day and executes 30 per day, 300 cases is 20 design days plus 10 execution days.

Analogy is faster: the last release of similar scope took 12 person days, this one is roughly 1.3 times the scope, so 16 person days. The techniques interviewers expect you to name: three point estimation, where estimate equals optimistic plus four times most likely plus pessimistic, all divided by six, which gives a defensible number and a variance you can quote. Wideband Delphi or planning poker for team consensus, which is what Agile teams actually use for story level testing effort.

Function point or test point analysis, more common in services companies with formal metrics programmes. Percentage of development effort, a rough rule of thumb of 25 to 35 percent of development effort for testing, useful as a sanity check but never as the primary method. What people forget, and what the panel is listening for: retesting effort, which is not free and needs a multiplier based on your historical reopen rate, typically 20 to 30 percent of execution effort.

Regression on unchanged areas. Environment setup and downtime, which on Indian service projects with shared environments is a real and recurring cost. Test data creation.

Defect logging and triage meetings. Buffer for the unknown, usually 15 to 20 percent. Report preparation.

And leave, holidays and the fact that nobody is productive eight hours a day. The follow up is 'what if the estimate is rejected'. You do not silently compress, you present what scope drops out at the reduced number and let the business choose.

Three point estimation
  E = (Optimistic + 4 x MostLikely + Pessimistic) / 6
  Execution: (6 + 4x10 + 18) / 6 = 10.7 days
  Std dev  : (18 - 6) / 6 = 2 days, so quote 10.7 plus or minus 2

Work breakdown for a 300 case release
  Test case design    300 / 15 per day       = 20.0 days
  Execution cycle 1   300 / 30 per day       = 10.0 days
  Retest (25 percent of exec)                =  2.5 days
  Regression cycle 2 (50 percent scope)      =  5.0 days
  Non functional spot checks                 =  2.0 days
  Environment setup and downtime             =  2.0 days
  Test data creation                         =  1.5 days
  Reporting and triage meetings              =  2.0 days
  Subtotal                                   = 45.0 days
  Buffer 15 percent                          =  6.8 days
  TOTAL                                      = 51.8 person days

Sanity check: testing is usually 25 to 35 percent of dev effort.

Answer

Start from data, not from assumption. Pull the actual device, OS, RAM and network distribution from Firebase, Google Play Console or your analytics, and build a device matrix that covers the real 80 percent of your install base plus a deliberate floor device. In India that floor is typically a 2GB or 3GB RAM Android handset two or three OS versions behind, not the latest flagship.

Then test the conditions the office never reproduces. Low RAM: the operating system kills backgrounded apps aggressively, so test that the app restores state after being killed mid flow, especially mid payment. Slow storage and cold start: measure launch time on the floor device, not on the developer's phone.

Network: use network throttling profiles, the Chrome DevTools presets for web and Android Studio or Charles Proxy for mobile, and test on simulated 3G and 2G alongside a completely offline case. The behaviours to check are timeouts that are too aggressive, spinners with no timeout at all, double submission when an impatient user taps twice on a slow request, and whether the app recovers when connectivity returns mid request. Test network transitions specifically, WiFi to mobile data handover mid upload, which breaks more flows than pure slow networks do.

Then payments, which is where India specific testing matters most: a UPI collect request that the user never approves, an app switch to a UPI app and back, the user backgrounding the app during payment, a delayed webhook arriving after the user gave up, and a duplicate webhook. App size and data usage matter because users on metered plans uninstall heavy apps. Add regional language rendering, and test on a device with the system font scaled up, since that is common among older users. Tooling: BrowserStack and LambdaTest for the breadth, plus a small physical device lab of three or four real low end handsets, because emulators do not reproduce thermal throttling or a genuinely weak radio.

Answer

The happy path is trivial and nobody is asking about it: enter the amount, choose UPI, approve in the payment app, get a success screen, order confirmed. Everything valuable is in the unhappy paths, and the structural reason is that a UPI payment is asynchronous, involves an app switch outside your control, and reports its result through a webhook that can be late, duplicated or lost. The scenario groups.

Timeouts: the collect request expires without the user acting, and your order status must resolve correctly rather than sitting in PENDING forever. App switch: the user goes to the UPI app and never comes back, comes back after five minutes, or kills your app while in the UPI app. Insufficient balance, a wrong UPI PIN entered three times, a blocked VPA, a bank server down response, and the specific case of the bank debiting the account while the payment gateway reports failure, which is the most painful real world case and must be covered by a reconciliation process you should ask about.

Webhook behaviour: a duplicate success webhook must not create two orders, a webhook arriving after the user already retried must not double charge, and an out of order webhook where failure arrives after success must not flip a completed order. Idempotency: the same idempotency key retried must return the original result, not create a new transaction. User side races: double tapping Pay, opening the same cart in two tabs, pressing back from the payment screen and retrying.

Amount edge cases: the minimum amount, the per transaction UPI limit, decimals and rounding on split payments, and wallet plus UPI combinations where the wallet must be reversed if the UPI leg fails. Refunds: full, partial, and a refund on an order that was cancelled before capture. The production only failure modes are almost always the timing ones, the late webhook, the duplicate webhook and the debit without confirmation, so ask in the interview whether there is a reconciliation job and test it, since that job is the real safety net.

UPI scenario groups

Timeout and abandonment
  T1 Collect request expires unactioned, order resolves to FAILED
  T2 User switches to the UPI app and never returns
  T3 User kills the app while in the UPI app, then reopens

Bank and gateway failures
  B1 Insufficient balance
  B2 Wrong UPI PIN x3, lockout at the bank
  B3 Bank server down, gateway returns a retryable error
  B4 Amount DEBITED but gateway says FAILED  <- reconciliation case

Webhook behaviour
  W1 Duplicate success webhook, only one order created
  W2 Late success webhook after the user already retried
  W3 Out of order: failure webhook arrives after success
  W4 Webhook never arrives, status polling fallback works

Races and idempotency
  R1 Double tap on Pay, single transaction created
  R2 Same idempotency key replayed, original result returned
  R3 Wallet 250 plus UPI 649, UPI fails, wallet fully reversed

Amounts
  A1 Minimum amount, A2 per transaction UPI limit,
  A3 rounding on a split payment, A4 partial refund

Answer

Translation correctness is the smallest part of the problem and usually the only part people test. What actually breaks is layout and rendering. Text expansion: Hindi and Tamil strings are frequently 20 to 40 percent longer than the English equivalent, so buttons truncate, labels wrap onto two lines and break vertical rhythm, and a fixed height card starts clipping.

Test with the longest string in each language, not the average. Font and script rendering: Devanagari, Tamil and Bengali use conjuncts and combining marks, so you check for clipped ascenders and descenders, broken conjunct ligatures, the tofu box appearing when a glyph is missing from the bundled font, and line height that was tuned for Latin script cutting off matras. Test on a real low end device, because font fallback differs by manufacturer skin and an OEM ROM may not ship the same font as a Pixel.

Input: can the user type in the language, does the app handle an Indic keyboard, does search work with Indic input, and does a name with a matra survive a round trip through your database, which is where a column with the wrong collation or a latin1 charset turns text into question marks. Data formats: the Indian numbering system with lakh and crore separators, 1,00,000 rather than 100,000, currency symbol placement, and date format DD/MM/YYYY consistency. Mixed content: numbers and English product names inside an Indic sentence, which is where bidirectional and spacing issues appear.

Then the pragmatic checks: untranslated strings leaking through, which you find by switching the language and scanning for English, hardcoded strings that never went into the resource file, concatenated sentences built from fragments that produce grammatical nonsense in another language, and pluralisation rules. Finally test the language switch itself: does it persist across sessions, does it apply to server sent content such as emails and SMS, and does a push notification arrive in the chosen language. That last one is missed constantly.

Answer

Decide by what you are actually trying to verify. Business logic, validation rules, calculations, permissions and error handling belong at the API layer, because that is where they are implemented. Rendering, navigation, layout and the integration of the whole stack belong at the UI layer.

The cost difference is severe: an API test runs in tens of milliseconds and is stable, a UI test runs in seconds to minutes and is the primary source of flakiness in any suite, so putting logic verification in the UI means you pay a hundred times the runtime for the same assertion. Practically, if a rule has 40 permutations, test one or two through the UI to prove the screen is wired correctly and the other 38 through the API. What API tests catch that the UI cannot.

The UI often blocks invalid input, so the server side validation is never exercised, and that is a real security gap: a client that enforces a maximum quantity of 10 hides the fact that the API accepts 10000. Authorisation flaws where user A can fetch user B's record by changing an ID, since the UI never offers that link. Response contract changes such as a field renamed or a type changed from number to string, which break mobile clients silently.

Correct HTTP status codes, since a UI showing a friendly error can be sitting on a 200 response that reports failure in the body, which breaks retry logic. Idempotency behaviour on repeated calls. Rate limiting.

Response times per endpoint, which is where you catch a slow query long before it shows as a slow page. Error message leakage, such as a stack trace or a database error returned to the client. Tooling in Indian teams in 2026: Postman with Newman in CI for exploratory and collection based checks, RestAssured with Java or Karate for framework based suites, and increasingly contract testing with Pact between services. The follow up is 'so should you have no UI tests', and the answer is no, you keep a thin layer of end to end UI journeys on the critical paths, because they are the only tests that prove the whole system is wired together.

Answer

Do not start by writing test cases. Start by finding out where quality is actually failing, because a process built on assumption gets ignored. First two weeks: read the last six months of production incidents and support tickets, categorise them by module and root cause, and interview engineers and support about what breaks most.

That gives you a defect profile and it is the evidence base for everything you propose next. Weeks three to six: put in the minimum viable process, which is a defect workflow with agreed severity definitions, a bug report template, and a triage cadence. Then a risk based test approach for the top three modules identified from the incident data, and a smoke suite that a human can execute in fifteen minutes so there is at least a build acceptance gate.

Also fix the environment situation if staging does not resemble production, because everything else you build sits on that foundation. Weeks seven to twelve: automate the smoke suite and wire it into CI so it gates merges, add API level tests on the highest risk service, and start a lightweight release checklist. Define three metrics only, escaped defect count, defect leakage rate, and time from commit to test feedback, and publish them every release, because publishing a small number of metrics consistently builds more credibility than a large dashboard nobody reads.

What to deliberately not do: do not try to write comprehensive test cases for the whole product, do not buy a test management tool in month one, do not push for a QA sign off gate that slows the release train, and do not try to hire a team before you have shown the value of the first improvements. The panel is checking prioritisation under ambiguity and whether you will be a bureaucracy generator or a risk reducer. The follow up is usually 'what if the developers resist the process'. You win that by removing pain first, for example a reliable staging environment and a fast smoke gate, and only then asking for anything from them.

Answer

The most damaging effect of flakiness is not the wasted minutes, it is that the team has learned to ignore red, which means a real regression will also be re run and merged. So the first action is organisational: stop blanket auto retries at the pipeline level, and quarantine known flaky tests into a separate non blocking job so the main pipeline signal becomes trustworthy again immediately. Then instrument.

You cannot fix what you cannot see, so record every test result over time and compute a flake rate per test, meaning how often the same test changed outcome without a code change. Rank by flake rate multiplied by execution frequency and fix the top offenders first, because flakiness follows a power law and a handful of tests usually cause most of the noise. Then attack by root cause class.

Timing: hardcoded sleeps and implicit waits replaced by explicit conditional waits on the actual state you need, waiting for the network call to settle or the element to be interactable rather than for a fixed number of seconds. Test data collisions: tests sharing an account or a record fail intermittently under parallel execution, so every test creates and cleans its own data. Order dependency: run the suite in random order to expose tests that only pass after another test ran, which is a genuine defect in the suite.

Environment: a shared staging environment where a deploy lands mid suite, fixed by an ephemeral environment per pipeline run or at least a deploy lock. External dependencies: a third party sandbox that fails randomly, fixed by mocking it at the boundary for regression and testing the real integration in a separate scheduled job. Animation and rendering races in UI tests. Then set a policy: a test that flakes more than an agreed threshold within a window is auto quarantined and assigned to an owner with a fix deadline, and a quarantined test that is not fixed within two sprints is deleted, because a test nobody trusts and nobody fixes has negative value.

Flake triage pipeline

1. Measure   store every result, compute per test flake rate
               flake rate = outcome flips / runs, no code change
2. Rank      priority = flake rate x runs per week
3. Quarantine  move above threshold tests to a non blocking job
4. Fix by class
     timing        replace sleeps with explicit conditional waits
     data          per test data creation and teardown
     order         run in random order to expose dependencies
     environment   ephemeral env per run, or a deploy lock
     third party   mock at the boundary, real integration nightly
5. Policy     quarantined and unfixed for 2 sprints equals deleted

Banned in review
  Thread.sleep(5000)
  cy.wait(3000)
  driver.manage().timeouts().implicitlyWait mixed with explicit waits

Required
  wait until the element is interactable, or the request completes,
  or the expected application state is reached

Answer

Layer it so that the thing that changes most often is isolated from the thing that changes least. Bottom layer: driver and configuration management, browser and device setup, environment URLs, credentials pulled from a secret store, and parallel execution configuration. Next: page objects or screen objects, one class per screen exposing intent level methods such as applyCoupon rather than exposing raw locators.

Locators live only here, so a UI change touches one file. Next: a business action or workflow layer composing page objects into reusable flows such as completeCheckoutWithUPI, which is what stops the same twelve step sequence being copy pasted into thirty tests. Next: test data management, factories that create data through APIs rather than through the UI, because logging in through the UI to set up a precondition is the single largest waste of runtime in most suites.

Then the test layer, which should read like a specification and contain assertions only. Alongside: utilities, reporting with Allure or ExtentReports, and a common assertion library. Where it goes wrong with four squads sharing it.

Ownership: a shared framework with no owner rots, so you need a named maintainer and a contribution review. Coupling: one squad changes a shared page object and breaks three other squads, so shared components need their own tests and semantic versioning of the framework library. Divergence: squads fork the framework because a change was slow to merge, and within a year you have four frameworks.

Runtime: the suite grows past the pipeline budget, so you need per squad tagging so a squad can run only its own subset, plus parallel sharding. Reporting: four squads need to see their own failures, so results must be tagged by squad and routed. The follow up at lead level is usually 'BDD or not'. The honest answer is that Cucumber or SpecFlow pays for itself only when non technical stakeholders genuinely read the feature files, and when they do not, it adds a translation layer and a glue code maintenance cost for no benefit, so pick it based on the audience, not on fashion.

framework/
  core/         driver factory, config, secrets, parallel setup
  pages/        one class per screen, locators live ONLY here
  workflows/    composed business actions, reused across squads
  data/         API driven factories, per test create and teardown
  utils/        waits, file handling, date helpers, db helpers
  reporting/    Allure or ExtentReports adapters
tests/
  squad-payments/
  squad-search/
  squad-profile/
  squad-notifications/

Test layer reads as a specification
  loginAs(user);
  cart.add(BOOST_PLAN);
  checkout.payWithUPI(SANDBOX_VPA);
  assertThat(orders.latest().status()).isEqualTo(CONFIRMED);

Scale rules
  named framework owner + contribution review
  semantic versioning on the shared library
  squad tags so each squad can run its own subset
  shared page objects have their own tests

Answer

With ten deploys a day, no human gate can sit in the path, so quality has to be encoded into stages with progressively wider scope and progressively later blocking. Pre commit, on the developer machine: linting, formatting and fast unit tests through a git hook, target under 30 seconds. On the pull request, target under 10 minutes and it must block the merge: full unit test suite with a coverage threshold on changed lines rather than on the whole repository, static analysis and security scanning through SonarQube or similar, dependency vulnerability scanning, contract tests for any changed API, and a fast integration test subset.

On merge to main, target under 20 minutes: build the artefact once and promote that same artefact through every later environment, never rebuild per environment. Deploy to staging, run the smoke suite, run the fast regression tier, and run API integration tests against real dependencies. This blocks promotion, not the merge.

Post deploy to production: run a small production smoke of read only and synthetic transaction checks against the live system, and watch error rate, latency and business metrics for an automated bake period. Then the deployment strategy carries the rest of the risk: feature flags so a change can be dark launched and turned off without a rollback, canary or phased rollout to a small percentage of traffic with automated rollback if error rate or a business metric such as payment success rate crosses a threshold, and a rollback that is a single command with a known duration. Nightly and scheduled: full regression across the device and browser matrix, performance baseline comparison, accessibility scanning, and a longer soak.

What blocks a deploy: any failing unit test, any new high severity security finding, a smoke failure on staging, and a canary breaching its error budget. What does not block: full cross browser regression, because it is too slow to gate a ten times daily pipeline, which is exactly why feature flags and fast rollback are load bearing here rather than optional.

Stage            Runs                                     Blocks       Budget
pre commit hook  lint, format, fast unit                  local push   30s
pull request     full unit + coverage on changed lines    MERGE        10m
                 SAST, dependency scan, contract tests
merge to main    build once, deploy to staging            PROMOTION    20m
                 smoke + fast regression tier + API tests
pre production   synthetic transaction on prod like env   PROMOTION    5m
post deploy      prod smoke (read only + synthetic txn)   ROLLBACK     3m
                 automated bake: error rate, p95, payment
                 success rate vs baseline
nightly          full regression, all browsers/devices    reported     no cap
                 performance baseline, a11y scan, soak

Risk carried by deployment strategy, not by a human gate
  feature flags, canary at 5 percent, auto rollback on error budget

Answer

Start by converting the business expectation into measurable non functional requirements, because '12 times traffic' is not testable. Derive concurrent users and requests per second from real analytics: peak concurrent sessions today, the ratio of browse to search to checkout, and the historical shape of a sale spike, which in Indian sale events is a sharp vertical at the opening minute rather than a gentle ramp. Then set targets per critical transaction, for example home feed under 800ms at p95, search under 1.2 seconds at p95, and checkout under 2.5 seconds at p95, with an error rate under 0.1 percent and no degradation over a four hour window.

Test types you must run and the distinction matters: load testing at expected peak to verify the targets, stress testing beyond peak to find the breaking point and confirm it fails gracefully rather than corrupting data, spike testing that jumps from baseline to 12 times within a minute to mirror the sale opening, soak or endurance testing at moderate load for six to eight hours to expose memory leaks and connection pool exhaustion, and scalability testing to verify that adding instances actually improves throughput rather than moving the bottleneck to the database. Tooling: JMeter remains the default in Indian services and enterprise teams, k6 and Gatling are common in product teams for scripted scenarios in code, and Locust where the team is Python heavy. Run against a production sized environment or you will measure the wrong thing entirely, and use realistic data volumes because a query that is fast against 10000 rows is not fast against 40 million.

Correlate results with server side observability, APM traces, database slow query logs, connection pool metrics and cache hit ratios, because a load test that only reports response times tells you that something is slow, not what. Then act on findings with the business: CDN and caching strategy, queueing for checkout, rate limits, autoscaling policy warm up time, and a degradation plan that switches off non essential features under load. Finally rehearse the rollback and the war room, because the sale is a single shot event.

Answer

A functional QA team is not a penetration testing team, but it should own the class of issues that come from broken business logic rather than from exotic exploitation, because those are the ones a specialist scanner misses and a tester who understands the domain finds easily. The highest value area is broken access control, which sits at the top of the OWASP list. Insecure direct object reference is the canonical test: log in as user A, capture the request that fetches a resource, note the identifier, then replay that exact request with user B's session token and user A's resource ID.

If you get A's data, that is a critical defect. Do this for every identifier your application exposes, order IDs, application IDs, resume IDs, invoice URLs, and do it for the download endpoints too, because a signed document URL that never expires and requires no authentication is extremely common. Then vertical access control: take an admin only endpoint and call it with a normal user token, and take a normal user endpoint and check whether it accepts a request with the role field altered in the request body.

Function level checks: the UI hides the delete button for a viewer role, but does the API still accept the delete call. Then the rest of the QA owned surface: authentication behaviour including session expiry, session invalidation on password change and on logout, concurrent session policy, and account lockout. Input validation on the server independent of the client, since the UI blocking input is not validation.

Sensitive data exposure, checking that OTPs, tokens, full card numbers, PAN or Aadhaar do not appear in API responses, in logs, or in analytics events, which is a very common leak. Error handling that does not return stack traces or database errors. Transport security and secure cookie flags.

Rate limiting on OTP, login and any expensive endpoint. Then hand off injection, cryptography review, and infrastructure to a specialist. The follow up is usually 'how do you fit this in a sprint', and the answer is a short security checklist attached to the definition of done for any story touching authentication, authorisation or personal data.

IDOR test procedure

1. Log in as user A, create a resource, note the id
     GET /api/applications/8815  ->  200, A's data
2. Log in as user B in a separate session, capture B's token
3. Replay A's request with B's token
     GET /api/applications/8815
     Authorization: Bearer <B_TOKEN>
   PASS: 403 or 404
   FAIL: 200 with A's data  ->  CRITICAL defect

4. Repeat for every exposed identifier
     /api/resumes/{id}     /api/invoices/{id}
     /api/orders/{id}      /api/messages/{id}
     signed download URLs (also check expiry and reuse)

5. Vertical checks
     call an admin endpoint with a normal user token
     POST with {"role": "admin"} injected into the body
     UI hides Delete for viewer role, does the API still accept DELETE?

6. Data exposure sweep
     grep API responses and logs for otp, token, pan, aadhaar,
     card, cvv, password before every release

Answer

Accessibility testing verifies that people with visual, motor, auditory and cognitive impairments can use the product, measured against WCAG 2.1 or 2.2 at level AA, which is the level almost every procurement requirement and Indian government guideline references. Automated scanners such as axe, Lighthouse, WAVE or Pa11y catch roughly 30 to 40 percent of issues, and that gap is the point of the question. They reliably find missing alternative text, insufficient colour contrast, missing form labels, missing document language, duplicate IDs and invalid ARIA usage.

What they cannot judge: whether the alternative text is meaningful rather than just present, whether the reading order makes sense, whether a custom component behaves like the widget it imitates, whether focus goes somewhere sensible after a modal closes, whether an error message is actually announced, and whether the content is understandable. So the manual programme matters more. Keyboard only testing: unplug the mouse and complete every critical journey using tab, shift tab, enter, space and arrow keys, checking that focus is always visible, that tab order follows visual order, that no component traps focus, and that a modal returns focus to the trigger on close.

Screen reader testing with NVDA on Windows, VoiceOver on macOS and iOS, and TalkBack on Android, since behaviour differs meaningfully across them. Zoom to 200 percent and check nothing is lost or requires horizontal scrolling. Test with the operating system font scaled up.

Check that colour is never the only carrier of meaning, for example a required field marked only in red. Verify that dynamic content updates are announced through live regions. Check that touch targets meet the minimum size.

Then embed it: add axe into the CI pipeline so regressions are caught automatically, add accessibility acceptance criteria into the definition of done, and keep a manual audit per release for the critical journeys. The follow up is 'who signs it off', and for a tender the answer is usually a formal VPAT or an accessibility conformance report, so the evidence trail matters as much as the fixes.

Answer

Run it blameless, and say that first, because the quality of the information you get depends entirely on people not fearing the meeting. Establish the timeline precisely: when the defect was introduced, when it was deployed, when it first affected a user, when it was detected, by whom, and when it was mitigated. Two derived numbers matter more than the defect itself, time to detect and time to mitigate, because those are the capabilities you can actually improve for defects you have not written yet.

Then run the five whys, but push past the first satisfying answer. Why did the payment double charge? A retry created a second transaction.

Why? No idempotency key on the retry path. Why?

The requirement never mentioned idempotency. Why? Nobody with payment domain knowledge reviewed that story.

Why? Grooming for payment stories has no required reviewer. That last level is the actionable one, and stopping at 'we missed a test case' is exactly the failure mode this question is testing for.

Then examine every layer of the defence in depth, not just testing. Requirements: was it specified. Design: was there a review.

Code: did the review catch nothing because the diff was 900 lines. Unit tests: was the path covered. Integration and QA: was it in scope, was it reasonably findable, was there a test environment that could reproduce the condition.

Release: did the rollout strategy limit the blast radius, was there a canary. Monitoring: why did an alert not fire on a payment anomaly, because a defect that costs money for six hours before a customer reports it is a monitoring failure as much as a testing failure. Recovery: how long did rollback take.

Then produce actions with owners and dates, split into corrective, which fixes this defect, and preventive, which fixes the class. Add the regression test, yes, but also the process change and the alert. Finally track that the actions actually got done, since post mortems whose actions expire silently teach the organisation that the meeting is theatre.

Post mortem structure

Timeline
  introduced 12 Aug 14:20 | deployed 13 Aug 11:05
  first user impact 13 Aug 11:40 | detected 13 Aug 17:55
  mitigated 13 Aug 18:30
  Time to detect 6h 15m   Time to mitigate 35m   Users affected 412

Five whys, push past the first answer
  double charge -> retry created a second transaction
  -> no idempotency key on the retry path
  -> requirement never mentioned idempotency
  -> no payment domain reviewer on the story
  -> grooming has no required reviewer for payment stories  <- ACT HERE

Defence layers, which one should have caught it
  requirement | design review | code review | unit | API test
  QA scope | canary | monitoring | rollback speed

Actions
  CORRECTIVE  idempotency key on retry           dev lead   18 Aug
  CORRECTIVE  regression test for duplicate txn  QA         19 Aug
  PREVENTIVE  payment reviewer required at grooming  EM      1 Sep
  PREVENTIVE  alert on duplicate txn rate per user   SRE     25 Aug

Answer

Code coverage measures which lines or branches were executed while the tests ran. It does not measure whether anything was verified. A test suite that calls every function and asserts nothing achieves 100 percent line coverage and catches zero defects, which is the fundamental point to make without being adversarial about it.

Coverage is useful as a negative signal, uncovered code is definitely untested, but it is weak as a positive signal. Also distinguish the types, since a senior panel will: line or statement coverage is the weakest, branch or decision coverage is meaningfully stronger because it requires both sides of every condition, condition coverage requires each boolean sub expression to take both values, and path coverage is usually infeasible past trivial functions. A module at 90 percent line coverage may sit at 60 percent branch coverage, so ask which number is being quoted.

Then there is the coverage that nobody measures: requirement coverage, whether every acceptance criterion has a test, and risk coverage, whether the highest risk scenarios are covered at all. Code coverage cannot tell you about a missing requirement, because code that was never written cannot be uncovered. Mutation testing is the technique that actually evaluates test quality.

A tool such as PIT for Java, Stryker for JavaScript and TypeScript, or mutmut for Python deliberately introduces small faults into the source, changing a plus to a minus, inverting a conditional, removing a method call, replacing a return value, then re runs the tests. If the tests still pass, the mutant survived, which proves that no test would have caught that real defect. The mutation score is killed mutants over total mutants, and it is a far better quality signal than coverage.

The cost is runtime, since the suite runs once per mutant, so teams run it on critical modules or on changed files rather than across the whole codebase. The practical response to the developer is not an argument about the number, it is to run mutation testing on that module and let the surviving mutants make the case for you.

Full line coverage, zero verification

  function applyGst(amount) {
    return amount + amount * 0.18;
  }

  test("applyGst runs", () => {
    applyGst(1000);        // 100 percent line coverage
  });                      // asserts nothing, catches nothing

Mutation testing exposes it
  original   return amount + amount * 0.18;
  mutant 1   return amount - amount * 0.18;   SURVIVED
  mutant 2   return amount + amount * 0.28;   SURVIVED
  mutant 3   return amount;                   SURVIVED
  Mutation score 0 percent despite 100 percent coverage

Coverage types, weakest to strongest
  statement < branch < condition < path
  90 percent statement can be 60 percent branch, always ask which

Tools: PIT (Java), Stryker (JS/TS), mutmut (Python)
Run on critical modules or changed files only, it is expensive.

Answer

Attack it in four ways, in order of return per unit of effort. First, parallelisation, which is pure infrastructure and requires no test changes if the tests are independent. Sharding 4000 tests across 12 containers takes three hours to roughly fifteen minutes of wall clock time, and if the tests are not independent enough to shard, that dependency is itself the first defect to fix.

Grid infrastructure such as Selenium Grid, or a cloud provider like BrowserStack or LambdaTest, gives you the browser capacity. Second, test impact analysis: map which tests exercise which code, then on a pull request run only the tests affected by the changed files, keeping the full suite for the nightly run. Tooling support varies by stack, and where it does not exist you can approximate it with module tagging, running the payments suite when payment code changes.

Third, rebalance the pyramid. A three hour suite is almost always a suite where UI tests are doing work that belongs at the API or unit level, so identify the assertions that do not require a browser and move them down. Moving 800 UI tests to API level typically returns more time than any infrastructure change and improves stability at the same time.

Fourth, remove redundancy, which is the politically hard part, so do it with data rather than opinion. Measure which tests have never failed in the last 200 runs and which tests always fail together with another test, since the latter are duplicates by behaviour. Present a candidate deletion list with evidence, and instead of deleting immediately, move them to a nightly only tier, which is a much easier proposal to get agreement on and achieves the same feedback time.

Then prevent regrowth with a policy: a per pipeline time budget, and a rule that a new test entering the merge gate must justify its runtime or run nightly. The follow up is 'what do you tell a manager who says never delete a test'. You show the maintenance cost per test per year and the flake contribution, and reframe it as moving tests to a slower tier rather than losing coverage.

Answer

Stop trying to make one shared full stack environment the primary gate, because with twelve services it will never be simultaneously up to date and stable, and every failure needs cross team triage before anyone knows whose defect it is. Shift the weight to contract testing. Each consumer defines the requests it makes and the responses it expects, and that contract is published, for example through Pact with a broker.

The provider runs the consumer's contract as part of its own pipeline, so a breaking change is caught by the team that made it, in their own build, minutes after they wrote it, without any shared environment existing at all. This is the single highest value change in a microservices testing strategy and it is what the panel is listening for. Around it: strong service level testing where each service is tested in isolation with its dependencies stubbed using WireMock or a similar tool, and component tests that exercise a service with a real database in a container through Testcontainers.

Then keep a deliberately small number of true end to end journeys, five to ten covering the money paths, run against a stable environment before release, accepting that they are slow and occasionally flaky because their purpose is integration confidence, not coverage. Add production verification to cover what pre production cannot: synthetic transactions running continuously against production, feature flags and canary deploys, and observability with distributed tracing so that when something fails you can see which of the twelve services broke rather than debating it in a call. On environments, prefer ephemeral namespaces spun up per pipeline run over a shared long lived staging environment, with the service under test deployed at the version being tested and every other service pinned to its last known good production version. Also agree the cross team rules explicitly: versioned APIs with a deprecation policy, backwards compatible changes by default, and a shared definition of who owns a failing end to end test, since ownerless end to end suites are the ones that get switched off.

Test weight distribution across 12 services

  Unit and component (per service, containerised deps)   heavy
  Contract tests (Pact, consumer driven)                 heavy
  Service integration with stubs (WireMock)              medium
  End to end journeys                                    5 to 10 only
  Production synthetic monitoring                        continuous

Contract flow, no shared environment needed
  1. Checkout service (consumer) declares expectations
  2. Contract published to the Pact broker
  3. Payments service (provider) verifies it in ITS pipeline
  4. Breaking change fails the PROVIDER build, not QA's suite
  5. can-i-deploy check gates the provider deploy

Environment model
  ephemeral namespace per pipeline run
  service under test at the candidate version
  all other services pinned to last known good production version

Answer

First, handle the zero defects request directly, because agreeing to it sets you up to fail and to corrupt your own data. Zero defects found is not a quality signal, it is either a trivial release or a testing failure, and a target of zero defects reliably produces under reporting, relabelling of defects as change requests, and testers who stop logging small issues. What leadership actually wants is confidence that the product is not going to embarrass them, so redirect the conversation to escaped defects and customer impact rather than to internal defect counts.

Design the dashboard around outcome metrics first: defect leakage or escape rate over a fixed post release window, production incidents by severity, mean time to detect and mean time to restore, customer reported issues per thousand active users, and crash free session rate for a mobile app, which is the metric product companies actually manage against. Then supporting process metrics: defect removal efficiency, reopen rate as a signal of fix quality, requirement coverage from the RTM, automation pass rate and flake rate, and feedback time from commit to test result. Explicitly avoid the metrics that drive bad behaviour: defect count per tester, which turns into logging trivia and inflates numbers, test cases written or executed per day, which rewards volume over risk, and a raw code coverage target, which produces assertion free tests.

Every metric should have a stated purpose and a named decision it informs, and you should say out loud that any metric used to evaluate individuals will be gamed, which is Goodhart's law in practice and a line that lands well in a senior interview. Then present trends rather than single numbers, keep the dashboard to six or seven metrics because a larger one gets ignored, and always pair a metric with the context that explains it, since a spike in defects after a large refactor is expected and reporting it without that context creates the wrong reaction. Review the metric set every couple of quarters and retire any metric that has not changed a decision.