Software Testing Foundations Interview Questions

Quality is a broader property of the whole product and process (meeting user needs, being maintainable, performing well); testing is one specific activity used to gather evidence about quality -- testing can reveal defects, but it doesn't itself build quality in, and passing tests doesn't guarantee a genuinely high-quality product.

Testing can only demonstrate the presence of defects (by finding them), not their absence -- the space of possible inputs and states for any non-trivial program is effectively too large to exhaustively test, so passing tests shows 'no defects found by these specific tests,' not 'no defects exist.'

A testable requirement states a precise, verifiable expected outcome (e.g. 'the page loads within 2 seconds on a 3G connection') rather than a vague goal ('the page should be fast'). An ambiguous requirement forces testers to guess intent, producing test cases that may not match what stakeholders actually meant -- a cost that surfaces late, often as a dispute over whether a bug is really a bug.

Common mistake: Writing test cases against a vague requirement without first clarifying what specific, measurable outcome is actually expected.

Verification asks 'are we building the product right?' (does it conform to its specification); validation asks 'are we building the right product?' (does it actually meet the user's real need) -- software can pass verification (match its spec exactly) while still failing validation (the spec itself was wrong).

A defect found during requirements review or design costs far less to fix than the same underlying defect discovered after the feature is fully built and shipped -- by that point it may require reworking code, retesting, and potentially fixing data already affected in production.

A defect (or fault) is a flaw in the code itself; a failure is the observable, incorrect behavior that results when that defect is actually triggered during execution -- a defect can exist in code for a long time without producing a failure, if the specific conditions that trigger it never occur.

Developers testing their own code tend to (often unconsciously) test the paths they already had in mind while writing it, and can share the same misunderstanding of a requirement that caused the bug in the first place -- independent testing brings a different perspective more likely to catch what the original author overlooked.

Reading requirements critically to identify ambiguity, missing edge cases, and implicit assumptions before test design even begins -- a tester analyzing requirements often surfaces questions ('what should happen if the field is empty?') that improve the requirement itself, not just the eventual test cases.

It frames quality-related spending as either prevention/appraisal costs (testing, reviews, training -- paid deliberately, up front) or failure costs (bugs found in production, customer support burden, reputational damage -- paid involuntarily, later, usually at a higher total cost) -- testing investment is justified by shifting cost from the more expensive failure category to the cheaper prevention category.

A vague description forces the developer to spend time reproducing the issue from scratch before they can even start diagnosing it -- effective testing communicates specifically what was expected, what actually happened, and how to reproduce it, treating the developer's time as a real constraint.

Unit testing verifies a single small piece of code (a function/method) in isolation; integration testing verifies that multiple units/components work correctly together; system testing verifies the entire integrated application against its overall requirements, end to end.

Testing conducted to determine whether the system satisfies the business/user's actual acceptance criteria, often performed by (or with) stakeholders or end users rather than only the technical team -- it answers 'is this actually ready to ship/accept,' distinct from earlier levels focused on technical correctness.

A test level describes the SCOPE being tested (unit, integration, system, acceptance -- how much of the system is under test at once); a test type describes the QUESTION being asked about that scope (functional correctness, performance, security, usability) -- the two are independent dimensions that combine (e.g. system-level performance testing).

Functional testing verifies WHAT the system does (does this feature produce the correct output for a given input); non-functional testing verifies HOW WELL it does it (performance, security, usability, reliability) -- a feature can be functionally correct while still failing a non-functional requirement like acceptable load time.

Re-running previously-passing tests after a code change to confirm the change didn't break existing functionality -- typically run after bug fixes, refactors, or new feature additions, since new changes can have unintended side effects on unrelated, already-working parts of the system.

A minimal set of tests confirming the most critical functionality works at all (e.g. 'does the app even launch, can a user log in') -- it's meant as a quick sanity gate to decide whether a build is stable enough for further, more thorough testing, not a substitute for that deeper testing.

Black-box testing designs test cases based only on the system's specified behavior/inputs-outputs, without knowledge of its internal code; white-box testing designs test cases with knowledge of the internal code structure (e.g. ensuring every branch is executed) -- both are valid, complementary approaches at different levels.

The standard testing pyramid recommends many fast unit tests, fewer integration tests, and even fewer slow end-to-end tests; an 'inverted' suite (mostly slow, brittle end-to-end tests with few unit tests) tends to run slowly, be harder to debug when it fails, and give less precise localization of what actually broke.

Usability testing evaluates how easily real users can accomplish tasks with the system, often through observing actual users attempting realistic tasks and noting confusion/friction points -- functional testing checks 'does it work correctly against a spec,' while usability testing checks 'can a real person actually use it effectively.'

It suggests unit-level test coverage has a real gap for that code path -- relying on later, more expensive test levels to catch what earlier, cheaper levels should have caught is a symptom worth investigating, not just a one-off bug to patch and move past.

Grouping an input space into partitions where every value in a partition is expected to be handled the same way by the system, then testing just one representative value per partition -- it solves the impossibility of testing every possible input by reducing an infinite input space to a small, defensible representative set.

Testing values right at, just below, and just above a valid range's edges (e.g. for an age field accepting 18-65: test 17, 18, 65, 66) -- boundaries are where off-by-one errors in conditional logic (`<` vs `<=`) most commonly hide, since the 'interior' of a valid range is usually handled correctly by simpler logic.

Common mistake: Testing only comfortably-interior values of a valid range and missing the exact boundary values where off-by-one bugs most often hide.

Equivalence partitioning identifies the meaningful groups/ranges to test; boundary-value analysis then focuses extra attention on the edges of those specific partitions -- used together, they produce a small but high-value set of test cases rather than either technique alone.

A structured table mapping every meaningful combination of input conditions to the corresponding expected outcome/action -- especially useful when a feature's behavior depends on the combination of several independent conditions (e.g. discount eligibility depending on membership tier AND order size AND promo code), where testing conditions individually would miss interaction effects.

A technique modeling a system's valid states and the events that transition it between them, then testing both valid transitions and invalid ones (attempting a transition that shouldn't be allowed from a given state) -- best suited to systems with clearly-defined states, like an order's lifecycle (pending → shipped → delivered) or a login/session flow.

A system that only correctly enforces valid transitions but silently allows an invalid one can end up in a genuinely inconsistent, hard-to-recover state -- verifying the system correctly REJECTS an illegal transition is often what catches a real bug that testing only the happy path would miss entirely.

Partitions might be: too short (<8), valid length (8-20), too long (>20) -- one representative test case per partition, then boundary-value analysis adds specific edge tests at exactly 7, 8, 20, and 21 characters to catch off-by-one errors at the range's actual limits.

'Defensible' means you can justify to a stakeholder exactly why each test case exists and what specific risk it covers -- as opposed to an arbitrarily large pile of tests with unclear purpose, or too few tests chosen without a systematic rationale, a defensible set demonstrates deliberate, explainable coverage decisions.

Treating 'any text' as a single partition and testing only one example -- free-form text fields often have hidden sub-partitions worth testing separately: empty string, extremely long input, special characters, and internationalized/non-ASCII text, each of which can expose different bugs.

Automation tools execute whatever test cases you give them exactly as written -- they don't decide WHICH cases are worth testing. The design techniques are what determine the actual coverage and value of the automated suite; automating a poorly-designed set of test cases just runs bad coverage faster.

Simultaneous learning, test design, and test execution -- a tester actively investigates the application, using what they discover to inform their next test, rather than following a pre-written script step by step. It's especially good at finding unanticipated issues that a fixed test plan, designed before seeing the actual system, wouldn't have thought to check.

Effective exploratory testing is still purposeful -- often guided by a time-boxed 'charter' describing an area/risk to investigate -- with the tester actively taking notes on what was tried and found, so the session's coverage and results are still communicable and repeatable, not just an untracked ad hoc session.

An approach to allocating limited testing time by prioritizing areas of highest risk -- typically assessed as likelihood (how probable is a defect in this area) multiplied by impact (how bad would the consequences be if it failed) -- so testing effort concentrates where it matters most, rather than spreading evenly regardless of actual risk.

Risk-based prioritization weighs impact, not just likelihood of use -- a low-frequency feature whose failure would have severe consequences (a failed compliance export, a broken payment refund) can rank as high-risk overall even though most users rarely touch it.

Explicitly identify and document the lowest-risk areas being deliberately deprioritized (low likelihood of defect AND low impact if one occurs), and communicate that decision to stakeholders -- an unstated gap in coverage is a hidden risk; an explicitly acknowledged one is a managed tradeoff.

Scripted tests only check what was anticipated in advance; exploratory testing near release can catch integration issues, unexpected interactions between recently-changed features, or usability problems that a pre-written test plan (designed earlier, potentially before the final build existed) wouldn't have covered.

A brief, focused mission statement for an exploratory testing session -- e.g. 'explore the checkout flow's handling of expired discount codes for 30 minutes' -- giving the session a clear scope and purpose without pre-scripting every specific step to take.

Risk depends on context that can shift independently of the code -- e.g. a feature's usage growing significantly increases the impact of a defect in it, or new regulatory requirements increase the consequences of a compliance-related bug -- so risk-based prioritization needs periodic re-evaluation, not a one-time assessment.

A tester exploring the application with fresh eyes may discover a scenario the scripted test cases never considered at all -- revealing not just a product bug, but a gap in the test design itself, prompting the scripted suite to be updated to cover that newly-discovered scenario going forward.

Exhaustive testing is mathematically impossible for any non-trivial system (per the earlier point about testing only showing presence, not absence, of defects) -- acknowledging finite time honestly, then deliberately prioritizing by risk, is a more defensible strategy than pretending full coverage is achievable and then falling short unpredictably.

A clear title, exact steps to reproduce, the expected result, the actual result, environment details (browser/OS/version), severity/priority, and supporting evidence (screenshot, log, or video) -- enough detail that a developer can reproduce and diagnose the issue without needing to ask clarifying questions first.

Severity measures the technical impact of the defect on the system (how badly it breaks functionality); priority measures how urgently it should be fixed relative to other work (a business/scheduling decision) -- a low-severity cosmetic bug on the homepage might still get high priority due to visibility, while a severe bug in a rarely-used admin tool might get lower priority.

A developer who can't reliably reproduce a bug can't confidently verify their fix actually addresses it -- precise, ordered reproduction steps turn a vague 'sometimes this breaks' report into a concrete, actionable, and eventually re-testable scenario.

A matrix mapping requirements to the test cases that verify them (and often to their execution results) -- it helps catch requirements with zero test coverage, and conversely, test cases that don't map back to any actual requirement, both of which represent a real gap or waste worth investigating.

Automation pays off best for tests that are run repeatedly (regression suites), are stable/well-defined, and are tedious or error-prone to execute manually; manual testing (especially exploratory) remains valuable for scenarios needing human judgment, rarely-run one-off checks, or areas still actively changing where automation would need constant rewriting.

If the feature's UI/behavior is still in flux, the automated tests need constant rewriting to keep up with each change -- the maintenance cost of a premature automated suite can exceed the manual-testing time it was meant to save, until the feature stabilizes.

In agile, testing happens continuously throughout the sprint alongside development (often the same sprint a feature is built in), with testers involved early in story refinement/acceptance-criteria discussions -- rather than testing being a separate, later phase that only begins once 'development is done.'

Verifying keyboard-only navigation reaches every interactive element, checking that images have meaningful alt text, confirming visible focus indicators exist, and running an automated scanner (like axe) to catch common issues -- a genuinely thorough accessibility audit needs deeper expertise, but these basic checks catch real, common gaps.

Trying obviously-invalid or malicious-looking input in form fields (extremely long strings, script tags, SQL-like syntax) to see if the application handles it gracefully rather than erroring or behaving unexpectedly, and verifying that access-restricted pages genuinely reject unauthorized access rather than just hiding a link to them.

As the application evolves, some tests become obsolete (testing removed features), some need updated expected values (behavior legitimately changed), and some become flaky -- a regression suite left unmaintained accumulates noise that erodes trust in its results, the same failure mode as a defect report nobody can act on.