Foundation Level Chapters 3 & 4

Front 1

dynamic testing

Back 1

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

Front 2

static testing

Back 2

Testing of a software development artifact, e.g., requirements, design or code, without execution of these artifacts, e.g., reviews or static analysis.

Front 3

entry criteria

Back 3

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 entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort needed to remove the failed entry criteria.

Front 4

formal review

Back 4

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

Front 5

informal review

Back 5

A review not based on a formal (documented) procedure.

Front 6

inspection

Back 6

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.

Front 7

metric

Back 7

A measurement scale and the method used for measurement.

Front 8

moderator

Back 8

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

Front 9

peer review

Back 9

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.

Front 10

reviewer

Back 10

The person involved in the review that identifies and describes anomalies in the product or project under review. Reviewers can be chosen to represent different viewpoints and roles in the review process.

Front 11

scribe

Back 11

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

Front 12

technical review

Back 12

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

Front 13

walkthrough

Back 13

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.

Front 14

compiler

Back 14

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

Front 15

complexity

Back 15

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

Front 16

control flow

Back 16

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

Front 17

data flow

Back 17

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.

Front 18

static analysis

Back 18

Analysis of software development artifacts, e.g., requirements or code, carried out without execution of these software development artifacts. Static analysis is usually carried out by means of a supporting tool.

Front 19

test case specification

Back 19

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

Front 20

test design

Back 20

The process of transforming general test objectives into tangible test conditions and test cases.

Front 21

test execution schedule

Back 21

A scheme for the execution of test procedures. Note: The test procedures are included in the test execution schedule in their context and in the order in which they are to be executed.

Front 22

test procedure specification

Back 22

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

Front 23

test script

Back 23

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

Front 24

traceability

Back 24

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

Front 25

black-box test design technique

Back 25

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.

Front 26

experience-based test design technique

Back 26

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

Front 27

test design technique

Back 27

Procedure used to derive and/or select test cases.

Front 28

white-box test design technique

Back 28

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

Front 29

boundary value analysis

Back 29

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

Front 30

decision table testing

Back 30

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.

Front 31

equivalence partitioning

Back 31

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 32

state transition testing

Back 32

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

Front 33

use case testing

Back 33

A black-box test design technique in which test cases are designed to execute scenarios of use cases.

Front 34

code coverage

Back 34

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, e.g., statement coverage, decision coverage or condition coverage.

Front 35

decision coverage

Back 35

The percentage of decision outcomes that have been exercised by a test suite, 100% decision coverage implies both 100% branch coverage and 100% statement coverage.

Front 36

statement coverage

Back 36

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

Front 37

structure-based testing

Back 37

Testing based on an analysis of the internal structure of the component or system.

Front 38

exploratory testing

Back 38

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 39

(fault) attack

Back 39

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