3. Definitions, acronyms, and abbreviations
3.1 Definitions
For the purposes of this document, the following terms and definitions apply. The Authoritative Dictionary of IEEE Standards Terms [B2] and IEEE Std 610.12TM-1990 [B3] should be referenced for terms not defined in this clause.
3.1.1 acceptance testing: (A) Testing conducted to establish whether a system satisfies its acceptance criteria and to enable the customer to determine whether to accept the system. (B) Formal testing conducted to enable a user, customer, or other authorized entity to determine whether to accept a system or component. This is analogous to qualification testing in IEEE/EIA Std 12207.0-1996 [B21]. Another commonly used synonym is validation testing.
3.1.2 activity: An element of work performed during the implementation of a process. An activity normally has an expected duration, cost, and resource requirements. Activities are often subdivided into tasks.
3.1.3 address: To deal with, to take into consideration; (specifically) to decide whether and when a defined documentation topic is to be included, either directly or by reference to another document. Make a decision
as to whether an item is to be recorded prior to the test execution (in a tool or not in a tool), recorded during
the test execution, recorded post-test execution, not recorded (addressed by the process), or excluded.
3.1.4 anomaly: Anything observed in the documentation or operation of software or system that deviates
from expectations based on previously verified software products, reference documents, or other sources of
indicative behavior. (adopted from IEEE Std 610.12-1990 [B3])
3.1.5 checkout: Testing conducted in the operational or support environment to ensure that a software product performs as required after installation. (adopted from IEEE Std 610.12-1990 [B3])
3.1.6 component: One part that makes up a system. A component may be hardware or software and may be subdivided into other components. (adopted from IEEE Std 610.12-1990 [B3])
NOTE—The terms “module,” “component,” and “unit” are often used interchangeably or defined to be subelements of one another in different ways depending on the context. The relationship of these terms is not yet standardized.
3.1.7 component integration testing: Testing of groups of related components.
3.1.8 component testing: Testing of individual hardware or software components. (adopted from
IEEE Std 610.12-1990 [B3])
3.1.9 criticality: The degree of impact that a requirement, module, error, fault, failure, or other
characteristic has on the development or operation of a system. (adopted from IEEE Std 610.12-1990 [B3])
3.1.10 development testing: Testing conducted to establish whether a new software product or softwarebased system (or components of it) satisfies its criteria. The criteria will vary based on the level of test being performed.
3.1.11 document: (A) A medium, and the information recorded on it, that generally has permanence and can be read by a person or a machine. Examples in software engineering include project plans, specifications, test plans, and user manuals. (B) To create a document as in (A). (adopted from IEEE Std 610.12-1990 [B3])