Manual Testing Interview Questions (2026): QA Fundamentals to Scenarios

SDLC covers the entire software build process: requirements, design, development, testing, deployment, and maintenance. STLC is the testing-specific subset that runs inside (or alongside) the SDLC: requirement analysis, test planning, test case design, environment setup, test execution, and closure. STLC doesn't replace SDLC, it zooms into one phase of it.

Interviewers want to hear that STLC phases map onto specific SDLC stages, and that testing, on most modern teams, starts during requirements gathering rather than after coding is "done."

A test scenario is a one-line, high-level idea of what to test, "verify login with valid credentials," for example. A test case is the detailed, step-by-step specification underneath it: precondition, exact input data, execution steps, expected result. One scenario can expand into five or six test cases once you factor in valid, invalid, empty, and boundary inputs.

Some interviewers will hand you a scenario on the spot and ask you to write two or three real test cases from it. Practice this out loud instead of only on paper. The pause while you think it through is where most candidates lose their composure.

Test case ID, title, precondition, test steps, test data, expected result, actual result, status (pass, fail, or blocked), and priority. Some teams add a severity field here too, though it usually only gets filled once a test fails and turns into a defect.

If you can list eight fields but can't explain why "expected result" and "actual result" get separate columns, traceability, so a reviewer can see the gap at a glance without rereading the whole case, that's a sign you copied a template without ever using one.

An error is a human mistake, in the code or in the requirements. A defect (the word "bug" is used interchangeably in casual speech) is the flaw that mistake leaves behind in the software. A failure is what happens when that defect actually gets triggered during operation, the system behaves incorrectly in front of a real user. Not every defect causes a failure, dead code with a bug in it that never executes is still a defect, just one without a failure attached.

This question tests precision, not memorization. Interviewers want the causal chain (error creates defect, defect under the right conditions produces failure), not four synonyms recited back to back.

Functional testing checks what the system does against requirements, does clicking "submit" actually save the record? Non-functional testing checks how well it does it: performance, load, usability, security, compatibility. A login page can pass every functional test and still fail non-functional testing if it takes eight seconds to respond under fifty concurrent users.

The follow-up usually pushes for one non-functional example beyond "performance." Most candidates stop at load testing and forget usability or compatibility exist as separate categories too.

User Acceptance Testing is the last check before release, run by real business users or client representatives, not the QA team, to confirm the software solves the actual problem it was built for, beyond simply passing the written requirements. QA runs functional and regression testing. UAT is the business's own gate.

One typical follow-up asks what it means if UAT fails after every prior stage passed. Good answer: it usually points to the requirements themselves being wrong or incomplete, not to testing being skipped, which loops straight back to verification vs validation.

Splitting input data into groups (partitions) that should all behave the same way, then testing one representative value from each group instead of every possible value. If an age field accepts 18 to 60, you don't need sixty test cases, you need one valid partition (say, 30), one below-range partition (10), and one above-range partition (75).

Expect a follow-up asking you to name the partitions for a different field, a percentage 0-100, say, to check that you actually generalize the concept rather than repeating a memorized example.

Scope (what's in and out), test objectives, resources and roles, schedule, environment and tools, entry and exit criteria, risks and mitigations, and deliverables (test cases, reports, defect logs, whatever gets handed off at the end).

A common ask here is which section you'd cut first under a tight deadline. There's no perfect answer, but "risks and mitigations" is the wrong one to cut, and saying so out loud shows judgment.

Black box testing means you test the application purely from the outside, feeding inputs through the UI or an API and checking the outputs, without caring how the code underneath is structured. Most manual functional testing, most of what a QA does day to day, is black box. White box testing means the tester, usually a developer or SDET, looks directly at the source code, unit tests, and branch coverage to make sure every code path actually gets exercised. Gray box sits in between: you have partial knowledge of the internals, maybe the database schema or the API contract, and you use that knowledge to design smarter black box tests, like sending a value you know will hit a specific SQL query or trigger a particular validation rule.

In practice, a good manual tester usually operates in gray box mode even without writing a line of code. If you know there's a rate limiter that kicks in after five requests, you're not purely black box anymore, you're using system knowledge to aim your tests.

Alpha testing happens inside the company, before the product goes anywhere near a real customer. It's usually done by internal QA, and sometimes other employees, in a controlled environment, and the goal is to catch the obvious problems before anyone external sees the build. Beta testing happens after that, once the build is stable enough to hand to a limited set of real users, often outside the company, running on their own devices and networks. The point of beta isn't just finding more bugs, it's finding bugs you'd never think to test for because your test lab doesn't look like a real user's messy setup: spotty wifi, a five-year-old Android phone, an odd combination of installed apps.

Banking apps are a good example. Many run a closed beta with a few hundred real customers for weeks before a wide release, specifically to catch environment-specific issues that no internal test matrix would surface.

Positive testing checks that the system behaves correctly when you give it valid input, the happy path: does login work with a correct username and password, does checkout complete with a valid card. Negative testing checks that the system fails gracefully and safely when you give it input it was never designed to accept: a wrong password, an empty required field, a file of the wrong type, a negative quantity in a cart.

Junior testers naturally gravitate toward positive testing, because it feels like proving the feature works. But negative testing is usually where the interesting bugs live, since developers spend far less time thinking about what should happen when something goes wrong. A mature test suite has more negative cases than positive ones for anything user facing.

A test environment is a setup, hardware, software, network config, and test data, that mirrors production closely enough to run tests without touching real customers or real money. Most companies keep at least a couple of tiers: a dev environment for early integration, a QA or staging environment meant to be a near-exact copy of production, and sometimes a separate UAT environment where business stakeholders sign off before release.

You don't test directly in production for a few concrete reasons: real customer data can get corrupted or exposed, you can trigger real charges or emails to real people, and any downtime or bug you introduce hits paying users instead of nobody. Some companies do practice a form of testing in production, canary releases or feature flags rolled out to a small percentage of traffic, but that's a controlled, monitored exception, not a replacement for a proper test environment.

Automation is great at repeating the same check thousands of times without getting bored or skipping a step, which is why regression suites get automated. But automation is bad at anything that needs human judgment: does a new UI actually feel intuitive, does an error message make sense to a first-time user, does an animation look janky. Exploratory testing, usability testing, and brand-new features that are still changing shape every sprint are all places where writing an automated script would be wasted effort, because the script would be obsolete before it's even finished.

There's also a cost argument. If a feature only exists for two sprints before being replaced, or it's a one-off migration script that runs once, automating its tests can cost more time than it saves. The rule most teams use: automate what's stable and repeated, test manually what's new, exploratory, or inherently subjective.

Exploratory testing is simultaneous learning, test design, and test execution. You're not following a pre-written script, you're using what you just learned from the last action to decide the next one. You might start with a rough charter, "explore the checkout flow's coupon code handling for 30 minutes," but you're reacting to what the application actually does, not reading off a checklist.

It's especially good at finding bugs that scripted test cases miss, because scripted cases only find what someone already predicted might go wrong. A skilled exploratory tester will try things like double-clicking a submit button, hitting the browser back button mid-transaction, or switching network conditions mid-flow, things nobody wrote a test case for because nobody thought of them in advance. It's not a replacement for scripted testing, the two complement each other: scripted testing gives you coverage and repeatability, exploratory testing gives you the surprises.

Ad-hoc testing is informal, unplanned testing with basically no structure, no documented charter, no notes as you go, you just poke at the application to see if anything breaks. Exploratory testing looks similar from the outside, someone testing without a script, but it's actually disciplined: there's a charter or goal, the tester takes notes, and the session usually gets debriefed afterward so the findings feed back into the test plan.

Ad-hoc testing is fine for a quick gut check before a demo, or when a new tester is just getting familiar with an app. But if it's the only kind of unscripted testing your team ever does, you lose traceability, nobody can say what was actually covered, and the same gaps get missed release after release because there was never a record of what got explored last time.

Verification asks "are we building the product right?" It's a static check, reviews, walkthroughs, and inspections of documents and code before anything actually runs. Validation asks "are we building the right product?" It's a dynamic check, executing the software and comparing behavior against requirements. A requirements document can pass verification (it's internally consistent, well written, complete) and still fail validation later, if it solved the wrong problem for the actual user.

One concrete example of each is what separates a real answer from a memorized one. A candidate who can only recite the two definitions, with no activity attached to either, sounds like they copied a slide rather than understood the difference.

A traceability matrix maps every requirement to the test cases that cover it, so nothing ships untested and nothing gets tested that isn't tied to a real requirement. On regulated teams (healthcare, finance, fintech), it's a living document reviewed on a schedule. On smaller product teams, it's often built once during sprint zero and never opened again, which isn't ideal, but it's common enough that interviewers rarely expect you to defend it as sacred.

The question is really testing whether you understand traceability as a concept. Nobody expects you to have used the same tool they use, JIRA, Zephyr, and TestRail all handle this differently.

The core path runs New, Assigned, Open, Fixed, Retest, Verified, Closed, with two branch points along the way.

• Reopened: the retest fails, the original issue is still there, back to Assigned
• Rejected, Duplicate, or Deferred: the developer or lead disagrees it's a valid, current-priority bug

Different tools compress this differently, JIRA workflows vary team to team, but the underlying states hold up everywhere: someone finds it, someone owns it, someone fixes it, someone else confirms the fix, then it closes.

Bug ID: BUG-1042
Summary: Login fails with valid credentials on Safari 17
Steps to reproduce:
1. Open the login page in Safari 17 on macOS
2. Enter a valid username and password
3. Click "Log in"
Expected result: User lands on the dashboard
Actual result: Page reloads to the login screen with no error message
Severity: High
Priority: Medium
Environment: Safari 17, macOS 14.5, staging build 2.3.1

Reopened means the fix was attempted and it didn't work, the tester retested and the original issue is still present, or it came back. Rejected means the report itself didn't get accepted as a valid defect, maybe it's expected behavior, a duplicate of an existing ticket, or simply not reproducible on the reported environment.

A strong answer also covers what a tester should do when they disagree with a rejection: attach a screen recording, exact repro steps, and environment details, then escalate to the lead rather than let it drop silently.

Smoke testing is broad and shallow, run right after a new build to confirm it's stable enough to test at all, can you even log in, does the app launch. Sanity testing is narrow and deep, run after one specific fix or minor change, to confirm that particular area works and didn't obviously break anything adjacent to it. Smoke asks "is this build worth testing." Sanity asks "is this specific fix actually fixed."

A common follow-up asks which one is scripted. Smoke tests are usually predefined and repeated every build. Sanity tests are usually unscripted, decided on the fly based on exactly what changed.

No. Retesting confirms one specific defect is actually fixed, you rerun the exact failed test case with the exact steps that originally found the bug. Regression testing checks that the fix, or any other change, didn't break something else nearby. You do both after a bug fix: retest the reported issue first, then regression-test the surrounding area.

A common trap is answering as if the two terms are interchangeable. They're sequential steps in the same process, not synonyms for the same activity.

Integration testing checks that two or more modules work correctly together, at the seams, the interface between a payment service and an order service, for instance. System testing checks the entire application end to end, as one product, against the full set of requirements, after integration has already been confirmed to work.

Expect a follow-up naming actual integration approaches, big bang, top-down, bottom-up, sandwich, especially if your resume shows two or more years of experience.

Severity measures technical impact, how badly the defect damages the system's functioning. Priority measures business urgency, how soon it needs fixing relative to everything else in the queue. The International Software Testing Qualifications Board defines the two exactly this way in its official glossary (ISTQB Glossary), and interviewers lean on that definition even when they don't cite it by name.

A candidate who can only define the words, but can't classify a real bug into one of the four combinations (high severity/high priority, high/low, low/high, low/low), hasn't actually internalized the distinction yet.

High severity, low priority: the application crashes, but only when a user pastes an emoji into a date field on a browser almost nobody uses anymore, technically catastrophic, practically rare. Low severity, high priority: a spelling mistake in the company name on the homepage, cosmetically trivial, but it has to go out before the next press mention, so it jumps the queue.

Business context, not the raw technical damage, is what's actually being graded in an answer like this.

Boundary value analysis tests the exact edges of each partition, because most real defects live at boundaries, off-by-one errors, an incorrect ">" where the requirement meant ">=", not in the comfortable middle of a range. For an age field accepting 18-60, boundary value analysis tests 17, 18, 19 (lower edge) and 59, 60, 61 (upper edge), six values, against equivalence partitioning's three representative values.

A frequent follow-up asks you to combine both techniques into one test set. That combination is closer to how testers actually work day to day than either technique used alone.

A test strategy is organization-level and rarely changes project to project: general approach, tooling standards, risk categories, entry and exit criteria templates. A test plan is project-specific: scope, schedule, resources, environment, specific risks, and deliverables for this particular release. Strategy gets written once and referenced repeatedly. A plan gets written, or at least updated, for every project.

Expect a follow-up on who writes each document, strategy usually comes from a QA lead or architect, the plan from whoever's actually running that project's testing day to day.

Testing happens inside the same sprint as development, not after it, which is the biggest practical difference from a Waterfall-style STLC. Testers write test cases from a user story's acceptance criteria as soon as the story is groomed, sometimes before a single line of code exists, then execute as builds land throughout the sprint instead of waiting for one "code complete" milestone. Definition of Done for QA usually means functional tests pass, no open critical or high-severity defects remain, and the acceptance criteria are demonstrably met, rather than resting on "the developer says it's finished."

Teams running agile ask this specifically to filter out candidates who've only worked in a Waterfall "test after dev is done" setup. If that's your only background, say so honestly and describe how you'd adapt, don't pretend otherwise.

This is the classic warm-up scenario precisely because it has no software to hide behind. Functional: does it write, does the cap fit both ends, does the clip hold onto a shirt pocket without falling off. Boundary: does it still write when nearly out of ink, does it work in extreme cold or heat. Negative: does it leak when held upside down, does it survive a drop from desk height, does the ink smear right after writing. Usability: is it comfortable to hold for twenty minutes, does the barrel color match what's printed on the packaging.

This question checks whether you can apply testing categories, functional, boundary, negative, usability, to something with zero code, which proves you understand the categories as concepts and not as Selenium-specific vocabulary.

A decision table maps every combination of input conditions to the expected output action, so instead of testing conditions one at a time you test the combinations together. It's the right tool whenever business logic depends on multiple independent conditions interacting: discount rules, loan approval logic, insurance premium calculation, anything where the rule is really "if A and not B and C, then do X."

Say a checkout applies a discount based on loyalty membership (yes/no) and cart value (over $100 or not). A decision table gives you four rows covering every combination: member plus high value gets 20% off, member plus low value gets 10% off, non-member plus high value gets 5% off, non-member plus low value gets nothing. Without the table it's easy to test each condition independently and think you've got coverage, while missing that the "member and high value" combination has its own special rule that never actually gets exercised.

State transition testing models a system as a set of states plus the events that move it between them, and you design test cases around valid transitions, invalid transitions, and the states themselves. It's the right technique whenever something has a lifecycle: order status, account status, a multi-step approval workflow.

Take an order: it can be Placed, Confirmed, Shipped, Delivered, or Cancelled. A state transition suite checks the valid path, Placed to Confirmed to Shipped to Delivered, but just as importantly it checks the invalid ones: can you cancel an order that's already Delivered, can you ship an order that was never Confirmed, what happens if two different processes try to move the same order to Shipped and to Cancelled at nearly the same moment. Those invalid-transition tests are usually where testers find bugs that happy-path scripted testing never touches.

Functional testing asks whether something works correctly. Usability testing asks whether a real person can figure out how to use it without help. A feature can be 100% functionally correct and still fail usability testing because users can't find the button, misread an icon, or can't tell what an error message is asking them to do.

Running one manually usually means recruiting five to eight representative users, research from the Nielsen Norman Group has shown five users typically surface most of the major usability problems in a design, giving them a task with no instructions, like "buy this item and apply a discount code," and watching where they hesitate, misclick, or give up. You're not fixing anything during the session, you're taking notes on friction points. The output is a list of specific moments where users struggled, not a pass or fail bug report.

You can't test every browser and device combination that exists, so the strategy starts with data. Pull your actual analytics for the browsers, OS versions, and screen sizes your real users are on, and weight your test matrix toward that instead of guessing. Most teams end up with a tiered matrix: a small "must pass every release" tier covering current Chrome, Safari, and your top mobile OS versions, and a wider "check before major releases" tier covering older browsers and less common devices.

The testing itself focuses on things that genuinely differ between environments: CSS rendering and layout breaks, date and currency formatting, touch versus mouse interaction, and browser-specific quirks like Safari's stricter local storage handling or iOS Safari's viewport-height bugs caused by the address bar. Tools like BrowserStack or Sauce Labs let you do this manually against real device farms instead of maintaining a physical device lab, which matters because emulators don't always reproduce things like real touch latency or memory constraints on older phones.

A bug report needs to let a developer reproduce the problem without asking you a single follow-up question. At minimum: a clear title that says what's wrong and where, exact steps to reproduce numbered in order, the expected result, the actual result, environment details (browser, OS, app version, user role, whether it's staging or prod), and evidence, a screenshot, a screen recording, or the relevant log lines.

The details people skip are usually the ones that matter most: was this reproducible every single time or only sometimes, what's the exact input data used (not "a long name" but the actual string that broke it), and severity versus priority, is this cosmetic or does it block a core flow. A bug report that just says "checkout is broken" with no repro steps bounces between dev and QA for a day before anyone even starts fixing it.

Entry criteria are the conditions that must be true before testing can start: the build is deployed to the test environment, smoke tests pass, test data is loaded, and any blocking dependencies are available. Exit criteria are the conditions that must be true before you call testing done: a target percentage of planned test cases executed, no open critical or high-severity defects, and any remaining open defects reviewed and accepted by the product owner.

These get defined in the test plan, usually agreed between the test lead, project manager, and product owner, and they matter because without them "testing is done" turns into a subjective argument at the worst possible time, the night before release. A common failure mode is skipping entry criteria under deadline pressure, testers start executing against a build that hasn't even passed smoke tests, and half the session gets burned on environment problems instead of real bugs.

Without statement or branch coverage numbers, you fall back to requirement-based and risk-based coverage. You map every requirement or user story to at least one test case in a traceability matrix, and coverage becomes "what percentage of requirements have at least one passing test case," not "what percentage of code lines got executed." You can also track coverage by feature area or risk level, making sure high-risk areas carry proportionally more test cases than a low-risk cosmetic one.

In practice this is a decent proxy but it has a real blind spot: a requirement can have a test case that "covers" it on paper while only exercising the happy path, so it looks fully covered while huge chunks of actual logic, error handling, edge cases, unusual data, never get touched. Good testers pair requirement coverage with an honest look at equivalence classes and boundary values for each requirement, not just a checkbox that says a test case exists.

This is risk-based testing in practice: you rank features by probability of failure times impact if it fails, and spend limited hours on the top of that list first. Probability of failure is usually driven by how much code actually changed, how complex the logic is, and how new or junior the developer who wrote it is. Impact is driven by how many users touch the flow and how bad it is if it breaks, payment and auth flows are almost always near the top, a rarely used admin settings page is near the bottom.

Concretely, I'd pull the diff or changelog first, not guess, and prioritize testing around what actually changed plus anything that shares code paths with it, since regressions cluster around recent changes. I'd also explicitly flag to the product owner what's being descoped, "we're not testing the reporting export feature this cycle because nothing there changed," so the decision is visible and owned by the business, not silently absorbed by QA.

Defect density is the number of confirmed defects divided by size, usually defects per thousand lines of code or defects per feature or module, and it tells you which parts of the codebase are the buggiest relative to their size, useful for deciding where to focus code review or refactoring effort. Defect leakage is the percentage of defects that escaped one test phase and got caught later, or worse, in production: leakage equals defects found after release divided by total defects found, expressed as a percentage.

High leakage from a specific phase, say a lot of bugs escaping system testing and getting caught in UAT, signals your system test cases aren't covering something UAT naturally exercises, real end-to-end user workflows instead of isolated feature checks. Teams track leakage over multiple releases to see whether their test process is actually improving or just staying lucky.

All three are static testing techniques, meaning you examine a document or code without executing it, but they differ in formality. A walkthrough is informal, the author leads a group through the document explaining their thinking, and feedback happens live in the room. An inspection is the most formal: there's a defined process, a moderator, reviewers who've read the material beforehand and logged issues in advance, and a documented defect list at the end, following something close to the Fagan inspection process IBM developed in the 1970s.

A formal review sits in between, it's planned and follows a defined process, but it's typically led by management or a senior stakeholder checking correctness against a standard, rather than the peer-driven, defect-hunting focus of an inspection. Most teams that say "we do code review" are really doing something closer to an informal walkthrough through pull request comments, which is fine for day-to-day work but doesn't have the rigor to reliably catch subtle requirement gaps the way a real inspection does.

Internationalization testing, often shortened to i18n, checks whether the application is built in a way that can support multiple locales at all: does the layout survive text that's 40% longer in German, does it handle a right-to-left language like Arabic without breaking, does it store dates and currency internally in a locale-neutral format. It's testing the architecture, not the content.

Localization testing, l10n, checks the actual translated content and locale-specific behavior for a specific market: is the Japanese translation accurate and not just machine-translated nonsense, does the address form match the fields a Japanese address actually needs, is the currency symbol and decimal separator correct for that locale, are dates shown as day/month/year versus month/day/year appropriately. You need solid i18n before l10n testing means anything, if the architecture can't handle a longer string, no amount of translation QA fixes the layout that breaks.

First I check environment differences that aren't obvious from the ticket: browser version, screen resolution, whether the reporter was logged in under a different user role, whether they were on a mobile network versus wifi, and whether the account had a specific data state, an empty cart versus one with items, a new account versus one with history. A huge share of "works on my machine" bugs are really environment or data-state bugs in disguise.

Second, I check timing and sequence, some bugs only appear if steps happen in a specific order or fast enough to trigger a race condition, so I try the steps both slowly and quickly. Third, I check whether it's actually intermittent rather than truly unreproducible, bugs involving caching, session state, or async calls need more than one failed attempt before you can honestly call them non-reproducible. Only after exhausting those do I mark it "cannot reproduce," and even then I ask the original reporter for a screen recording or the exact account used before closing it, because closing a real bug as unreproducible just means a customer hits it again later with no record of the first report.

The V-model pairs each development phase with a matching test phase. Going down the left side: requirements pair with acceptance test planning, high-level design with system test planning, low-level design with integration test planning, coding sits at the bottom. Going up the right side: unit testing, integration testing, system testing, acceptance testing. The part interviewers actually care about is that test planning starts opposite the matching design phase, before a single line of code exists, not after the build is handed over.

Expect a follow-up comparing this to pure Waterfall (which tests only after coding finishes) and to agile sprints, where the same idea gets compressed into days instead of months.

Regression testing re-runs existing tests to confirm a new change didn't break something that used to work. In practice the suite grows every sprint unless someone actively prunes it: add tests for the new feature and whatever the bug fix touched, retire tests for features that got removed, merge near-duplicate cases that test the same path with slightly different data.

Most teams under-invest in pruning, and end up with regression suites that take longer to run than the sprint that produced them, that's the honest, slightly cynical answer. Interviewers who've owned a suite for more than a year tend to nod at that. The ones who haven't sometimes push back, and that's a fair disagreement to have out loud.

Start functional: valid credentials succeed, invalid ones fail with a clear but not overly specific error message (security matters here), empty fields get caught before a network call even fires. Then boundary and equivalence cases on the password field length. Then negative and security-adjacent cases: SQL injection strings in the username field, session behavior after several failed attempts (lockout, CAPTCHA, rate limiting), password masking, and whether "forgot password" actually works. Then non-functional: does login respond fast enough under load, does it work across the two or three browsers the company actually supports, is the page usable with a screen reader.

The real test is whether you organize your answer at all. A candidate who jumps straight into fifteen random test cases with no structure signals less experience than one who says "I'd group this into functional, boundary, negative, security, and non-functional" and then gives two examples from each bucket.

Functional: a valid card and PIN dispense the correct amount and debit the right account, balance inquiry shows the correct figure, a mini-statement prints correctly. Boundary and negative: withdrawing more than the daily limit, more than the account balance, an amount not divisible by the machine's note denominations, entering the wrong PIN three times (does it lock the card, and does it say so clearly). Concurrency: two card swipes at the same physical machine seconds apart, or the same account accessed from an ATM and a banking app at the same time, does the balance stay consistent either way. Failure and recovery: a power cut mid-transaction (does the account get debited without dispensing cash, and does it reverse automatically), a network timeout between the ATM and the bank's server, running out of physical cash mid-queue.

This question is a favorite for anyone with two or more years of experience, because it forces a candidate to talk about concurrency and failure recovery, past the happy-path clicking most people default to. That's exactly the gap between fresher-level and experienced-level answers.

Defect clustering is the observed pattern that a small number of modules account for a disproportionate share of defects, in practice this tends to follow something close to the Pareto principle, roughly 80% of defects trace back to about 20% of the modules. It usually happens because that 20% is the oldest, most modified, most complex, or was written under the most deadline pressure, complexity and change frequency are the real predictors, not randomness.

The practical implication is that once you have a release or two of defect history, you stop treating every module as equally likely to break and start weighting test effort by historical defect density. If the payments reconciliation module produced 40% of your last three releases' bugs, it should get more test time, more exploratory sessions, and more regression coverage than a module that's been stable for a year, even though both "feel" equally important on paper. Ignoring this means spreading a fixed test budget evenly across all modules and under-testing the ones statistically guaranteed to keep producing bugs.

The pesticide paradox is the observation that if you run the same set of test cases over and over, they eventually stop finding new bugs, not because the software got perfect, but because the software evolved past what those specific tests check for, the same way insects develop resistance to a pesticide that used to kill them. A regression suite that hasn't changed in two years is very good at proving old bugs stay fixed and nearly useless at finding new ones.

The fix is to keep revising and adding to the suite, not just running it: review it every release, retire cases for functionality that's been stable a long time, and reallocate that time to new equivalence classes, new boundary values, and new exploratory charters around whatever changed recently. I also treat production incidents as a direct input, every real bug that escaped to production should generate at least one new regression test case that specifically would have caught it, otherwise you're guaranteed to see some version of that same bug again once the fix gets refactored.

I'd use a tool like Postman or curl and work through it systematically instead of just hitting the happy path. Start with the contract itself: does every field marked required in the spec actually get rejected with a 400 when missing, does the response match the documented schema and status codes for every documented error, not just the 200s. Then negative and boundary cases: send a string where an integer is expected, send a negative number for a quantity field, send a payload that's technically valid JSON but semantically wrong, a start date after an end date, send an empty array where the API expects at least one item.

A few things get missed constantly. Idempotency, does calling the same POST twice create two records when it should create one, or return the same result safely for a PUT. Pagination edge cases, does requesting page zero or a page beyond the last one behave sensibly instead of erroring or returning garbage. And authorization boundaries, does a request with a valid token for user A actually get rejected when trying to reach user B's resource by just swapping the ID in the URL.

That last one, broken object level authorization, is one of the most common real vulnerabilities in production APIs, and manual testers can catch it just by deliberately changing an ID in a request, no automation needed.

GET /api/orders/1042  (token belongs to user A)
GET /api/orders/1043  (should return 403 or 404, not user B's order data)

The core technique is forcing two actions to overlap on purpose instead of hoping to catch it by accident. Open the same record in two sessions, two different browsers or one normal and one incognito, logged in as different users or the same user, load both, then submit changes from each within a second or two of each other and check what actually got saved. You're looking for lost updates, one user's change silently overwriting the other's with no warning, and whether the system uses optimistic locking, a version number or timestamp check that rejects the second save with a conflict message, or has no protection at all.

A specific case worth testing deliberately is inventory and payment flows: add the last unit of a limited-stock item to two different carts, then check out both nearly at once and see whether the system correctly sells only one and rejects the other, or oversells. You can also simulate slower race conditions by intentionally throttling network speed in dev tools on one tab so its request lands later, which gives you control over exact ordering instead of relying on both requests happening to overlap naturally. These bugs rarely show up in normal single-user scripted testing, which is exactly why they survive into production so often.

Without historical defect or effort data, I break the work down first, work breakdown structure style, listing every testable feature or module, then estimate test case count and execution time per module rather than trying to estimate the whole project as one number. For each module I use three-point estimation, best case, worst case, and most likely, and average them with something close to the PERT formula, (best plus 4 times likely plus worst) divided by 6, because a single-point guess is almost always wrong in a way that quietly compounds across dozens of modules.

I also compare against similar past projects even if this exact one has no history, most companies have tested something structurally similar before, a CRUD-heavy admin panel, a checkout flow, a reporting dashboard, and those give a rough per-module baseline to adjust for this project's complexity. Finally I explicitly budget time for things that always get forgotten in estimates: test environment setup and instability, test data creation, defect retesting cycles (a bug found once usually needs at least one retest pass), and regression testing after fixes land. Those four categories alone commonly eat 30 to 40% of total test time and get left out of naive "test case count times average execution time" estimates.

I don't start writing test cases against nothing, I start by reconstructing intent. I talk directly to whoever asked for the feature, usually product or the developer who built it, and ask what problem it's solving and what a user would actually do with it, then write down what I understood as a quick informal spec and get it confirmed back before testing starts. That confirmation step matters because it surfaces disagreements early, sometimes the developer built one interpretation and the product owner wanted a different one, and it's much cheaper to catch that mismatch before a test cycle than after.

Once there's a rough shared understanding, I lean harder on exploratory testing and use-case-based testing than on scripted test cases, since there's no formal spec to write cases against yet, and I document every assumption directly in the bug reports or test notes, "assuming X should happen when Y, confirm if this is intended," so ambiguity becomes visible instead of silently turning into a bug report that gets rejected as working as intended. I also push back, gently but clearly, that shipping a customer-facing feature with zero documented acceptance criteria is a process gap worth fixing before the next one, not something to just quietly absorb every time.

Equivalence partitions: below 8 (invalid), 8 to 20 (valid), above 20 (invalid). Boundary values: 7 and 8 (lower edge), 20 and 21 (upper edge). Combined, a solid test set covers 7 (fail), 8 (pass), 14 (pass, mid-range representative), 20 (pass), and 21 (fail), five test cases instead of testing every length from 1 to 50.

A strong candidate also flags the ambiguous part out loud: does "8 to 20" mean inclusive on both ends? Real requirements documents are frequently unclear about exactly this, and asking the clarifying question is itself a signal interviewers are listening for.

First I get the actual facts straight before anyone starts arguing opinions: what's the exact scope of the bug, does it affect all users or a narrow segment, is there a workaround, and what's the blast radius of shipping versus the cost of delaying. I don't make the ship or hold call alone, that's a decision for the release owner or product lead, but my job is to hand them an accurate, unpanicked risk assessment fast, not a vague "this is bad" with no detail.

Then I lay out three realistic options with tradeoffs: ship as-is with the bug present, ship with a feature flag that disables just the broken piece so the rest of the release still goes out, or delay the whole release. Feature-flagging around the broken part is usually underused, if the bug is isolated to one feature and the rest of the release is solid and tested, disabling that one thing is often better than blocking everything else that's ready. If we do decide to ship with a hotfix, I make sure the fix is already tested and staged, not "we'll write it and test it after it's already in front of customers," and I flag exactly what regression testing that hotfix still needs, because a rushed hotfix under pressure is where a lot of second bugs get introduced.