Testing Fundamentals & Core Concepts

A bug is an informal term for a defect — a flaw in code that causes incorrect or unexpected behavior. Most teams use "bug" and "defect" interchangeably in conversation, reserving "defect" for the formal record logged in a tracker. Either way, it's the same underlying problem: code doing something other than what it should.

A defect (or bug) is a flaw in software that causes it to produce an incorrect or unexpected result, or to behave in a way that violates its requirements. Defects are found during testing or in production, logged with steps to reproduce, and tracked through a lifecycle from Open to Fixed to Verified to Closed.

Entry criteria are the conditions that must be met before a testing phase can begin — a stable build, a deployed test environment, completed dependent features, or available test data. They exist to stop testing from starting on something not actually ready to be tested, which wastes tester time and produces misleading results.

An error is a mistake a person makes — a developer misreading a requirement, mistyping a variable, or misunderstanding an edge case — that gets introduced into the code. An error becomes a fault once it's sitting in the codebase, and a failure once that fault actually produces wrong behavior a user or tester can observe.

Exit criteria are the conditions that must be satisfied before a testing phase can be considered complete — a target pass rate, zero open critical defects, required test coverage reached, or all planned test cases executed. They give a team an objective answer to "are we done testing?" instead of a gut-feel guess.

A failure is the visible, observable moment software does the wrong thing — a page that doesn't load, a calculation that returns the wrong number, a crash. It's the end result of the error → fault → failure chain: a human error introduced a fault into the code, and a failure is that fault actually manifesting under real conditions.

A fault is the actual flaw sitting in the code — the incorrect line, the missing null check, the off-by-one condition — introduced by a developer's error. A fault can exist for a long time without causing any visible problem; it only becomes a failure once execution actually hits that flawed code under the right conditions.

Priority is how urgently a defect needs to be fixed, based on business impact and timing — distinct from severity, which measures how bad the defect's technical impact is. A cosmetic typo on the homepage right before a big launch can be high priority and low severity; a rare crash in a rarely-used admin tool can be the opposite.

Quality Assurance (QA) is the set of proactive activities aimed at preventing defects before they happen — process design, standards, code review practices, and test planning — as opposed to Quality Control, which is the reactive work of finding defects that already exist. In practice, "QA" is also used loosely as an umbrella term covering both.

Quality Control (QC) is the reactive, product-focused work of finding defects in something that's already been built — running test cases, executing test scripts, and inspecting output against requirements. It's distinct from Quality Assurance, which is the proactive, process-focused work of preventing defects in the first place.

A Requirements Traceability Matrix (RTM) is a document that maps each requirement to the test cases that verify it, making it possible to confirm every requirement has been tested and every test case exists for a reason. It's the tool teams use to answer "have we tested everything we're supposed to?" with evidence instead of a guess.

Root cause analysis is the process of tracing a defect back past its symptom to the actual underlying reason it happened — a missing requirement, a process gap, a misunderstanding — so the fix addresses the cause, not just the visible failure. Done well, it prevents whole categories of future defects, not just the one that got reported.

Severity is how bad a defect's technical impact is — whether it crashes the whole application, blocks a core workflow, or is a minor cosmetic issue — independent of how urgently it needs fixing. A Severity 1 (critical) bug that only affects an unused feature might still sit behind a Severity 3 bug in the checkout flow when it comes to priority.

Software quality is how well a product meets both its explicit requirements and the implicit expectations users bring to it — correctness, reliability, performance, usability, and security among them. It's not a single measurable number; it's a combination of dimensions that trade off against each other depending on what the product actually needs to be good at.

Software testing is the practice of executing a system with the intent of finding defects and verifying it behaves as expected — covering everything from a single unit test to a full manual exploratory session. It exists to answer one practical question before users find out the hard way: does this software actually do what it's supposed to do?

A test bed is the complete hardware and software configuration a test runs against — the specific combination of OS, browser version, device, database state, and network conditions. Two tests running the identical test case can produce different results if their test beds differ, which is why test beds are documented explicitly, not assumed.

A test case is a documented set of preconditions, steps, test data, and an expected result used to verify one specific piece of application behavior. It's the smallest unit of testing you actually execute and mark pass or fail — the building block that test suites, test plans, and traceability matrices are all made of.

Test coverage measures how much of an application has actually been exercised by tests — as a percentage of code lines, branches, requirements, or user flows, depending on what's being measured. High coverage reduces the odds of untested code shipping with a hidden defect, but it's a proxy for risk reduction, not a guarantee of quality on its own.

Test data is the input values, records, and datasets used to execute a test case — anything from a single valid email address to a full production-like database snapshot. Good test data covers the range a test technique calls for: valid inputs, invalid inputs, edge cases, and boundary values, not just the happy path.

A test environment is the infrastructure a test runs against — servers, databases, third-party service configurations, and deployed application code — kept separate from production so testing doesn't affect real users or real data. Most teams run several: development, QA/staging, and sometimes a dedicated performance or UAT environment, each serving a different stage of the release process.

A test oracle is the mechanism used to decide whether a test passed or failed — a known correct output, a specification, a prior working version, or in some cases human judgment. Without a reliable oracle, a test can execute successfully but tell you nothing, because there's no trustworthy answer for what the "right" result should have been.

A test plan is the document that defines the scope, approach, resources, and schedule for a testing effort — what will be tested, how, by whom, with what environment and data, and what the entry and exit criteria are. It's the single reference that aligns the team on what "done testing" actually means before work starts.

A test scenario is a high-level description of something to be tested — "verify a user can reset their password" — that later gets broken down into one or more detailed test cases covering the specific steps, data, and expected results. Scenarios describe what to test; test cases describe exactly how.

A test script is the concrete set of steps — manual instructions or executable automation code — that carries out a test case. In manual testing it's a written procedure a tester follows by hand; in automated testing it's the actual code that performs the same steps programmatically.

A test strategy is the high-level approach to testing across a whole project or organization — which test levels and types matter most, how much gets automated vs. tested manually, what tools and environments are standard, and how risk gets prioritized. It sits above individual test plans, which apply that strategy to a specific release or feature.

A test suite is a collection of test cases grouped together, usually because they share a purpose — a regression suite, a smoke suite, an API test suite for one service. Suites are the unit teams actually run and report on, rather than executing hundreds of individual test cases one at a time.

Validation asks whether a product does the right thing — does it actually meet the user's real needs, independent of what the written spec says. It's typically checked late in development, through user acceptance testing or beta programs, and is distinct from verification, which checks whether the product was built correctly against its stated requirements.

Verification asks whether a product was built correctly according to its specified requirements — reviewing designs, checking code against a spec, and running tests that confirm stated behavior. It's distinct from validation, which asks whether those requirements actually solve the user's real problem in the first place.