Istqb Glossary Report - Foundation (V3.01) -- Part 3

Front 1

driver

Back 1

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.

Front 2

dynamic analysis tool

Back 2

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 to monitor the allocation, use and de-allocation of memory and to flag memory leaks.

Front 3

dynamic testing

Back 3

Testing that involves the execution of the software of a component or system.

Front 4

effectiveness

Back 4

The capability of producing an intended result.

Front 5

efficiency

Back 5

(1) The capability of the software product to provide appropriate performance, relative to the amount of resources used, under stated conditions.

(2) The capability of a process to produce the intended outcome, relative to the amount of resources used.

Front 6

entry criteria

Back 6

The set of generic and specific conditions for permitting a process to go forward with a defined task, e.g., test phase. The purpose of it is to prevent a task from starting which would entail more (wasted) effort compared to the effort needed to remove the failed one.

Front 7

equivalence class

Back 7

A portion of an input or output domain for which the behavior of a component or system is assumed to be the same, based on the specification.

Front 8

equivalence partitioning

Back 8

A black-box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle, test cases are designed to cover each partition at least once.

Front 9

error

Back 9

A human action that produces an incorrect result.

Front 10

error guessing

Back 10

A test design technique where the experience of the tester is used to anticipate what defects might be present in the component or system under test as a result of errors made, and to design tests specifically to expose them.

Front 11

executable statement

Back 11

A statement which, when compiled, is translated into object code, and which will be executed procedurally when the program is running and may perform an action on data.

Front 12

exercised

Back 12

A program element is said to be ___ by a test case when the input value causes the execution of that element, such as a statement, decision, or other structural element.

Front 13

exhaustive testing

Back 13

A test approach in which the test suite comprises all combinations of input values and preconditions.

Front 14

exit criteria

Back 14

The set of generic and specific conditions, agreed upon with the stakeholders for permitting a process to be officially completed. The purpose of it is to prevent a task from being considered completed when there are still outstanding parts of the task which have not been finished. These are used to report against and to plan when to stop testing.

Front 15

expected result

Back 15

The behavior predicted by the specification, or another source, of the component or system under specified conditions.

Front 16

experience-based test design technique

Back 16

Procedure to derive and/or select test cases based on the tester's experience, knowledge and intuition.

Front 17

experience-based testing

Back 17

Testing based on the tester's experience, knowledge and intuition.

Front 18

exploratory testing

Back 18

An informal test design technique where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests.

Front 19

factory acceptance testing

Back 19

Acceptance testing conducted at the site at which the product is developed and performed by employees of the supplier organization, to determine whether or not a component or system satisfies the requirements, normally including hardware as well as software.

Front 20

test fail

Back 20

A test is deemed to fail if its actual result does not match its expected result.

Front 21

failure

Back 21

Deviation of the component or system from its expected delivery, service or result.

Front 22

failure rate

Back 22

The ratio of the number of failures of a given category to a given unit of measure, e.g., failures per unit of time, failures per number of transactions, failures per number of computer runs.

Front 23

attack

Back 23

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

Front 24

feature

Back 24

An attribute of a component or system specified or implied by requirements documentation (for example reliability, usability or design constraints).

Front 25

formal review

Back 25

A review characterized by documented procedures and requirements, e.g., inspection.

Front 26

functional requirement

Back 26

A requirement that specifies a function that a component or system must perform.

Front 27

functional testing

Back 27

Testing based on an analysis of the specification of the functionality of a component or system.

Front 28

functionality

Back 28

The capability of the software product to provide functions which meet stated and implied needs when the software is used under specified conditions.

Front 29

high-level test case / abstract test case

Back 29

A test case without concrete (implementation level) values for input data and expected results. Logical operators are used: instances of the actual values are not yet defined and/or available.

Front 30

impact analysis

Back 30

The assessment of change to the layers of development documentation, test documentation and components, in order to implement a given change to specified requirements.