VS key terms

Confirmation, through objective evidence, that specified requirements have been fulfilled. It answers whether the product was built correctly according to its design specifications and documented requirements.

Confirmation, through objective evidence, that the requirements for a specific intended use or application have been fulfilled. It answers whether the right product was built to meet user needs.

A statement that identifies a capability, characteristic, or quality factor that a system must possess to be useful and acceptable to its stakeholders. Requirements should be testable and unambiguous.

The ability to link requirements to design elements, code, tests, and results in both directions. Bidirectional traceability supports impact analysis, coverage assessment, and evidence that each requirement has been verified.

A document describing the scope, approach, resources, schedule, and activities for intended test efforts. It identifies items to be tested, features to be tested, responsibilities, risks, and exit criteria.

Preconditions that must be satisfied before a test activity begins, such as approved test cases, available environments, trained personnel, and stable software. They help prevent wasted effort and unreliable results.

Conditions agreed in advance that indicate a test activity can conclude, such as coverage targets, defect thresholds, and completion of planned tests. They support objective decisions about readiness.

A strategy that prioritizes test effort according to the likelihood and impact of potential failures. Higher-risk areas receive more thorough testing, while lower-risk areas may receive lighter coverage.

Conditions that a product or deliverable must satisfy to be accepted by a user, customer, or stakeholder. They are often expressed as scenarios and are used to decide whether work is complete.

An approved, recorded configuration of one or more configuration items that serves as a reference for further development. Changes to a baseline require formal control and impact assessment.

An entity treated as a unit for configuration management, such as a document, source file, test script, or hardware component. Its identity, version, and changes are controlled.

A set of preconditions, inputs, actions, expected results, and postconditions developed to verify a particular requirement or behavior. A good test case is repeatable and has a clear oracle.

A mechanism or source of truth used to determine whether a test's actual result is correct. Oracles may be specifications, reference implementations, models, or human judgment.

A controlled state or set of data and environment components established before a test runs and restored afterward. Fixtures make tests repeatable and isolate them from shared state.

A simplified replacement for a called component that returns predetermined responses during testing. Stubs let testers isolate the unit under test from dependencies that are unavailable or costly.

A test harness component that invokes the unit under test, supplies inputs, and captures outputs. Drivers are especially useful when testing lower-level components that lack a user interface.

A black-box technique that divides input data into classes expected to produce the same behavior. Testing one representative value from each class reduces the number of test cases while maintaining coverage.

A black-box technique focused on values at the edges of input ranges, such as minimum, maximum, just inside, and just outside. Defects often cluster at boundaries.

A measure of how much of a specified structure has been exercised by tests, such as statements, branches, requirements, or interfaces. Coverage indicates completeness but does not by itself prove correctness.

Examination of code or artifacts without executing them, often using tools to detect violations of rules, coding standards, or potential defects. It can find issues early and is complementary to dynamic testing.

Testing that involves executing the software or system with selected inputs and observing results. It can reveal runtime behavior, performance, and integration problems that static methods may miss.

Testing performed after changes to confirm that previously working functionality still works and that new defects have not been introduced. It typically reuses a selected suite of existing tests.

A shallow, broad test suite run to confirm that the most critical functions work and that a build is stable enough for deeper testing. It is often automated and quick.

A narrow, focused check that a specific change or fix behaves as expected and has not broken nearby functionality. It is less comprehensive than a smoke test.

A systematic examination of an artifact by one or more people to find defects, ambiguities, or improvements. Reviews can be informal or formal and apply to requirements, designs, code, and test materials.

A formal, rigorous review process with defined roles, entry and exit criteria, and recorded findings. Inspections are effective for finding defects in documents and code early.

An informal review in which an author leads reviewers through an artifact to gather feedback and increase shared understanding. It is less structured than an inspection and may not record defects formally.

A flaw or imperfection in a work product that may cause it to fail to meet requirements or expectations. Defects can exist in requirements, design, code, tests, or documentation.

An unplanned event or observed anomaly that requires investigation. In testing, an incident may indicate a defect, an environment problem, or a misunderstanding of expected behavior.

Verification and validation performed by an organization independent of the development team. Independence reduces bias and provides objective evidence that requirements and quality standards are met.

The process of demonstrating that equipment, systems, or personnel meet specified requirements and are suitable for their intended use. It often produces documented evidence for regulated environments.

The process of bringing a system or facility into operational service and confirming that it performs according to design intent. It follows installation and precedes routine operation.

Documented evidence that equipment or systems are installed correctly and consistently with manufacturer recommendations and approved design specifications. It is often the first qualification stage.

Documented evidence that equipment or systems operate as intended throughout anticipated operating ranges. It tests functional performance under controlled conditions.

Documented evidence that equipment or systems consistently perform effectively under actual production conditions and intended use. It often follows installation and operational qualification.