Ruankao Software Evaluator (Intermediate) key terms

A structured framework describing the stages a software product passes through, from requirements through retirement, and how work flows between them. Testing scope and timing depend on which model an organization adopts.

A life cycle model that pairs each development phase with a corresponding test level, so requirements link to acceptance testing and design links to integration and system testing. It emphasizes early test planning.

Verification asks whether the product was built according to its specification; validation asks whether it meets the user's real needs. Both are needed because a product can conform to a flawed specification.

Modularity is the division of a system into separately understandable units. Cohesion measures how strongly the responsibilities inside one unit belong together; high cohesion makes units easier to test in isolation.

The degree of dependency between software modules. Loose coupling reduces the ripple effect of change and simplifies stubbing, while tight coupling forces testers to assemble many components before anything can be exercised.

A directed graph whose nodes are program statements or blocks and whose edges are possible transfers of control. Testers use it to compute cyclomatic complexity and to identify paths for structural coverage.

A count of linearly independent paths through a program, computed as edges minus nodes plus two on a control flow graph. It indicates the minimum number of tests for branch coverage and flags risky modules.

Test design based only on externally visible behavior and specifications, without knowledge of internal code. It is suited to functional requirements and works at every test level, including acceptance.

Test design that uses knowledge of internal structure, such as code, control flow, or data flow. It measures structural coverage and reveals unreachable or untested logic that black-box tests may miss.

A technique that divides input and output domains into classes expected to be handled identically, then selects one representative value per class. It reduces the number of tests while keeping defect-finding power.

A technique that selects values at and just outside the edges of each equivalence class, because off-by-one and limit errors cluster there. It complements partitioning and is often combined with it.

A technique that tabulates combinations of conditions and the actions required for each combination, exposing rules that might otherwise be missed. It suits business logic with interacting conditions and outcomes.

A technique that models a system as states, events, and transitions, then derives tests to cover valid transitions, invalid transitions, and unreachable states. It is common for transaction and protocol behavior.

The percentage of executable statements exercised by a test suite. It is the weakest structural criterion because a statement can run without its guarding condition ever being false.

The percentage of decision outcomes, true and false, exercised by tests. Also called branch coverage, it is stronger than statement coverage and is a common minimum entry criterion for unit testing.

A white-box method that derives a set of linearly independent paths from the control flow graph and designs one test per path. The number of paths equals the cyclomatic complexity.

A documented set of preconditions, inputs, execution steps, and expected results aimed at a specific objective. A good test case is traceable, repeatable, and states expected results precisely enough to judge pass or fail.

The mechanism used to decide whether an observed result is correct, such as a specification, a reference implementation, or a human expert. Without a reliable oracle, a test cannot produce a verdict.

A group of test activities organized around a stage of development, such as component, integration, system, and acceptance testing. Each level has distinct objectives, entry criteria, and typical defects.

Testing individual components or functions in isolation, usually by developers with stubs and drivers. It targets logic errors and is the cheapest level at which to find and fix defects.

Testing that verifies interfaces and interactions between integrated components. Strategies include big-bang, top-down, bottom-up, and sandwich, each trading off stub and driver effort against defect localization.

Testing a complete, integrated system against its requirements, including functional and non-functional behavior. It is usually performed by an independent test team in an environment close to production.

Testing conducted to decide whether a system satisfies business needs and can be released or accepted. Forms include user acceptance, operational acceptance, contractual, and regulatory acceptance testing.

Re-execution of selected tests after a change to confirm that existing behavior still works and no new defects were introduced. It is the main justification for automated test suites and continuous integration.

Retesting the specific defect that was reportedly fixed, using the original failing case, to confirm the fix works. It differs from regression testing, which checks for side effects elsewhere.

A replacement for a called component that returns controlled values so the component under test can run. Stubs simulate the lower layers that a module depends on during integration testing.

A program or script that invokes the component under test and supplies its inputs, standing in for the upper layers that would normally call it. Drivers are typical in bottom-up integration.

The collection of tools, scripts, stubs, drivers, and data needed to execute tests and capture results. It provides the scaffolding that makes automated and repeatable execution possible.

A document describing scope, objectives, approach, resources, schedule, risks, and exit criteria for testing. It is the reference for controlling and communicating test work throughout the project.

Conditions that must be met before a test level starts and before it can be declared complete, such as approved requirements or a target pass rate. They make go/no-go decisions objective rather than intuitive.

The sequence of states a defect passes through, typically new, assigned, open, fixed, retested, verified, and closed, with rejection or deferral as alternatives. It defines who acts at each stage.

The number of confirmed defects per unit size, such as per thousand lines of code or per function point. It supports release decisions and comparison across modules, provided measures are consistent.

Using software to execute tests, compare actual with expected results, and report outcomes without manual intervention. It pays off for stable, repetitive suites such as regression rather than one-off exploratory work.

Testing to determine responsiveness, throughput, and resource use under defined workloads. It includes load and stress variants and requires realistic data volumes and production-like environments to yield meaningful results.

Testing that applies expected or peak workload levels to verify the system meets performance requirements without unacceptable degradation. It answers whether the system handles anticipated demand.

Testing beyond normal capacity to find the breaking point and observe how the system fails and recovers. It reveals bottlenecks, memory leaks, and poor degradation behavior rather than everyday throughput.

Testing how a system behaves under invalid inputs, resource shortages, or hostile conditions, focusing on graceful failure rather than correctness on valid input. It is closely related to reliability and security testing.

The probability that software performs required functions without failure for a stated period under stated conditions. It is measured statistically, for example by mean time between failures.

The degree to which a product satisfies stated and implied needs. Standards such as ISO/IEC 25010 organize it into characteristics including functionality, reliability, performance efficiency, usability, security, and maintainability.

A recognized specification of quality characteristics, processes, or documentation requirements, such as ISO/IEC 25010 for product quality or ISO/IEC 29119 for testing processes. It gives auditors and teams a common reference.