Sk1

Front 1

Formal testing conducted to
determine whether or not a system satisfies its acceptance criteria—enables an end user to determine whether or not to accept the system.

Back 1

Acceptance Testing

Front 2

A group process that takes large amounts of language data, such as a list developed by brainstorming, and divides it into categories.

Back 2

Affinity Diagram

Hint 2

Diagram

Front 3

Testing of a software product or system
conducted at the developer's site by the end user.

Back 3

Alpha Testing

Front 4

An inspection/assessment activity that verifies
compliance with plans, policies, and procedures, and
ensures that resources are conserved. It is a staff
function; it serves as the "eyes and ears" of management.

Back 4

Audit

Front 5

That part of software testing that
is assisted with software tool(s) that does not require
operator input, analysis, or evaluation.

Back 5

Automated Testing

Front 6

Testing conducted at one or more end user sites by the end user of a delivered software product or system.

Back 6

Beta Testing

Front 7

Functional testing based on
requirements with no knowledge of the internal program structure or data. Also known as closed-box testing.

Back 7

Black-box Testing

Front 8

An integration testing technique that tests the low-level components first using test drivers for those components that have not yet been developed to call the low-level components for test.

Back 8

Bottom-up Testing

Front 9

A test data selection technique in which values are chosen to lie along data
extremes. Values include maximum, minimum, just inside/outside boundaries, typical values, and error values.

Back 9

Boundary Value Analysis

Front 10

A group process for generating creative and diverse ideas.

Back 10

Brainstorming

Front 11

A test method satisfying
coverage criteria that requires each decision point at each possible branch to be executed at least once.

Back 11

Branch Coverage Testing

Front 12

A design flaw that will result in symptoms
exhibited by some object (the object under test or some other object) when an object is subjected to an
appropriate test.

Back 12

Bug

Front 13

A tool used to identify possible causes of a problem by representing the relationship between some effect and its possible cause.

Back 13

Cause-and-Effect Diagram

Front 14

Fishbone Diagram is also known as ____

Back 14

Cause-and-Effect Diagram

Front 15

A testing technique that aids
in selecting, in a systematic way, a high-yield set of test cases that logically relates causes to effects to produce test cases. It has a beneficial side effect in pointing out
incompleteness and ambiguities in specifications.

Back 15

Cause-effect Graphing

Front 16

A form used to record data as it is gathered.

Back 16

Checksheet

Front 17

Another term for white-box testing. A.k.a structural testing since "white boxes" are considered opaque and
do not really permit visibility into the code. This is also known as glass-box or open-box testing.

Back 17

Clear-box Testing

Front 18

The end user that pays for the product received, and receives the benefit from the use of the product.

Back 18

Client

Front 19

A statistical method for distinguishing between common and special cause variation exhibited by processes.

Back 19

Control Chart

Front 20

The individual or organization, internal or external to the producing organization, that
receives the product.

Back 20

Customer (end user)

Front 21

A measure of the number of
linearly independent paths through a program module.

Back 21

Cyclomatic Complexity

Front 22

Consists of the graphical analysis of collections of (sequential) data definitions and reference patterns to determine constraints that can be
placed on data values at various points of executing the source program.

Back 22

Data Flow Analysis

Front 23

The act of attempting to determine the cause of the symptoms of malfunctions detected by testing or by frenzied user complaints.

Back 23

Debugging

Front 24

From the producer's
viewpoint: a product requirement that has not been met or a product attribute possessed by a product or a function performed by a product that is not in the statement of requirements that define the product.

Back 24

Defect

Front 25

From the end user's viewpoint: anything that causes end user dissatisfaction, whether in the statement of requirements or not.

Back 25

Defect

Front 26

Using defects as data for continuous quality improvement. Defect analysis generally seeks to classify defects into categories and identify possible causes in order to direct process improvement efforts.

Back 26

Defect Analysis

Front 27

Ratio of the number of defects to program length (a relative number).

Back 27

Defect Density

Front 28

A form of manual static analysis usually performed by the originator. Source code documentation, etc., is visually checked against
requirements and standards.

Back 28

Desk Checking

Front 29

The process of evaluating a
program based on execution of that program. Dynamic
analysis approaches rely on executing a piece of software with selected test data.

Back 29

Dynamic Analysis

Front 30

Verification or validation performed which executes the system's code.

Back 30

Dynamic Testing

Front 31

A discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition.

Back 31

Error

Front 32

A mental mistake made by a programmer that may result in a program fault.

Back 32

Error

Front 33

Testing where information about programming style, error-prone language constructs, and other programming knowledge is applied to select test data capable of detecting faults, either a specified class of faults or all possible faults.

Back 33

Error-based Testing

Front 34

The process of examining a system or system component to determine the extent to which specified properties are present.

Back 34

Evaluation

Front 35

The process of a computer carrying out an
instruction or instructions of a computer.

Back 35

Execution

Front 36

Executing the program with all possible combinations of values for program variables.

Back 36

Exhaustive Testing

Front 37

The inability of a system or system component to perform a required function within specified limits. It may be produced when a fault is encountered.

Back 37

Failure

Front 38

Testing based on the knowledge of the types of errors made in the past that are likely for the system under test.

Back 38

Failure-directed Testing

Front 39

A manifestation of an error in software. A fault, if encountered, may cause a failure.

Back 39

Fault

Front 40

Testing that employs a test data selection strategy designed to generate test data capable of demonstrating the absence of a set of prespecified faults, typically, frequently occurring faults.

Back 40

Fault-based Testing

Front 41

A form of safety analysis that assesses hardware safety to provide failure statistics and sensitivity analyses that indicate the possible effect of critical failures.

Back 41

Fault Tree Analysis

Front 42

A diagram showing the sequential steps of a process or of a workflow around a product or service.

Back 42

Flowchart

Front 43

A technical review conducted with the end user, including the types of reviews called for in the standards.

Back 43

Formal Review

Front 44

Application of test data derived from the specified functional requirements without regard to the final program structure. Also known as black-box testing.

Back 44

Functional Testing

Front 45

A consistent measure of software size based on user requirements. Data components include inputs, outputs, etc. Environment characteristics include data communications, performance, reusability, operational ease, etc.

Weight scale:
0 = not present;
1 = minor influence,
5 = strong influence.

Back 45

Function Points

Front 46

Another term for failure-directed testing.

Back 46

Heuristics Testing

Front 47

A graphical description of individual measured values in a data set that is organized according to the frequency or relative frequency of occurrence. It illustrates the shape of the distribution of individual values in a data set along with information regarding the average and variation.

Back 47

Histogram

Front 48

A combination of top-down testing combined with bottom-up testing of prioritized or
available components.

Back 48

Hybrid Testing

Front 49

Incremental analysis occurs
when (partial) analysis may be performed on an incomplete product to allow early feedback on the development of that product.

Back 49

Incremental Analysis

Front 50

Program statements sequence that can never be executed.

Back 50

Infeasible Path

Front 51

Products, services, or information needed from suppliers to make a process work.

Back 51

Inputs

Front 52

1) A formal evaluation technique in which software requirements, design, or code are examined in detail by a person or group other than the author to detect faults, violations of development standards, and other problems.
2) A quality improvement process for written material that consists of two dominant
components: product (document) improvement and
process improvement (document production and
inspection).

Back 52

Inspection

Front 53

To install or insert devices or instructions into hardware or software to monitor the operation of a
system or component.

Back 53

Instrument

Front 54

The process of combining software components or hardware components, or both, into an overall system.

Back 54

Integration

Front 55

An orderly progression of testing in which software components or hardware components, or both, are combined and tested until the entire system has been integrated.

Back 55

Integration Testing

Front 56

A shared boundary. An interface might be a hardware component to link two devices, or it might be a portion of storage or registers accessed by two or more computer programs.

Back 56

Interface

Front 57

Checks the interfaces between
program elements for consistency and adherence to
predefined rules or axioms.

Back 57

Interface Analysis

Front 58

Testing that collects timing and processing information during program execution that
may change the behavior of the software from its behavior in a real environment. Usually involves additional code embedded in the software being tested or additional processes running concurrently with software
being tested on the same platform.

Back 58

Intrusive Testing

Front 59

It is the verification and validation of a software product by an organization that is both technically and managerially separate from the organization responsible for developing the product.

Back 59

Independent verification and validation (IV&V)

Front 60

The period that starts when a software product is conceived and ends when the product is no longer available for use. The software life cycle typically includes a requirements phase, design phase, implementation (code) phase, test phase, installation and checkout phase, operation and maintenance phase, and a retirement phase.

Back 60

Life Cycle

Front 61

That part of software testing that requires operator input, analysis, or evaluation.

Back 61

Manual Testing

Front 62

A value derived by adding several qualities and
dividing the sum by the number of these quantities.

Back 62

Mean

Front 63

To ascertain or appraise by comparing to a standard; to apply a metric.

Back 63

Measure

Front 64

1) The act or process of measuring.
2) A figure, extent, or amount obtained by measuring.

Back 64

Measurement

Front 65

A measure of the extent or degree to which a product possesses and exhibits a certain quality, property, or attribute.

Back 65

Metric

Front 66

A method to determine test set thoroughness by measuring the extent to which a test set can discriminate the program from slight variants of the program.

Back 66

Mutation Testing

Front 67

Testing that is transparent to the software under test; i.e., testing that does not change the timing or processing characteristics of the software under test from its behavior in a real environment.
Usually involves additional hardware that collects timing or processing information and processes that information on another platform.

Back 67

Nonintrusive Testing

Front 68

Qualitative and quantitative
parameters that specify the desired operational capabilities of a system and serve as a basis for determining the operational effectiveness and suitability of a system prior to deployment.

Back 68

Operational Requirements

Front 69

Testing performed by the end
user on software in its normal operating environment.

Back 69

Operational Testing

Front 70

Products, services, or information supplied to meet end user needs.

Back 70

Outputs

Front 71

Program analysis performed to identify all possible paths through a program, to detect incomplete paths, or to discover portions of the program that are not on any path.

Back 71

Path Analysis

Front 72

A test method satisfying coverage criteria that each logical path through the program is tested. Paths through the program often are grouped into a finite set of classes; one path from each class is tested.

Back 72

Path Coverage Testing

Front 73

A methodical examination of software work products by the producer's peers to identify defects and areas where changes are needed.

Back 73

Peer Reviews

Front 74

Managerial desires and intents concerning either process (intended objectives) or products (desired attributes).

Back 74

Policy

Front 75

Any deviation from defined standards. Same as defect.

Back 75

Problem

Front 76

The step-by-step method followed to ensure that standards are met.

Back 76

Procedure

Front 77

The work effort that produces a product. This includes efforts of people and equipment guided by policies, standards, and procedures.

Back 77

Process

Front 78

To change a process to make
the process produce a given product faster, more economically, or of higher quality. Such changes may require the product to be changed. The defect rate must be maintained or reduced.

Back 78

Process Improvement

Front 79

The output of a process; the work product. There are three useful classes of products: manufactured products (standard and custom), administrative/
information products (invoices, letters, etc.), and service products (physical, intellectual, physiological, and psychological). These are defined by a statement of requirements; they are produced by one or more people working in a process.

Back 79

Product

Front 80

To change the statement of requirements that defines a product to make the product more satisfying and attractive to the end user (more competitive). Such changes may add to or delete from the list of attributes and/or the list of functions defining a product. Such changes frequently require the process to be changed. NOTE: This process could result in a totally new product.

Back 80

Product Improvement

Front 81

The ratio of the output of a process to the input, usually measured in the same units. It is frequently useful to compare the value added to a product by a process to the value of the input resources required (using fair market values for both input and output).

Back 81

Productivity

Front 82

A program that checks formal proofs of program properties for logical correctness.

Back 82

Proof Checker

Front 83

Evaluating requirements or designs at the conceptualization phase, the requirements analysis phase, or design phase by quickly building scaled-down components of the intended system to obtain rapid feedback of analysis and design decisions.

Back 83

Prototyping

Front 84

Formal testing, usually conducted by the developer for the end user, to demonstrate that the software meets its specified requirements.

Back 84

Qualification Testing

Front 85

A product is a quality product if it is defect free. To the producer a product is a quality product if it meets or conforms to the statement of requirements that defines the product.
This statement is usually shortened to _____ means meets requirements.
NOTE: Operationally, this word refers to products.

Back 85

Quality

Front 86

The set of support activities
(including facilitation, training, measurement, and analysis) needed to provide adequate confidence that processes are established and continuously improved in order to produce products that meet specifications and are fit for use.

Back 86

Quality Assurance (QA)

Front 87

The process by which product quality is compared with applicable standards; and the action taken when nonconformance is detected. It's focus is defect detection and removal. This is a line function, that is, the performance of these tasks is the responsibility of the people working within the process.

Back 87

Quality Control (QC)

Front 88

To change a production process so that the rate at which defective products (defects) are produced is reduced. Some process changes may require the product to be changed.

Back 88

Quality Improvement

Front 89

An essentially black-box testing approach in which a program is tested by randomly choosing a subset of all possible input values. The distribution may be arbitrary or may attempt to accurately reflect the distribution of inputs in the application environment.

Back 89

Random Testing

Front 90

Selective retesting to detect faults introduced during modification of a system or system component, to verify that modifications have not caused unintended adverse effects, or to verify that a modified system or system component still meets its specified requirements.

Back 90

Regression Testing

Front 91

The probability of failure-free operation for a specified period.

Back 91

Reliability

Front 92

A formal statement of:
1) an attribute to be possessed by the product or a function to be performed by the product;
2) the performance standard for the attribute or function; or
3) the measuring process to be used in verifying that the standard has been met.

Back 92

Requirement

Front 93

A way to use the diversity and power of a group of people to point out needed improvements in a product or confirm those parts of a product in which improvement is either not desired or not needed. A review is a general work product evaluation technique that includes desk checking, walkthroughs, technical reviews, peer reviews, formal reviews, and inspections.

Back 93

Review

Front 94

A graph of data points in chronological order used to illustrate trends or cycles of the characteristic being measured for the purpose of suggesting an assignable cause rather than random variation.

Back 94

Run Chart

Front 95

A graph designed to show whether there is a relationship between two changing factors.

Back 95

Scatter Plot (correlation diagram)

Front 96

1) The relationship of characters or a group of characters to their meanings, independent of the manner of their interpretation and use.
2) The relationships between symbols and their meanings.

Back 96

Semantics

Front 97

An inherent, possibly accidental, trait, quality, or property of software (for
example, functionality, performance, attributes, design constraints, number of states, lines of branches).

Back 97

Software Characteristic

Front 98

A software characteristic specified or implied by requirements documentation (for example, functionality, performance, attributes, or design constraints).

Back 98

Software Feature

Front 99

A computer program used to help develop, test, analyze, or maintain another computer program or its documentation;
e.g.: automated design tools, compilers, test tools, and maintenance tools

Back 99

Software Tool

Front 100

The measure used to evaluate products and identify nonconformance. The basis upon which adherence to policies is measured.

Back 100

Standards

Front 101

Procedures are implemented to ensure that the output of a process is maintained at a desired level.

Back 101

Standardize

Front 102

A test method satisfying coverage criteria that requires each statement be executed at least once.

Back 102

Statement Coverage Testing

Front 103

The exhaustive list of requirements that define a product.
NOTE: This should document requirements proposed and rejected (including the reason for the rejection) during the requirements determination process.

Back 103

Statement of Requirements

Front 104

Verification performed without executing the system's code.

Back 104

Static Testing

Front 105

Also called static analysis.

Back 105

Static Testing

Front 106

The use of statistical techniques and tools to measure an ongoing process for change or stability.

Back 106

Statistical Process Control

Front 107

This requires that each pair of module invocations be executed at least once.

Back 107

Structural Coverage

Front 108

A testing method where the test data is derived solely from the program structure.

Back 108

Structural Testing

Front 109

A software component that usually minimally simulates the actions of called components that have not yet been integrated during top-down testing.

Back 109

Stub

Front 110

An individual or organization that supplies inputs needed to generate a product, service, or information to an end user.

Back 110

Supplier

Front 111

1) The relationship among characters or groups of characters independent of their meanings or the manner of their interpretation and use; 2) the structure of expressions in a language; and 3) the rules governing the structure of the language.

Back 111

Syntax

Front 112

A collection of people, machines, and methods organized to accomplish a set of specified functions.

Back 112

System

Front 113

Another name for prototyping.

Back 113

System Simulation

Front 114

The process of testing an integrated hardware and software system to verify that the system meets its specified requirements.

Back 114

System Testing

Front 115

A review that refers to content of the technical material being reviewed.

Back 115

Technical Review

Front 116

1) An environment that contains the integral hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test of a logically or physically separate component.
2) A suite of test programs used in conducting the test of a component or system.

Back 116

Test Bed

Front 117

The definition of test case differs from company to company, engineer to engineer, and even project to project. A test case usually includes an identified set of information about observable states, conditions, events, and data, including inputs and expected outputs.

Back 117

Test Case

Front 118

The development of anything required to conduct testing. This may include test requirements (objectives), strategies, processes, plans, software, procedures, cases, documentation, etc.

Back 118

Test Development

Front 119

Another term for test harness.

Back 119

Test Executive

Front 120

The formal or informal procedure that will be followed to execute a test. This is usually a written document that allows others to execute the test with a minimum of training.

Back 120

Test Procedure

Front 121

A software tool that enables the testing of software components that links test capabilities to perform specific tests, accept program inputs, simulate missing components, compare actual outputs with expected outputs to determine correctness, and report discrepancies.

Back 121

Test Harness

Front 122

An identified set of software features to be measured under specified conditions by comparing actual behavior with the required behavior described in the software documentation.

Back 122

Test Objective

Front 123

A formal or informal plan to be followed to assure the controlled testing of the product under test.

Back 123

Test Plan

Front 124

Any activity aimed at evaluating an attribute or capability of a program or system to determine that it meets its required results. The process of exercising or
evaluating a system or system component by manual or automated means to verify that it satisfies specified requirements or to identify differences between expected and actual results.

Back 124

Testing

Front 125

An integration testing technique that tests the high-level components first using stubs for lower-level called components that have not yet been integrated and that stimulate the required actions of those components.

Back 125

Top-down Testing

Front 126

The testing done to show whether a unit (the smallest piece of software that can be independently compiled or assembled, loaded, and tested) satisfies its functional specification or its implemented structure matches the intended design structure.

Back 126

Unit Testing

Front 127

The end user that actually uses the product received.

Back 127

User

Front 128

The process of evaluating software to determine compliance with specified requirements.

Back 128

Validation

Front 129

The process of evaluating the products of a given software development activity to determine correctness and consistency with respect to the products and standards provided as input to that activity.

Back 129

Verification

Front 130

Usually, a step-by-step simulation of the execution of a procedure, as when walking through code, line by line, with an imagined set of inputs. The term has been extended to the review of material that is not procedural, such as data descriptions, reference manuals, specifications, etc.

Back 130

Walkthrough

Front 131

Testing approaches that examine the program structure and derive test data from the program logic.

Back 131

White-box Testing