Istqb F.l. Glossary Chapters 3 & 4

Front 1

The process consisting of all life cycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects.

Back 1

Testing

Front 2

Testing of a component or system at specification or implementation level without execution of that software, e.g. reviews.

Back 2

Static testing

Front 3

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

Back 3

Dynamic Testing

Front 4

A review not based on a documented procedure.

Back 4

Informal review

Front 5

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

Back 5

Formal review

Front 6

The leader and main person responsible for an inspection or other review process.

Back 6

Moderator

Front 7

The set of generic and specific conditions for permitting a process to go forward with a defined task, e.g. test phase.

Back 7

Entry criteria

Front 8

The person that identifies and describes anomalies in the product or project. Can be chosen to represent different viewpoints and roles.

Back 8

Reviewer (inspector)

Front 9

The person who records each defect mentioned and any suggestions for process improvement during a review meeting, on a logging form. This person has to ensure that the logging form is readable and understandable.

Back 9

Scribe

Front 10

A review of a software work product by colleagues of the producer of the product for the purpose of identifying defects and improvements. Examples are inspection, technical review and walkthrough.

Back 10

Peer review

Front 11

A step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content.

Back 11

Walkthrough

Front 12

A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken.

Back 12

Technical review

Front 13

A type of peer review that relies on visual examination of documents to detect defects, e.g. violations of development standards and non-conformance to higher level documentation. The most formal review technique and therefore always based on a documented procedure.

Back 13

Inspection

Front 14

Analysis of software artifacts, e.g. requirements or code, carried out without execution of these software artifacts.

Back 14

Static analysis

Front 15

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

Back 15

Compiler

Front 16

The degree to which a component or system has a design and/or internal structure that is difficult to understand, maintain and verify.

Back 16

Complexity

Front 17

The number of independent paths through a program. 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 called graph and a subroutine)

Back 17

Cyclomatic complexity

Front 18

A sequence of events (paths) in the execution through a component or system.

Back 18

Control flow

Front 19

An abstract representation of the sequence and possible changes of the state of data objects, where the state of an object is any of: creation, usage, or destruction.

Back 19

Data flow

Front 20

A measurement scale and the method used for measurement.

Back 20

Metric

Front 21

Procedure used to derive and/or select test cases.

Back 21

Test design technique

Front 22

The ability to identify related items in documentation and software, such as requirements with associated tests.

Back 22

Traceability

Front 23

A document specifying the test conditions (coverage items) for a test item, the detailed test approach and identifying the associated high level test cases.

Back 23

Test design specification

Front 24

A document specifying a set of test cases (objective, inputs, test actions, expected results, and execution preconditions) for a test item.

Back 24

Test case specification

Front 25

A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script.

Back 25

Test procedure specification

Front 26

Commonly used to refer to a test procedure specification, especially an automated one.

Back 26

Test script

Front 27

Procedure to derive and/or select test cases based on an analysis of the specification, either functional or non-functional, of a component or system without reference to its internal structure.

Back 27

Black-box test design technique

Front 28

Procedure to derive and/or select test cases based on an analysis of the internal structure of a component or system. Another name for white-box test design technique.

Back 28

Structure-based test design technique

Front 29

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

Back 29

Experienced-based test design technique

Front 30

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.

Back 30

Equivalence partitioning

Front 31

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.

Back 31

Equivalence partition

Front 32

An input value or output value which is on the edge of an equivalence partition or at the smallest incremental distance on either side of an edge, for example the minimum or maximum value of a range.

Back 32

Boundary value

Front 33

A black box test design technique in which test cases are designed based on boundary values.

Back 33

Boundary value analysis

Front 34

A table showing combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects), which can be used to design test cases.

Back 34

Decision table

Front 35

A black box test design technique in which test cases are designed to execute the combinations of inputs and/or stimuli (causes) shown in a decision table.

Back 35

Decision table testing

Front 36

A black box test design technique in which test cases are designed to execute valid and invalid state transitions. See also N-switch testing.

Back 36

State transition testing

Front 37

A diagram that depicts the states that a component or system can assume, and shows the events or circumstances that cause and/or result from a change from one state to another.

Back 37

State diagram

Front 38

A grid showing the resulting transitions for each state combined with each possible event, showing both valid and invalid transitions.

Back 38

State table

Front 39

A black box test design technique in which test cases are designed to execute user scenarios.

Back 39

Use case testing

Front 40

Procedure to derive and/or select test cases based on an analysis of the internal structure of a component or system.

Back 40

Structure-based test design techniques

Front 41

The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite.

Back 41

Coverage (test coverage)

Front 42

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

Back 42

Code coverage

Front 43

The percentage of executable statements that have been exercised by a test suite.

Back 43

Statement coverage

Front 44

The percentage of decision outcomes that have been exercised by a test suite.

Back 44

Decision coverage (100% branch coverage & 100% statement coverage)

Front 45

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.

Back 45

Error guessing

Front 46

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.

Back 46

Exploratory testing

Front 47

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

Back 47

Attack (fault attack)