See exactly what you get for ₹99

Say this: "7, 8, 9, 15, 16 and 17 — boundary value analysis: each boundary and its immediate neighbours. Just below the minimum, the minimum itself, just above; then the same at the maximum."

Say why, because that's the actual question: "Defects cluster at boundaries. A developer writes > where they meant >=, so a 16-character password gets wrongly rejected while a 12-character one works perfectly. Testing 8 and 16 alone misses exactly the off-by-one that BVA exists to catch."

Follow-up: "What else would you test on that field?" → Empty, exactly 8 spaces, non-ASCII characters, a very long paste, and whether the check is enforced server-side or only in the browser. Those are equivalence classes rather than boundaries.

Follow-up: "How is BVA different from equivalence partitioning?" → ECP divides input into classes that behave the same and tests one value from each. BVA then adds back the edges of those classes. Used together, you get high coverage from very few tests.

Don’t say: "Test every length from 1 to 20." Exhaustive testing is impossible in practice — that's literally one of the seven testing principles, and reaching for it signals you don't have a technique.

Say this: "Verification is building it right — checking the work products against the specification, without executing anything. Reviews, walkthroughs, inspections. Validation is building the right product — running the software and checking it against what the user actually needs."

Give the example immediately: "Reviewing the requirements document against the design is verification. Running a system test on the order flow is validation."

Follow-up: "Can something pass verification and fail validation?" → Yes, and it's the classic case: the team built exactly what the specification said, and the specification was wrong. The product matches the document and still doesn't solve the user's problem.

Follow-up: "Isn't this the same as QA versus QC?" → Related but different. QA is process-oriented and preventive; QC is product-oriented and detective. Verification and validation are both activities that sit inside those.

Don’t say: The two swapped round. It's the most common slip on this question, and it's usually the very first thing asked in a QA round — get it wrong and you spend the rest of the interview recovering.

Say this: "Testing is evaluating software to find defects and to confirm it actually meets the requirements and the user's needs. It's needed because it reduces risk and cost — a bug caught in requirements costs a fraction of the same bug found in production — and because a single visible failure damages the company's reputation with users."

Add the honest limit — it scores: "But testing can only show the presence of defects, never their absence. I can say 'these scenarios pass', not 'there are no bugs'."

Follow-up: "Why can't you test everything?" → Exhaustive testing is impossible — even one login form has effectively infinite input combinations. So you prioritise by risk and use techniques like equivalence partitioning to get coverage with a sensible number of cases.

Don’t say: "Testing means finding all the bugs." It sets an expectation no tester can meet, and the interviewer will immediately ask how you'd guarantee that.

Say this: "SDLC is the whole software development lifecycle — requirements, design, build, test, deploy, maintain. STLC is the testing lifecycle that sits inside it: requirement analysis, test planning, test case design, environment setup, execution, and closure. So STLC is one phase of SDLC expanded into its own process."

Follow-up: "What are the deliverables of each STLC phase?" → Requirement analysis gives the RTM, planning gives the test plan and estimates, design gives test cases and test data, execution gives defect reports and the status report, closure gives the test summary report. Naming the artefacts is what makes this answer sound like experience.

Follow-up: "When does testing start?" → At requirements, not at build. Reviewing a requirement and finding it ambiguous is testing — that's static testing, and it's the cheapest defect you'll ever find.

Don’t say: "STLC happens after SDLC." STLC is inside SDLC and runs in parallel with development, which is the entire point of the V-model.

Say this: "Verification asks 'are we building it right?' — checking the work products against the specification, without executing the software. That's reviews, walkthroughs and inspections. Validation asks 'are we building the right product?' — executing the software and checking it against what the user actually needs."

Give the example immediately: "Reviewing the BRD against the design document is verification. Running a system test and confirming the order flow works the way the customer expects is validation."

Follow-up: "Can something pass verification and fail validation?" → Yes, and it's the classic case: the team built exactly what the specification said, and the specification was wrong. The product matches the document and still doesn't solve the user's problem.

Don’t say: "Verification is dynamic." It's static — no code runs. That one word is how this answer is marked right or wrong.

Say this: "QA is process-oriented and preventive — defining standards, running reviews and audits, improving how the team works so defects don't get created. QC is product-oriented and detective — inspecting and testing the actual deliverable to find defects that are already there. Testing is part of QC."

Follow-up: "Give an example of each from a project." → QA: introducing a definition of done that requires unit tests before a story is accepted. QC: executing the regression suite on the release build.

Follow-up: "Which is cheaper?" → QA. Preventing a defect costs less than finding and fixing one, which is why mature teams invest in process rather than only in more test cycles.

Don’t say: "QA means automation." Very common confusion in interviews — automation is a technique used within QC, and has nothing to do with the QA/QC distinction.

Say this: "Smoke testing is broad and shallow — a quick check of the critical paths on every new build to decide whether the build is even worth testing. It's sometimes called build verification. Sanity testing is narrow and deep — after a small fix or change, I check that specific area works, before committing to a full regression."

Say the practical consequence: "If smoke fails, the build is rejected and goes back to the developers — I don't spend a day testing a build where login is broken."

Follow-up: "Which comes first?" → Smoke, on the new build. Sanity comes after, once you know the build is stable and you're verifying a particular change.

Follow-up: "Are they scripted?" → Usually not formally — they're quick and often unscripted, though the smoke suite is typically automated because it runs on every single build.

Don’t say: "They're the same thing." Many teams use the words loosely, but in an interview the broad-versus-narrow distinction is exactly what's being checked.

Good answer hits: Verification — static checking of work products against the specification, through reviews and walkthroughs, with no code executed. Validation is the other one: "are we building the right product", by executing against user needs.

One-liner: "Verification — building it right, statically, against the spec."

Follow-up they add: "Can something pass verification and fail validation?" → Yes — you built exactly what the document said and the document was wrong.

Good answer hits: Smoke testing — a broad, shallow check of the critical paths to decide whether the build is stable enough to test at all. Also called build verification. If it fails, the build is rejected back to development.

One-liner: "Smoke — broad and shallow, to decide if the build is worth testing."

Follow-up they add: "And sanity?" → Narrow and deep, after a specific fix, before committing to full regression.

Good answer hits: Retesting — re-executing the exact failed case with the same data to confirm the fix works. Regression is the other one: re-running previously passing tests to check the fix broke nothing else.

One-liner: "Retesting — the failed case. Regression is the passing ones."

Follow-up they add: "Which comes first?" → Retest. No point running regression if the fix itself doesn't work.