Manual Testing

Unstructured testing without a plan or documented test cases — relies on the tester's experience and intuition. Useful for quick smoke checks and early defect discovery, but not reproducible.

Internal testing by employees or invited users in a controlled environment, usually after dev/QA testing but before broader external release.

Testing by external real users in their own environments, often with a pre-release version. Used to validate UX and surface issues that don't appear in lab conditions.

Testing values immediately at and around boundaries (e.g., min, max, just-below, just-above). Bugs cluster at edges — this technique catches off-by-one errors that equivalence partitioning alone misses.

The stages a defect passes through from discovery to closure: New → Assigned → In Progress → Fixed → Verified → Closed (with possible Reopened, Deferred, or Rejected branches).

A systematic approach to test design that selects a subset of all possible input combinations using mathematical techniques such as pairwise (all-pairs) or t-way coverage. Exhaustive combinatorial testing grows exponentially with the number of parameters, so combinatorial methods aim for maximum fault detection with the minimum test count. Pairwise coverage — ensuring every pair of parameter values appears in at least one test case — typically catches 70–90% of configuration-related defects at a fraction of the full combinatorial cost.

A truth-table-style testing technique that maps every combination of input conditions to expected outputs. Best for rule-based logic with multiple inputs — exposes missing rules and conflicts at design time.

A flaw in a software system that causes it to behave in an unintended or incorrect way — also called a bug or fault. A defect arises when actual behaviour diverges from expected behaviour defined by requirements or specification. In QA workflow, a defect is formally logged with reproduction steps, severity, and priority, then tracked through the bug lifecycle from discovery to verified closure. The distinction that matters in practice: an error is the human mistake, a fault is the resulting code flaw, and a failure is the observable incorrect behaviour at runtime.

A test scenario that exercises a system at or near the extreme boundary of its valid input range, or at the intersection of multiple boundary conditions simultaneously. Edge cases are distinct from boundary values — a boundary value tests one limit in isolation (minimum, maximum, zero), while an edge case may involve combinations of unusual inputs, rare states, or unexpected sequences that only arise at the periphery of normal operation. Examples include an empty string passed to a text field, a file exactly at the permitted size limit, a date of 29 February in a non-leap year, or a shopping cart containing 10,000 items. Edge cases are disproportionately likely to expose defects because developers tend to build and test around the expected path and leave the periphery under-exercised. A disciplined tester explicitly enumerates edge cases for every feature by asking: what is the smallest possible value? The largest? What happens at exactly zero? What if all optional fields are omitted? What if they are all present simultaneously?

Dividing the input space into groups where the system should behave identically, then testing one representative value per group. Reduces redundant test cases dramatically without losing coverage.

Designing tests based on the tester's intuition about where defects are likely to occur. Powered by experience and knowledge of common failure modes — null inputs, off-by-one errors, race conditions.

Simultaneous learning, test design, and execution — the tester explores the app, forms hypotheses, and probes them, with no pre-scripted steps. Most effective when time-boxed and chartered.

A feature that lets users download application data as a file — CSV, Excel, PDF, JSON, or similar. QA concerns: does the exported file contain all expected records (especially across pagination boundaries), are values correctly encoded (special characters, quotes, commas in CSV), does the file open without errors in target applications, and is the MIME type set correctly so browsers prompt the right save/open behaviour. Also test large exports for timeout and memory behaviour, and verify that export respects the user's current filter and permission scope.

A testing discipline verifying that an application handles file uploads correctly across all dimensions: accepted types, size limits, malformed content, and security boundaries. A complete test strategy covers the happy path, boundary values (file exactly at and one byte over the size limit), type validation (correct extension with mismatched Content-Type MIME type; double extensions such as .php.jpg), empty files, zero-byte files, filenames with special characters, concurrent uploads, and interrupted uploads. Security-relevant tests include attempting to upload executable files to endpoints that serve user content, verifying that upload endpoints reject unauthenticated requests, and confirming stored files are served with Content-Disposition: attachment to prevent in-browser execution. Always test server-side validation independently from any client-side validation — client-side checks are easily bypassed.

Testing what a system does with invalid, unexpected, or out-of-bounds input — verifying it fails gracefully rather than behaving incorrectly. Complements positive (happy-path) testing. Examples: submitting a form with an empty required field, sending a string where an integer is expected, exceeding maximum field length, passing an expired token. A system passes negative testing when it returns a clear, appropriate error and does not crash, corrupt data, or leak internal state.

A logic error where a loop, index, or boundary check is off by exactly one — iterating one too many or too few times, or including/excluding a value at the edge of a range. Common causes include using < instead of <=, starting a loop at index 1 instead of 0, or miscalculating array bounds. Boundary value analysis targets off-by-one errors directly by testing the values immediately at and on either side of every boundary.

A combinatorial testing technique that constructs a minimal test suite in which every pair of distinct input parameters appears together in at least one test case — also called all-pairs testing. Research shows most software faults are triggered by interactions between at most two parameters, so pairwise coverage typically detects the same defects as exhaustive testing while reducing the test count from a multiplicative to roughly the square root of the full combination space.

A numbered sequence of actions a developer can follow to reliably trigger a defect from a known starting state. High-quality reproduction steps include: the environment and version, preconditions and test data, each action in order, and the actual vs expected result. Reproducibility is the single biggest factor in defect resolution speed — a bug that cannot be reproduced is rarely fixed. For intermittent defects, include the reproduction rate and any environmental conditions that affect it.

A rating of how badly a defect affects the system or users, independent of when it should be fixed. Common levels: critical (system unusable or data loss), major (core feature broken with no workaround), minor (non-critical degradation), trivial (cosmetic only). Severity measures impact; priority measures urgency — a cosmetic bug on the login page might be low severity but high priority for a public launch.

Severity describes how broken the system is (set by QA, technical impact). Priority describes how urgently it should be fixed (set by Product, business impact). The two are independent — a typo can be Trivial / P0.

A testing technique that models a system as states and the transitions between them, ensuring every legal transition is exercised and illegal ones are blocked.

A single, executable specification: preconditions, steps, expected result, and pass/fail criteria for one verification.

A higher-level description of what to test — the situation or feature — without the step-by-step details. One scenario typically generates multiple test cases.

The set of logic that converts timestamps between UTC (the storage standard) and local display times, accounting for UTC offsets and Daylight Saving Time transitions. Common bugs: dates shifting by one day at midnight when local offset is applied, DST gaps causing a time to not exist (2:30 AM on spring-forward night), DST ambiguity causing a time to appear twice (1:30 AM on fall-back night), and inconsistent display between server-rendered and client-rendered timestamps. Test strategy: cover at least one timestamp near a DST boundary, one at midnight UTC, and one for a user whose local offset crosses the date line.

Verification by end users or business stakeholders that the system meets their real-world needs. The final validation gate before release.

Testing based on user-perspective scenarios — start-to-finish flows like 'place an order' or 'reset password' — rather than isolated functions.

Checking that input or output conforms to expected rules — format, range, type, length, and business constraints. Client-side validation improves UX but must never be the only defence; server-side validation is the authority. Testing validation coverage includes: boundary values, type coercion, empty and null inputs, maximum lengths, and injection-dangerous characters. Distinct from verification (did we build it correctly?), though the two terms are frequently conflated.