Glossary

The definitions listed below have been extracted from the International Software Testing Qualifications Board (ISTQB) Standard Glossary of Terms used in Software Testing. Only the terms used for the Foundation Level certification exams are mentioned, so as not to drown the reader in terms that are used at other levels or in other syllabi.

Acceptance criteria: The criteria that a component or system must satisfy in order to be accepted by a user, customer or other authorized entity (from ISO 24765).

Acceptance test-driven development: A collaboration-based test-first approach that defines acceptance tests in the stakeholders’ domain language. Abbreviation: ATDD.

Acceptance testing: Formal testing with respect to user needs, requirements and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entities to determine whether or not to accept the system. See also user acceptance testing.

ACM: (Association for Computer Machinery) professional and scientific association for the development of information technology.

Alpha testing: Simulated or actual operational testing by potential users/customers or an independent test team at the developers’ site, but outside the development organization. Alpha testing is often employed as a form of internal acceptance testing.

Anomaly: A condition that deviates from expectation (from ISO 24765).

Attack: Directed and focused attempt to evaluate the quality, and especially the reliability, of a test object by attempting to force specific failures to occur.

Beta testing: Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers, to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes. Beta testing is often employed as a form of external acceptance testing in order to acquire feedback from the market.

Black-box technique: See also black-box testing.

Black-box test technique: A test technique based on an analysis of the specification of a component or system. Synonyms: black-box test design technique, specification-based test technique.

Black-box testing: Testing, either functional or nonfunctional, based on an analysis of the specification of the component or system. Synonym: specification-based testing.

Boundary value analysis: A black-box test technique in which test cases are designed based on boundary values. See also boundary values.

Branch coverage: The coverage of branches in a control flow graph (percentage of branches that have been exercised by a test suite). One hundred percent branch coverage implies both 100% decision coverage and 100% statement coverage.

Bug: See also defect.

Checklist-based testing: An experience-based test technique in which test cases are designed to exercise the items of a checklist.

Code coverage: An analysis method that determines which parts of the software have been executed (covered) by the test suite and which parts have not been executed, for example, statement coverage, decision coverage or condition coverage.

Collaboration-based test approach: An approach to testing that focuses on defect avoidance by collaborating among stakeholders.

Commercial off-the-shelf software (COTS): See also off-the-shelf software.

Compiler: A software tool that translates programs expressed in a high-order language into their machine language equivalents.

Complexity: The degree to which a component or system has a design and/or internal structure that is difficult to understand, maintain and verify. See also cyclomatic complexity.

Component integration testing: The testing executed to identify defects in the interfaces and interactions between integrated components. Synonyms: module integration testing, unit integration testing.

Component testing: A test level that focuses on individual hardware or software components. Synonyms: module testing, unit testing.

Configuration control: An element of configuration management, consisting of the evaluation, coordination, approval or disapproval, and implementation of changes to configuration items after formal establishment of their configuration identification.

Configuration item: An aggregation of hardware, software or both, that is designated for configuration management and treated as a single entity in the configuration management process.

Configuration management: A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.

Confirmation testing: A type of change-related testing performed after fixing a defect to confirm that a failure caused by that defect does not reoccur. Synonym: re-testing.

Control flow: An abstract representation of all possible sequences of events (paths) in the execution through a component or system.

Coverage: The degree to which specified coverage items are exercised by a test suite, expressed as a percentage. Synonym: test coverage.

Coverage item: An attribute or combination of attributes derived from one or more test conditions by using a test technique. See also coverage criteria.

Coverage measurement tool: See also coverage tool.

Coverage tool: A tool that provides objective measures of what structural elements, for example, statements, branches, have been exercised by the test suite.

Cyclomatic complexity: The number of independent paths through a program. Cyclomatic complexity is defined as: L – N + 2P, where:

• L = the number of edges/links in a graph;
• N = the number of nodes in a graph;
• P = the number of disconnected parts of the graph (e.g. a calling graph and a subroutine).

Data-driven testing: A scripting technique that stores test input and expected results in a table or spreadsheet, so that a single control script can execute all of the tests in the table. Data-driven testing is often used to support the application of test execution tools such as capture/playback tools. See also keyword-driven testing.

Data flow: An abstract representation of the sequence and possible changes of the state of data objects, where the state of an object can be creation, usage or destruction.

Debugging: The process of finding, analyzing and removing the causes of failures in a component or system.

Debugging tool: A tool used by programmers to reproduce failures, investigate the state of programs and find the corresponding defect. Debuggers enable programmers to execute programs step-by-step, halt a program at any program statement and set and examine program variables.

Decision coverage: The percentage of decision outcomes that have been exercised by a test suite. One hundred percent decision coverage implies both 100% branch coverage and 100% statement coverage.

Decision table testing: A black-box test technique in which test cases are designed to exercise the combinations of conditions inputs and/or stimuli (causes) shown in a decision table.

Defect: An imperfection or deficiency in a work product, which can cause the component or system to fail to perform its required function, for example, an incorrect statement or data definition (from ISO 24765). A defect, if encountered during execution, may cause a failure of the component or system. Synonyms: bug, fault.

Defect density: The number of defects identified in a component or system divided by the size of the component or system (expressed in standard measurement terms, for example, lines-of-code, number of classes or function points).

Defect management: The process of recognizing, recording, classifying, investigating, resolving and disposing of defects. It involves recording defects, classifying them and identifying the impact.

Defect management tool: See also incident management tool.

Defect report: Documentation of the occurrence, nature and status of a defect. Synonym: bug report.

Driver: A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system.

Dynamic analysis tool: A tool that provides run-time information on the state of the software code. These tools are most commonly used to identify unassigned pointers, check pointer arithmetic, and monitor the allocation, use and de-allocation of memory and highlight memory leaks.

Dynamic testing: Testing that involves the execution of the test item/software of a component or system (from ISO 29119-1). See...