CSQE key terms

Planned, systematic activities that build confidence a product conforms to requirements and standards. It is process-focused, preventive, and organization-wide, distinct from testing a finished product.

Activities that detect defects in work products by examining or testing them against a standard or requirement. It is product-focused and detective rather than preventive.

The documented set of policies, processes, procedures, and records an organization uses to direct and control quality. It provides the framework within which quality assurance activities are planned, executed, and audited.

Verification confirms that work products were built correctly against specifications; validation confirms the product meets intended use and user needs. Verification asks whether we built the product right; validation asks whether we built the right product.

The total cost of preventing defects, appraising products for defects, and dealing with failures. Prevention and appraisal are conformance costs; internal and external failures are nonconformance costs.

The portion of quality cost consumed by failures and their consequences, including rework, scrap, warranty, support, and lost goodwill. Reducing it is the usual economic justification for prevention activities.

A set of interrelated activities that transforms inputs into outputs using resources under defined controls. Software quality engineering treats processes as measurable and improvable objects, not just background activity.

A quantitative measure of how well a stable process can meet specification limits, often expressed as indices such as Cp and Cpk. It reflects the inherent spread and centering of process output relative to tolerances.

An independent, systematic examination of a process against defined criteria such as standards, procedures, or a maturity model. It produces findings, evidence, and corrective actions rather than product test results.

Action taken to eliminate the cause of a detected nonconformity so it does not recur. It follows root cause analysis and is distinct from containment or rework, which only address the symptom.

Action taken to eliminate the cause of a potential nonconformity before it occurs. It is triggered by trend data, risk analysis, or lessons learned rather than by an actual failure.

A structured investigation to find the underlying reason a defect or failure occurred, rather than the immediate symptom. Common techniques include the five whys, fishbone diagrams, and fault tree analysis.

Activities that stop defects from being introduced, such as training, standards, peer review, checklists, and causal analysis. It is the cheapest quality strategy because defects are never created or reworked.

A formal, documented examination of a work product against predefined criteria by a trained team. It is typically more rigorous and structured than a walkthrough or informal review.

A review of a work product by colleagues with relevant technical expertise, conducted to find defects and improve quality. It includes formal inspections, walkthroughs, pair programming, and desk checks.

An informal review in which the author leads reviewers through a work product to gather feedback and build shared understanding. It is less structured than an inspection and usually not statistically controlled.

A table that links requirements to design elements, code, test cases, and results in both directions. It supports coverage analysis, impact analysis, and evidence that every requirement was verified.

A structured examination of requirements for completeness, consistency, testability, and correctness before design begins. Detecting requirement defects early avoids expensive downstream rework.

The conditions a product or feature must satisfy to be accepted by a user, customer, or stakeholder. They make requirements testable and are the basis for acceptance testing.

The degree to which tests exercise specified items such as requirements, code statements, branches, or paths. It is usually expressed as a percentage and guides test completeness assessment.

A measure of how much source code is executed by a test suite, reported at statement, branch, decision, or path level. High coverage alone does not prove correctness; it shows untested areas.

A documented set of inputs, preconditions, execution steps, and expected results used to verify a specific behavior or requirement. Good test cases are repeatable, traceable, and independently verifiable.

Retesting a system after changes to confirm that existing functionality still works and that no new defects were introduced. It is often supported by automated test suites and impact analysis.

A test that exercises a single component, function, or module in isolation from the rest of the system. Unit tests are usually written by developers, run frequently, and automated.

The number of defects found per unit of product size, such as defects per thousand lines of code or per function point. It enables comparison across modules, releases, and organizations.

The percentage of defects present at a given stage that are found and removed before delivery. It measures how effective quality activities are at preventing defects from reaching customers.

A technique that ranks causes by frequency or impact to show that a small number of causes produce most problems. It helps teams focus improvement effort where it yields the largest return.

The use of statistical methods, especially control charts, to monitor a process and distinguish normal variation from special-cause variation. It supports decisions about when to adjust a process.

A time-ordered plot of process measurements with a center line and statistically derived control limits. Points outside the limits or nonrandom patterns signal special-cause variation.

Quantifying software product size, for example by lines of code or function points, to support estimation, productivity analysis, and normalized quality metrics such as defect density.

Predicting effort, cost, schedule, or size for planned work using historical data, expert judgment, or models. Accuracy improves with calibrated baselines and feedback from actual results.

Identifying, analyzing, prioritizing, and controlling risks that could affect quality, schedule, or cost. It includes mitigation plans, contingency reserves, and ongoing monitoring of triggers.

The discipline of identifying, controlling, recording, and auditing configuration items and their changes. It ensures the right versions of work products are used and that changes are traceable.

Any product or artifact placed under configuration management, such as a requirement document, source file, test case, or build. Each item has an identified version and controlled changes.

A formally approved and frozen version of a configuration item or set of items, used as a reference for future changes. Changes to a baseline require controlled approval.

The formal process for requesting, evaluating, approving, and implementing changes to baselined items. It records impact analysis and ensures changes are tested and traceable.

Effort spent correcting defective work that was already completed. It is a major component of poor quality cost and a signal that prevention and detection activities need improvement.

The financial benefit gained from quality activities relative to their cost, such as reduced rework, support, and warranty expense. It supports business cases for prevention and appraisal spending.