Testing: Levels & Techniques

1. What is the difference between verification and validation?

Verification asks “are we building the product right?” Validation asks “are we building the right product?” Verification checks conformance to specification; validation checks satisfaction of user needs.

Verification is mostly static — it examines documents, designs, and code against what was specified, through walkthroughs, code reviews, and inspections, without running the software. It catches errors of implementation: the work does not match what was agreed. Validation is dynamic — it runs the software and checks it against the user’s real needs, through execution and testing. It catches errors of expectation: even a product built perfectly to spec does not help the user.

A classic analogy is building a house. Verification checks the walls are straight and match the blueprint. Validation asks whether you actually want to live there. A product can pass every verification review and still fail validation if the original specifications were wrong. Both matter, and they answer different questions.

2. What is black-box testing?

Black-box testing tests the software purely from the outside, treating it as a closed box — the tester has no knowledge of the internal code, structure, or implementation. Testing is based entirely on the specification: inputs go in, outputs come out, and the tester checks whether the behavior matches what was specified.

The tester designs test cases from the requirements and functional specification. Techniques used in black-box testing include equivalence partitioning, boundary value analysis, decision tables, and state-transition testing — all of which generate inputs without needing to see the code.

The strengths are that it tests from the user’s perspective, catches mismatches between spec and behavior, and requires no code knowledge — it can be done by testers, product owners, and even end users. Its weakness is that it can miss code paths never triggered by the chosen inputs — internal branches, unreachable error handling, and uncovered logic. That is why black-box and white-box testing are combined.

3. What is white-box testing?

White-box testing — also called glass-box or structural testing — tests the software with full knowledge of its internal structure. The tester reads the code, understands the branches, conditions, and paths, and designs test cases to exercise that internal logic.

The goal is coverage of the code itself. Techniques include statement coverage (every line executes at least once), branch coverage (every if/else outcome is taken), condition coverage (every boolean condition is tested both true and false), and path coverage (every logical path through the code is executed). Tests are designed by reading the code, not just the spec.

Its strength is thoroughness — it finds defects that black-box testing misses, like code paths never exercised and dead or unreachable code. Its weakness is that it tests the code against itself: if the code is correct but the specification is wrong, white-box testing will happily confirm the wrong behavior. And it requires code access and skill. Unit testing is the classic home of white-box techniques.

4. What is grey-box testing?

Grey-box testing sits between black-box and white-box: the tester has partial knowledge of the internal structure but tests from the outside. It is testing with some insight into the code, but not the full code-level view.

In practice, grey-box testers know the architecture, the interfaces between modules, and the data model — enough to design smarter test cases — but they do not trace every branch of the implementation. They test through the user interface or public APIs like black-box testers, but use their structural knowledge to target high-risk areas.

Grey-box testing is very common in real projects. Integration testing and end-to-end testing often work this way — the tester understands how components interact and tests through their interfaces, using that understanding to pick inputs that will stress the seams. It balances the user perspective of black-box testing with the structural targeting of white-box testing. Tools like code coverage metrics plus black-box test cases create a de facto grey-box approach.

5. What is functional testing?

Functional testing verifies that the software does what it is supposed to do according to its functional requirements. It focuses on the behavior of the system — the functions, features, and operations — asking “does this feature work as specified?”

The tester checks each function against its specification: given the right inputs, the correct outputs occur; data is handled correctly; screens and workflows behave as documented. Functional testing is black-box in nature — it uses the specification, not the code, and tests through the interface or API.

Functional testing covers the range of user operations — valid and invalid inputs, error conditions, and the expected business logic. It does not concern itself with how the system is built internally or how well it performs. The key distinction in interviews: functional testing is about behavior (what the system does), non-functional testing is about qualities (how well it does it). Functional defects are “wrong results”; non-functional defects are “right results, but too slow, insecure, or unusable.”

6. What is non-functional testing?

Non-functional testing verifies the qualities of the system — how well it performs, not just whether it works. It checks attributes like performance, security, usability, reliability, scalability, and compatibility against non-functional requirements.

The main types: performance testing verifies speed and responsiveness; load and stress testing verify behavior under expected and extreme load; security testing checks the system resists attacks; usability testing evaluates whether real users can use the system easily; compatibility testing checks it works across browsers, devices, and platforms; reliability testing checks it runs without failure over time.

Non-functional testing matters because a system that is functionally correct can still be useless — a login page that responds in thirty seconds, a payment system with a known vulnerability, or an interface nobody can figure out all fail non-functional requirements. The difficulty is that non-functional requirements are often stated vaguely (“the system should be fast”) and must be made measurable (“the login must respond within two seconds”). Non-functional testing is often what separates a working system from a shippable product.

7. What is unit testing?

Unit testing tests the smallest testable parts of the software — individual functions, methods, or classes — in isolation from the rest of the system. It verifies that each unit behaves correctly on its own.

Unit tests are written and run by developers, usually with a test framework (JUnit, pytest, Jest), and are heavily white-box: the developer knows the code and designs cases to cover its branches and paths. Each unit test sets up inputs, calls the unit, and asserts the expected output. Dependencies on other units are typically replaced with mocks or stubs so the test isolates the unit itself.

The value of unit testing is early defect detection and safe change. Bugs found at unit level are the cheapest to fix, and a good unit test suite gives developers the confidence to refactor — if they break something, the tests catch it immediately. Unit tests are also the foundation of test-driven development (TDD) and continuous integration, running fast and frequently. Their limitation is that they prove only that the parts work, not that the parts work together.

8. What is integration testing?

Integration testing verifies that individual units, which each work in isolation, work correctly together. It tests the interfaces between modules — the seams where the classic integration bugs live: mismatched data formats, wrong assumptions about call ordering, broken contracts between components.

Integration testing approaches differ by how components are combined. Big-bang integration assembles all modules at once and tests the whole — fast to set up but very hard to debug when something fails, because the fault could be anywhere. Incremental integration combines modules a few at a time. Top-down integration starts with the high-level modules, using stubs for the missing lower ones. Bottom-up integration starts with low-level modules, using drivers to call them, and works upward.

Integration tests catch defects that unit tests cannot — the system-level problems where components disagree. The most effective approach is incremental, combining modules in an order that matches the architecture, so a failure can be localized to the latest addition. Integration testing is where the “it works on my machine” problem becomes “it works together.”

9. What is system testing?

System testing tests the complete, integrated system as a whole against its requirements. All the components are assembled, and the tester validates the full product as the user will experience it — end to end, through the real interfaces.

System testing is black-box in nature: it tests the entire system against the SRS and functional specifications, covering functional behavior, non-functional qualities like performance and security, and the system’s overall compliance. It runs in an environment as close to production as possible, with real data and real configurations.

The distinction from integration testing: integration proves the parts fit together; system testing proves the finished whole meets its requirements. System testing is the last comprehensive check before acceptance — it is where the team asks “does this complete product do what we agreed it would do?” A defect that escapes system testing reaches the customer, which is why system testing is thorough and why it comes before acceptance testing, where the customer makes the final judgment.

10. What is acceptance testing?

Acceptance testing is the final level of testing, where the customer or end user validates that the system meets their needs and accepts it. It answers “is this the right product?” and it is the formal gate for taking delivery of the software.

Acceptance testing is black-box and driven by user acceptance criteria derived from the requirements. Common forms include user acceptance testing (UAT), where real users execute real business scenarios; alpha testing, done by a small group of internal users in a controlled environment; and beta testing, where a larger set of external users try a near-final version in real-world conditions. Contract and regulation acceptance testing check compliance with contractual or regulatory requirements.

Acceptance testing is different from system testing: system testing is done by the development team to verify the system meets its specification; acceptance testing is done by the customer to verify the product meets their actual needs. Passing acceptance testing marks the transition from development to deployment — the customer signs off and the system goes live. A system can pass every internal test and still fail acceptance if it does not fit how the customer actually works.

11. What is regression testing?

Regression testing re-runs existing tests after a change to the software — a new feature, a bug fix, or a refactor — to verify that the change did not break anything that already worked. Its purpose is to catch regressions: defects introduced by the change itself.

The scope of regression testing depends on how the change might ripple. A change to a small, isolated module may only require re-testing that module and its direct dependents. A change to a widely used function may require re-running the full test suite. The selection problem — which tests to re-run — is important, because re-running everything is slow and re-running too little misses regressions.

Regression testing is where automated test suites pay off most. Because the same tests must be re-run again and again after every change, a fast automated suite makes regression testing cheap and continuous. Without automation, teams do manual regression testing, which is slow, incomplete, and gets skipped under time pressure. In Agile, regression testing runs every sprint to protect the increment from accumulating breakage.

12. What is retesting?

Retesting is re-running a specific test on a fixed defect to confirm that the defect has actually been corrected. It targets one thing: verify that a previously failing test case now passes after the developer’s fix.

The distinction with regression testing is the common interview trap. Retesting checks the specific defect that was fixed — the exact test that previously failed is run again against the new code. Regression testing checks the rest of the system — the tests that previously passed are re-run to ensure the fix did not break anything else.

In practice, both happen together after a fix: retest the corrected defect, and run regression tests on the surrounding functionality. The conceptual difference is clear: retesting confirms the fix worked; regression testing confirms the fix did not introduce new damage. Both are necessary, and conflating them is a classic interview mistake.

13. What is the difference between regression testing and retesting?

Retesting verifies that a specific fixed defect is actually fixed — the previously failing test is re-run against the new code to confirm the fix. Regression testing verifies that the change did not break anything else — previously passing tests are re-run to catch new defects introduced by the change.

Retesting is narrow and targeted: one defect, one fix, one confirmation. It is performed on the changed code with the test that exposed the defect. Regression testing is broad and protective: the surrounding system, re-checked after every change. It covers not just the fixed area but everything that could be affected by the change.

The two are complementary and usually run together after a fix — first retest the corrected defect, then run regression tests on the wider system. An important nuance: retesting confirms a known defect is gone; regression testing hunts for unknown, newly introduced defects. The interview answer should lead with that distinction.

14. What is smoke testing?

Smoke testing is a quick, shallow pass over the main functionality of the software to verify that it is stable enough for deeper testing to begin. It answers “is this build even worth testing?” — if the smoke test fails, the build is rejected and sent back to the developers.

The name comes from hardware: if you power on a circuit board and it produces smoke, you stop testing and fix the hardware first. Smoke testing applies the same idea — run a small set of critical, high-level tests covering the core paths — and if they pass, continue; if not, reject the build.

Smoke tests are intentionally fast and few — they do not explore edge cases, they just verify that the application starts, the main screens load, and the essential flows work. In modern practice, smoke testing is often automated and runs as part of continuous integration on every build, so a broken build is caught within minutes. Its purpose is not thoroughness but early triage: fail fast and cheap, before investing in a broken build.

15. What is sanity testing?

Sanity testing is a quick, narrow check that a specific area of the software works after a minor change or a small fix, to decide whether more detailed testing of that area is worthwhile. It answers “did this small change break the obvious things in its vicinity?”

Sanity testing is shallow and targeted — it focuses on the area affected by the change and verifies the basic functionality there is intact, without going deep. It is a subset of regression testing: a rapid sanity pass on the touched modules, not a full regression run.

The common distinction: smoke testing checks whether the whole build is stable enough to test at all, covering core functionality broadly. Sanity testing checks whether a specific changed area is stable enough to test deeply. Smoke is wide and shallow; sanity is narrow and shallow. Both are fast triage tools that decide whether to invest in fuller testing, and the difference between them is a classic interview question.

16. What is the difference between smoke and sanity testing?

Smoke testing is a broad, quick check of the entire build’s core functionality — does the application start, load its main screens, and work its essential paths? It is done on every new build to decide whether the build is stable enough to test at all. If it fails, the build is rejected.

Sanity testing is a narrow, quick check of a specific area after a minor change — did a small fix break the obvious functionality nearby? It is targeted at the affected area and decides whether deeper testing of that area is worthwhile.

The key distinctions: smoke is broad (whole build, core functions), sanity is narrow (a changed area). Smoke tests the overall stability of the build; sanity tests the basic sanity of one region after a change. Smoke runs on every build; sanity runs after small, focused changes. Both are shallow and fast, but they triage different situations — smoke gates the build, sanity gates a specific area.

17. What is exploratory testing?

Exploratory testing is testing done without pre-written test cases — the tester simultaneously learns the software, designs tests, and executes them, using their experience and intuition to explore and probe the application. Testing is guided by the tester’s knowledge of the domain and by what they discover as they go.

Unlike scripted testing, where testers follow a prepared checklist, exploratory testing is a live, creative activity. The tester forms a hypothesis about a risk area, probes it, observes the result, and follows the leads the exploration reveals. It is a disciplined process of simultaneous learning and testing, not random clicking.

Exploratory testing is excellent for finding defects that scripted tests miss — edge cases, unusual sequences, and usability problems no one anticipated. It is especially valuable with new or poorly documented features, time-boxed testing sessions, and complex real-world flows. Its weakness is lack of repeatability — two sessions will not cover the same ground, and the coverage depends on the tester’s skill. Good teams pair scripted regression tests (reliability) with exploratory sessions (discovery).

18. What is ad-hoc testing?

Ad-hoc testing is informal testing done without any preparation — no test cases, no test plan, no documentation — where the tester simply pokes at the software in an unstructured way, following their intuition and whatever they notice. It is the most informal form of testing.

Ad-hoc testing is typically done after the formal test cases are executed, as an informal sweep by testers or developers who want to explore the system freely. Because it has no scripts, it can find defects the structured tests missed — but the coverage is unpredictable and depends entirely on the tester’s experience and mood.

Exploratory testing and ad-hoc testing are related but not identical. Exploratory testing is a deliberate, disciplined technique with a clear learning-and-testing method. Ad-hoc testing is pure informality with no methodology — clicking around to see what happens. Both find unexpected defects, but exploratory testing is a skill; ad-hoc testing is an activity. Structured teams prefer exploratory testing because its results, while not scripted, are guided by intention and can be partly captured.

19. What is positive testing?

Positive testing verifies that the system behaves correctly when given valid, expected inputs — the “happy path.” The tester provides valid data and confirms the software produces the expected, correct results.

For example, with a field that accepts ages 1–120, positive testing submits a value like 30 and confirms it is accepted and processed correctly. Every valid input type, every expected flow, and every normal operation is positive testing. It proves the system does what it is supposed to do.

Positive testing is necessary but insufficient — it proves the happy path works, but tells you nothing about how the system handles mistakes, abuse, or unexpected conditions. That is why positive testing is paired with negative testing. A system that passes every positive test can still crash on a single invalid input, which is exactly what negative testing is designed to catch. The interview answer: positive tests confirm correct behavior with valid input; negative tests confirm graceful behavior with invalid input.

20. What is negative testing?

Negative testing verifies that the system behaves correctly when given invalid, unexpected, or malicious inputs — it tests how the software handles bad data and error conditions. It answers “does the system fail gracefully when things go wrong?”

For the age field accepting 1–120, negative testing submits values like 0, 121, -5, “abc”, and an empty string, and confirms the system rejects them with a sensible error message — not a crash, a hang, or a silent wrong result. Negative testing covers invalid inputs, boundary violations, unexpected formats, unauthorized access, and out-of-range values.

Negative testing matters because real users are unpredictable — they mistype, paste wrong data, use old browsers, and probe the system with unexpected input. A system that handles invalid input gracefully is robust and trustworthy; one that crashes on bad input is fragile and dangerous, especially if the invalid input is malicious. The discipline of negative testing: for every positive test that proves the system accepts valid input, there should be negative tests proving it rejects invalid input cleanly.

21. What is equivalence partitioning?

Equivalence partitioning is a black-box test design technique that divides the possible inputs into classes of equivalent data, where every value in a class is expected to be treated identically by the system. Instead of testing every possible input, the tester picks one representative value from each class.

For example, a field accepting ages 1–120 has three classes: valid ages (1–120), ages below the range (≤0), and ages above it (≥121). Testing one valid value (say 30), one low invalid value (say 0), and one high invalid value (say 130) covers the three classes — assuming the system treats all members of a class the same way.

The power is coverage with economy: it drastically reduces the number of test cases while maintaining coverage, because testing the million invalid values below the range is redundant. Its assumption is the basis of the technique — if the system treats every value in a class equivalently, one representative test per class suffices. Equivalence partitioning is the first step in designing efficient black-box tests and is usually combined with boundary value analysis.

22. What is boundary value analysis?

Boundary value analysis (BVA) is a black-box test design technique that focuses testing on the boundaries of input ranges, based on the observation that defects cluster at boundaries. Bugs are far more likely at the edges of a range than in its middle — off-by-one errors are the classic example.

For the age field accepting 1–120, the boundaries are 1 and 120, and BVA tests just inside, on, and just outside each boundary: 0, 1, 2, 119, 120, 121. The boundary points and their immediate neighbors get the densest testing, because a programmer writing “age > 1” instead of “age >= 1” creates a defect that only boundary testing catches.

BVA is the natural companion to equivalence partitioning: partitioning identifies the classes, and BVA concentrates the test effort on the edges of those classes where defects actually hide. It is among the most effective and cheap test design techniques — a handful of boundary tests catches more real-world defects than a flood of middle-of-range tests. Interviewers expect the answer to lead with “defects cluster at boundaries, especially off-by-one errors.”

23. What is decision-table testing?

Decision-table testing is a black-box technique for testing systems whose behavior depends on combinations of conditions — business rules with many inputs and many resulting actions. The technique builds a table that maps every combination of conditions to the expected action, and each row becomes a test case.

The table has columns for conditions and actions. Each row lists one combination of condition values (true/false, or a specific state) and the action that should result. Constructing the table forces the tester to consider every combination, exposing missing rules and contradictions in the requirements. For example, a loan approval rule with conditions “income above threshold” and “good credit score” produces four rows, each with an approve/reject action.

Decision-table testing is powerful when logic has multiple interacting conditions — discount rules, eligibility checks, tax calculators, error-handling matrices. Its strength is completeness: it guarantees systematic coverage of all condition combinations, which random or boundary testing would miss. Its limitation is combinatorial explosion — with many conditions, the table grows exponentially, so it is used where the conditions are few enough to be tractable and important enough to justify the coverage.

24. What is state-transition testing?

State-transition testing is a black-box technique for systems whose behavior depends on their current state and the events that occur. The system is modeled as a set of states, transitions between them, and the events that trigger each transition, and tests are designed to exercise the transitions.

The model is drawn as a state-transition diagram: circles for states, arrows for transitions labeled with the triggering event. Tests then traverse the diagram — starting in a state, firing an event, checking that the system moves to the expected state and produces the expected output. Testing covers valid transitions, invalid transitions (an event that should not be allowed in a given state), and states themselves.

State-transition testing fits systems with clear stateful behavior: logins (logged out, authenticating, logged in, locked), order processing (pending, paid, shipped, cancelled), vending machines, protocol implementations. Its strength is that it surfaces state-dependent defects that input-output testing misses — the classic bug where a system accepts an operation in the wrong state. Its limitation is that the technique is only as good as the model; the states must be identified correctly and the diagrams can get complex for large systems.

25. What is error guessing?

Error guessing is a black-box test design technique based on the tester’s experience and intuition about where defects typically hide. The tester guesses — from past experience, knowledge of the domain, and common programming mistakes — where the system is most likely to fail, and designs tests to probe those spots.

It is not a formal method like equivalence partitioning; there are no rules or formulas. Instead, the tester brings a mental catalog of classic errors: empty inputs, zero values, division by zero, boundary mistakes, missing fields, null pointers, timeouts, duplicate records, special characters, and unhandled exceptions. The tester throws these at the system and watches for unexpected behavior.

Error guessing is most valuable when combined with formal techniques — it finds the defects the structured methods miss, and it is especially effective in the hands of experienced testers who have seen many systems fail. Because it depends on judgment, teams often capture the accumulated guesses in checklists — “things to try with any input field” — so the technique becomes repeatable. The interview answer: error guessing leverages experience to target likely-failure points that formal techniques do not cover.

26. What is pairwise testing?

Pairwise testing is a combinatorial test design technique that tests all possible pairs of input parameter values, rather than all possible combinations. It is based on the empirical observation that most defects are triggered by the interaction of two parameters, not three or more.

If a feature has four parameters each with four values, exhaustive testing needs 4^4 = 256 combinations. Pairwise testing reduces this dramatically: it generates a test set where every pair of values from any two parameters appears in at least one test. For the same example, pairwise produces roughly 20–30 tests — a massive reduction with only a small loss in defect-finding power.

Pairwise testing works because software bugs are overwhelmingly two-way interactions — the interaction between browser and OS, for instance, far more often than a three-way interaction involving browser, OS, and language. The technique is automated by tools that generate the covering array. Its limitation is the assumption it rests on: if a defect depends on a three-way interaction, pairwise testing can miss it. For most features, the trade-off of coverage for economy is well worth it.

27. What is compatibility testing?

Compatibility testing verifies that the software works correctly across the environments in which it is expected to run — different browsers, operating systems, devices, screen sizes, network conditions, and versions of dependencies. It answers “does it work everywhere we claim it works?”

For web applications, compatibility testing checks browsers (Chrome, Firefox, Safari, Edge) and their versions, operating systems (Windows, macOS, Linux, Android, iOS), and device sizes (mobile, tablet, desktop). For other software, it checks hardware platforms, database versions, and integrations with third-party systems and APIs.

Compatibility defects are frustrating because they are invisible in the development environment — the developer tests on their own browser and OS, and the app breaks on someone else’s. Compatibility testing systematically covers the supported matrix, typically focusing on the most common combinations rather than every possible one. It also feeds configuration management: the test matrix defines which environment combinations must be validated before release, and compatibility issues often drive fixes like progressive enhancement and responsive design.

28. What is usability testing?

Usability testing evaluates how easily and effectively real users can use the software. It measures whether the intended audience can accomplish their tasks — finding features, completing workflows, understanding the interface — with minimal difficulty, errors, and time.

The method is observation: representative users are given realistic tasks and observed while they try to complete them. The tester notes where users struggle, get confused, make errors, or abandon tasks. Metrics include task success rate, time on task, and error rate. Findings are also qualitative — what users say, where they hesitate, what they misunderstand.

Usability testing matters because a system that is functionally correct can still fail if users cannot figure it out — confusing navigation, unclear labels, hidden actions, and poor error messages all drive users away. It is usually done iteratively: test early with a few users, fix the worst problems, and test again. Importantly, usability testing is distinct from functional testing — functional testing asks “does the feature work?” usability testing asks “can a real person use it effectively and without frustration?“

29. What is performance testing?

Performance testing verifies that the system meets its performance requirements — responsiveness, speed, and resource usage under expected conditions. It measures things like response time, throughput, and resource utilization, and asks “is the system fast enough?”

Performance testing covers several dimensions. Load testing measures behavior under expected load. Stress testing pushes beyond normal capacity to find the breaking point. Volume testing floods the system with data. Soak or endurance testing runs the system for extended periods to find degradation over time. Spike testing throws sudden bursts of load at the system. Each targets a different failure mode.

Performance testing matters because performance is a user-facing quality — slow applications lose users and revenue — and because performance problems often appear only at production scale, invisible in development with a handful of users. It uses tools to simulate many concurrent users and measure the metrics. The interview distinction to nail: performance testing is the umbrella; load, stress, and the others are specific types under it.

30. What is security testing?

Security testing verifies that the system protects its data and resists attacks from malicious users. It checks confidentiality (data is not exposed), integrity (data is not altered), and availability (the system cannot be taken down), plus authentication and authorization.

The techniques span the attack surface. Vulnerability scanning runs automated tools that look for known weaknesses. Penetration testing simulates real attacks — SQL injection, cross-site scripting (XSS), cross-site request forgery, authentication bypass — to exploit the system like an attacker would. Security auditing reviews code and configurations for insecure practices, like hardcoded credentials or missing input validation. Risk assessment identifies and prioritizes the threats the system faces.

Security testing is fundamentally different from functional testing: it requires thinking like an adversary, testing for things that should not happen (data leakage, unauthorized access, crashes on malicious input) rather than confirming expected behavior. Security defects are also among the most damaging — a single vulnerability can expose customer data or take the whole service down. Security testing is most effective when it starts early, with secure design and code review, not just scanning at the end.

31. What is load testing?

Load testing is a type of performance testing that verifies how the system behaves under the expected amount of concurrent load — the normal and peak numbers of users or transactions it is designed to handle. It answers “can the system handle the load it is supposed to handle?”

The tester simulates a realistic number of concurrent users or requests and measures response time, throughput, and resource usage. The goal is to confirm the system meets its performance targets under expected conditions — response times stay within limits, no errors appear, resources are not exhausted.

Load testing serves two purposes: validation and capacity planning. It validates that the system meets its service-level targets under expected load. And it establishes the system’s capacity — the maximum load it can sustain while still performing acceptably — which feeds decisions about scaling, hardware, and infrastructure budget. The distinction interviewers probe: load testing checks expected load; stress testing pushes beyond it to find the breaking point. Load tests use tools that generate realistic, concurrent traffic against the system.

32. What is stress testing?

Stress testing is a type of performance testing that pushes the system beyond its expected capacity to find its breaking point and observe how it fails. It answers “what happens when we push the system too hard?”

The tester throws increasing load at the system — far beyond normal and peak usage — until it degrades or fails. The goal is to find the system’s limits: the maximum load it can sustain, how it degrades (graceful slowdown versus sudden collapse), and how it recovers when the load drops back to normal. It also verifies that the system fails safely — rejecting requests or queueing them rather than corrupting data.

Stress testing matters because real disasters are unexpected: a viral product, a flash sale, a traffic spike can overwhelm a system sized for normal load. Knowing the breaking point in advance lets the team design for it — rate limiting, auto-scaling, graceful degradation, failover. The distinction from load testing: load testing checks the system works under expected load; stress testing finds what happens beyond it. A system that never fails over until it crashes at 2x capacity is a system that will take a site down during an unexpected spike.

33. What is scalability testing?

Scalability testing verifies that the system can grow to handle increased load — more users, more data, more transactions — by adding capacity. It answers “can this system scale, and how much capacity does it need to handle growth?”

Scalability testing increases the load or the system’s capacity and measures whether performance scales proportionally. Two patterns are examined. Vertical scaling (scale-up) adds power to existing resources — more CPU, memory — and the test verifies the system uses it. Horizontal scaling (scale-out) adds more machines — more instances behind a load balancer — and the test verifies the system distributes work across them. The key question is whether the system actually benefits from added capacity or whether some bottleneck (a database lock, a single server, a shared cache) caps the gains.

Scalability testing matters because growth is the normal fate of successful software — users increase, data accumulates, and a system that cannot scale becomes a capacity crisis. The tests find the bottlenecks — often a single point like the database or a synchronous dependency — and the results guide architecture: which parts need to be stateless, partitioned, cached, or made asynchronous. Scalability is not just “handle more load” but “handle more load by adding more capacity, predictably.”

34. What is recovery testing?

Recovery testing verifies that the system can recover from a failure — a crash, a network outage, a power loss, a failed process — and continue operating correctly. It answers “if things break, can we come back?” and is a form of reliability testing.

The tester deliberately induces failures and checks the recovery: kill the application process and verify it restarts cleanly. Disconnect a database and verify the system handles it and recovers when reconnected. Simulate a crash and verify data integrity is preserved — no corruption, no lost transactions, no half-written records. Recovery testing covers restart behavior, failover to a standby system, transaction rollback, and data restoration from backups.

Recovery testing matters because failures are inevitable, and the measure of a system is not whether it fails but how it fails and how it comes back. A system that crashes but restores cleanly is far more trustworthy than one that crashes and corrupts data. Recovery testing validates the mechanisms that make downtime survivable: redundant systems fail over, databases recover to a consistent state, and backup and restore procedures actually work. The worst discovery — a backup that cannot be restored — is exactly what recovery testing is designed to catch.