Glossary of Testing Terms and Definitions

Acceptance Criteria	The definition of the results expected from the test cases used for acceptance testing. The product must meet these criteria before implementation can be approved.
Acceptance Testing	(1) Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the client to determine whether or not to accept the system. (2) Formal testing conducted to enable a user, client, or other authorized entity to determine whether to accept a system or component.
Acceptance Test Plan	Describes the steps the client will use to verify that the constructed system meets the acceptance criteria. It defines the approach to be taken for acceptance testing activities. The plan identifies the items to be tested, the test objectives, the acceptance criteria, the testing to be performed, test schedules, entry/exit criteria, staff requirements, reporting requirements, evaluation criteria, and any risks requiring contingency planning.
Adhoc Testing	A loosely structured testing approach that allows test developers to be creative in their test selection and execution. Adhoc testing is targeted at known or suspected problem areas.
Audit and Controls Testing	A functional type of test that verifies the adequacy and effectiveness of controls and completeness of data processing results.
Auditability	A test focus area defined as the ability to provide supporting evidence to trace processing of data.
Backup and Recovery Testing	A structural type of test that verifies the capability of the application to be restarted after a failure.
Black Box Testing	Evaluation techniques that are executed without knowledge of the program’s implementation. The tests are based on an analysis of the specification of the component without reference to its internal workings.
Bottom-up Testing	Approach to integration testing where the lowest level components are tested first then used to facilitate the testing of higher level components. This process is repeated until the component at the top of the hierarchy is tested. See "Top-down".
Boundary Value Analysis	A test case selection technique that selects test data that lie along "boundaries" or extremes of input and output possibilities. Boundary Value Analysis can apply to parameters, classes, data structures, variables, loops, etc.
Branch Testing	A white box testing technique that requires each branch or decision point to be taken once.
Build	(1) An operational version of a system or component that incorporates a specified subset of the capabilities that the final product will provide. Builds are defined whenever the complete system cannot be developed and delivered in a single increment. (2) A collection of programs within a system that are functionally independent. A build can be tested as a unit and can be installed independent of the rest of the system.
Business Function	A set of related activities that comprise a stand-alone unit of business. It may be defined as a process that results in the achievement of a business objective. It is characterized by well-defined start and finish activities and a workflow or pattern.
Capability Maturity Model (CMM)	A model of the stages through which software organizations progress as they define, implement, evolve, and improve their software process. This model provides a guide for selecting process improvement strategies by determining current process capabilities and identifying the issues most critical to software quality and process improvement. This concept was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University.
Causal Analysis	The evaluation of the cause of major errors, to determine actions that will prevent reoccurrence of similar errors.
Change Control	The process, by which a change is proposed, evaluated, approved or rejected, scheduled, and tracked.
Change Management	A process methodology to identify the configuration of a release and to manage all changes through change control, data recording, and updating of baselines.
Change Request	A documented proposal for a change of one or more work items or work item parts.
Condition Testing	A white box test method that requires all decision conditions be executed once for true and once for false.
Configuration Management	(1) The process of identifying and defining the configuration items in a system, controlling the release and change of these items throughout the system life cycle, recording and reporting the status of configuration items and change requests, and verifying the completeness and correctness of configuration items. (2) A discipline applying technical and administrative direction and surveillance to (a) identify and document the functional and physical characteristics of a configuration items, (b) control changes to those characteristics, and (c) record and report change processing and implementation status.
Conversion testing	A functional type of test that verifies the compatibility of converted programs, data and procedures with the “old” ones that are being converted or replaced.
Coverage	The extent to which test data tests a program’s functions, parameters, inputs, paths, branches, statements, conditions, modules or data flow paths.
Coverage Matrix	Documentation procedure to indicate the testing coverage of test cases compared to possible elements of a program environment (i.e. inputs, outputs, parameters, paths, cause-effects, equivalence partitioning, etc.).
Continuity of Processing	A test focus area defined as the ability to continue processing if problems occur. Included is the ability to backup and recover after a failure.
Correctness	A test focus area defined as the ability to process data according to prescribed rules. Controls over transactions and data field edits provide an assurance on accuracy and completeness of data.