QAI CAST key terms

The process of evaluating a software product by executing it or reviewing its artifacts to find defects and to provide information about its quality and fitness for use.

Checking that a work product was built according to its specified requirements and design, answering the question of whether the product was built right, usually without executing the code.

Checking that the finished product meets the user's real needs and intended purpose, answering whether the right product was built, typically by exercising the software in realistic conditions.

A flaw or imperfection in a work product, such as a requirement, design, or code, that may cause the software to behave incorrectly or fail to meet its intended purpose.

The observable incorrect behavior of a running system, produced when a defect is reached under particular conditions and the software deviates from its expected result or specification.

A human action that produces an incorrect result, such as a mistake in reasoning, typing, or interpretation that introduces a defect into a work product.

Examination of work products such as requirements, designs, and code without running them, using reviews, walkthroughs, and inspections to find defects early and cheaply.

Testing that involves executing the software with selected inputs and observing the results, in contrast to reviewing artifacts without execution.

A stage of testing grouped by the object under test and the point in the lifecycle, such as unit, integration, system, and acceptance testing, each with distinct goals and entry criteria.

Re-running previously passed tests after changes to confirm that modified code has not broken existing functionality and that no new defects were introduced.

A document describing the scope, objectives, approach, resources, schedule, risks, and exit criteria for a testing effort, serving as the reference for planning and control.

The high-level description of how testing will be organized and conducted across a project or organization, including levels, types, techniques, environments, and automation direction.

The conditions that must be met before a test activity can begin, such as approved requirements, a stable build, and a prepared environment, used as a precondition for starting work.

The agreed conditions for declaring a test activity complete, such as coverage thresholds, defect counts, and pass rates, used to decide when to stop testing.

A set of preconditions, inputs, actions, and expected results designed to verify a specific behavior or condition, so that a result can be judged pass or fail.

A sequence of steps for executing one or more test cases in a defined order, including any setup and teardown actions needed to run them reliably.

Any source used to decide whether an observed test result is correct, such as a specification, a reference implementation, or a domain expert's judgment.

A black-box technique that divides input data into classes expected to behave the same way, then selects one representative value from each class to reduce redundant test cases.

A black-box technique that tests values at the edges of input ranges, such as minimums, maximums, and just outside them, where defects most often cluster.

A black-box technique that models combinations of conditions and their resulting actions in a table, ensuring that each relevant rule combination is exercised by at least one test.

A technique that models the system as states, events, and transitions, then derives tests to cover valid transitions, invalid transitions, and sequences of events.

A white-box coverage measure that reports the percentage of executable statements exercised by a test suite, helping reveal code that no test ever reaches.

A white-box coverage measure reporting the percentage of decision outcomes, such as true and false branches, taken by tests, which is generally stronger than statement coverage.

The activity of running test cases against a build, recording actual results, comparing them with expected results, and logging outcomes and evidence for each run.

A single execution cycle of a set of test cases against a particular build and environment, whose results are recorded together for tracking and reporting.

The behavior or output observed when a test case is executed, which is compared with the expected result to determine whether the test passes or fails.

A recorded description of a defect containing steps to reproduce, expected and actual results, environment details, severity, and priority, used to track the issue to resolution.

The measure of how much impact a defect has on the system's functionality or business operation, ranging from cosmetic issues to complete loss of critical capability.

The measure of how urgently a defect should be fixed relative to other work, driven by business and scheduling considerations and set independently of technical severity.

A review meeting in which team members assess new defects, confirm reproducibility, assign severity and priority, and decide whether to fix, defer, or reject each one.

The defined states a defect passes through, such as new, assigned, open, fixed, retest, verified, and closed, along with the allowed transitions between them.

Re-executing the specific test that exposed a defect after a fix, to confirm that the reported problem is genuinely resolved in the new build.

A quantitative measure derived from test activities or results, such as defect density or pass rate, used to monitor progress, quality, and risk and to support decisions.

The number of confirmed defects divided by a size measure of the product, such as lines of code or function points, used to compare quality across modules or releases.

The proportion of defects found after a testing phase or after release compared with all defects found, indicating how effective earlier testing was at catching problems.

A document produced at the end of a test level or project that summarizes results, coverage, defect status, deviations from plan, and a recommendation on release readiness.

The use of tools and scripts to execute tests, compare actual and expected results, and report outcomes with minimal manual intervention, suited to repeatable, high-volume checks.

A set of instructions, often code, that automates the execution of a test case, including setup, input, assertions, and reporting of results.

The collection of tools, drivers, stubs, and scripts that supports automated test execution by supplying inputs, controlling the environment, and capturing results.