Complete Glossary

Question 1

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

Answer 1

.black-box test design technique

Question 2

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

Answer 2

boundary value analysis

Question 3

An experience-based test design technique whereby the experienced tester uses a high-level list of items to be noted, checked, or remembered, or a set of rules or criteria
against which a product has to be verified.

Answer 3

checklist-based testing

Question 4

Simulated or actual operational testing by potential users/customers or an independent test team at the developers’ site, but outside the development organization. Alpha
testing is often employed for commercial off-the-shelf software as a form of internal acceptance testing.

Answer 4

alpha testing

Question 5

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.

Answer 5

decision table testing

Question 6

Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers, to determine whether or not a component or
system satisfies the user/customer needs and fits within the business processes. Beta testing is often employed as a form of external acceptance testing for commercial offthe-shelf software in order to acquire feedback from the market.

Answer 6

beta testing

Question 7

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.

Answer 7

equivalence partitioning

Question 8

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.

Answer 8

error guessing

Question 9

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

Answer 9

exit criteria

Question 10

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

Answer 10

experience-based test design technique

Question 11

The percentage of boundary values that have been exercised by a test suite.

Answer 11

boundary value coverage

Question 12

A basic block that can be selected for execution based on a program construct in which one of two or more alternative program paths is available, e.g., case, jump, go to, ifthen-else.

Answer 12

branch

Question 13

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.

Answer 13

exploratory testing

Question 14

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.

Answer 14

high-level test case

Question 15

A test case with concrete (implementation level) values for input data and expected results. Logical operators from high-level test cases are replaced by actual values that
correspond to the objectives of the logical operators.

Answer 15

low-level test case

Question 16

A risk directly related to the test object.

Answer 16

product risk

Question 17

The process of assessing identified project or product risks to determine their level of risk, typically by estimating their impact and probability of occurrence (likelihood).

Answer 17

risk analysis

Question 18

The process of identifying risks using techniques such as brainstorming, checklists and failure history.

Answer 18

risk identification

Question 19

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

Answer 19

compiler

Question 20

The importance of a risk as defined by its characteristics impact and likelihood. The level of risk can be used to determine the intensity of testing to be performed. A risk level
can be expressed either qualitatively (e.g., high, medium, low) or quantitatively.

Answer 20

risk level

Question 21

Systematic application of procedures and practices to the tasks of identifying, analyzing, prioritizing, and controlling risk.

Answer 21

risk management

Question 22

The process through which decisions are reached and protective measures are implemented for reducing risks to, or maintaining risks within, specified levels.

Answer 22

risk mitigation

Question 23

An approach to testing to reduce the level of product risks and inform stakeholders of their status, starting in the initial stages of a project. It involves the identification of
product risks and the use of risk levels to guide the test process.

Answer 23

risk-based testing

Question 24

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

Answer 24

state transition testing

Question 25

An aggregation of hardware, software or both, that is designated for configuration management and treated as a single entity in the configuration management process.

Answer 25

configuration item

Question 26

A statement of test objectives, and possibly test ideas about how to test. Test charters are used in exploratory testing.

Answer 26

test charter

Question 27

Testing that runs test cases that failed the last time they were run, in order to verify the success of corrective actions.

Answer 27

confirmation testing

Question 28

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

Answer 28

control flow

Question 29

A form of static analysis based on a representation of unique paths (sequences of events) in the execution through a component or system. Control flow analysis evaluates the integrity of control flow structures, looking for possible control flow anomalies such as closed loops or logically unreachable process steps.

Answer 29

control flow analysis

Question 30

An abstract representation of all possible sequences of events (paths) in the execution through a component or system.

Answer 30

control flow graph

Question 31

An approach to structure-based testing in which test cases are designed to execute specific sequences of events. Various techniques exist for control flow testing, e.g., decision testing, condition testing, and path testing, that each have their specific approach and level of control flow coverage.

Answer 31

control flow testing

Question 32

An entity or property used as a basis for test coverage, e.g., equivalence partitions or code statements.

Answer 32

coverage item

Question 33

The maximum number of linear, independent paths through a program. Cyclomatic complexity may be computed 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 or subroutine).

Answer 33

cyclomatic complexity

Question 34

The process of transforming general test objectives into tangible test conditions and test case

Answer 34

test design

Question 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.

Answer 35

decision coverage

Question 36

The result of a decision (which therefore determines the branches to be taken).

Answer 36

decision outcome

Question 37

A white-box test design technique in which test cases are designed to execute decision outcomes.

Answer 37

decision testing

Question 38

The number of defects identified in a component or system divided by the size of the component or system (expressed in standard measurement terms, e.g., lines-of-code, number of classes or function points).

Answer 38

defect density

Question 39

The number of defects found by a test level, divided by the number found by that test level and any other means afterwards.

Answer 39

Defect Detection Percentage (DDP)

Question 40

The process of developing and prioritizing test procedures, creating test data and, optionally, preparing test harnesses and writing automated test scripts.

Answer 40

test implementation

Question 41

A test management task that deals with the activities related to periodically checking the status of a test project. Reports are prepared that compare the actuals to that which was planned.

Answer 41

test monitoring

Question 42

A high-level description of the test levels to be performed and the testing within those levels for an organization or programme (one or more projects).

Answer 42

test strategy

Question 43

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

Answer 43

use case testing

Question 44

The exit criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authorized entity.

Answer 44

acceptance criteria

Question 45

he capability of the software product to be adapted for different specified environments without applying actions or means other than those provided for this purpose for the software considered.

Answer 45

adaptability

Question 46

The capability of the software product to be diagnosed for deficiencies or causes of failures in the software, or for the parts to be modified to be identified.

Answer 46

analyzability

Question 47

An independent evaluation of software products or processes to ascertain compliance to standards, guidelines, specifications, and/or procedures based on objective criteria, including documents that specify: the form or content of the products to be produced, the process by which the products shall be produced, and how compliance to standards or guidelines shall be measured.

Answer 47

audit

Question 48

The degree to which a component or system is operational and accessible when required for use. Often expressed as a percentage.

Answer 48

availability

Question 49

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.

Answer 49

boundary value

Question 50

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

Answer 50

branch coverage

Question 51

A minimal software item that can be tested in isolatio

Answer 51

component

Question 52

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

Answer 52

impact analysis

Question 53

The testing of individual software components.

Answer 53

component testing

Question 54

The process of recognizing, investigating, taking action and disposing of incidents. It involves logging incidents, classifying them and identifying the impact.

Answer 54

incident management

Question 55

A tool that facilitates the recording and status tracking of incidents. They often have workflow-oriented facilities to track and control the allocation, correction and re-testing of incidents and provide reporting facilities.

Answer 55

incident management tool

Question 56

A document reporting on any event that occurred, e.g., during the testing, which requires investigation.

Answer 56

incident report

Question 57

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

Answer 57

informal review

Question 58

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

Answer 58

coverage

Question 59

A program point at which the control flow has two or more alternative routes. A node with two or more links to separate branches.

Answer 59

decision | A program point at which the control flow has two or more alt

Question 60

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.

Answer 60

decision table

Question 61

A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g., an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.

Answer 61

defect

Question 62

The process of recognizing, investigating, taking action and disposing of defects. It involves recording defects, classifying them and identifying the impact.

Answer 62

defect management

Question 63

A tool that facilitates the recording and status tracking of defects and changes. They often have workflow-oriented facilities to track and control the allocation, correction and retesting of defects and provide reporting facilities.

Answer 63

defect management tool

Question 64

A test plan that typically addresses multiple test levels

Answer 64

master test plan

Question 65

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.

Answer 65

entry criteria

Question 66

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.

Answer 66

equivalence partition

Question 67

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

Answer 67

moderator | The leader and main person responsible for an inspectio

Question 68

A software tool or hardware device that runs concurrently with the component or system under test and supervises, records and/or analyzes the behavior of the component or system.

Answer 68

monitoring tool

Question 69

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

Answer 69

expected result

Question 70

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

Answer 70

failure

Question 71

A software development approach whereby lines of code (production and/or test) of a component are written by two programmers sitting at a single computer. This implicitly means ongoing real-time code reviews are performed

Answer 71

pair programming

Question 72

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

Answer 72

formal review

Question 73

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

Answer 73

path coverage

Question 74

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.

Answer 74

peer review

Question 75

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

Answer 75

functional testing

Question 76

Any event occurring that requires investigation

Answer 76

incident

Question 77

A development lifecycle where a project is broken into a series of increments, each of which delivers a portion of the functionality in the overall project requirements. The requirements are prioritized and delivered in priority order in the appropriate increment. In some (but not all) versions of this lifecycle model, each subproject follows a mini Vmodel with its own design, coding and testing phases.

Answer 77

incremental development model

Question 78

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.

Answer 78

inspection