Istqb (Qa) Certification

Front 1

abstract test case

Back 1

See high level test case.

Front 2

acceptance

Back 2

See acceptance testing.

Front 3

acceptance criteria

Back 3

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

Front 4

acceptance testing

Back 4

Formal testing with respect to user needs, requirements, and business
processes conducted to determine whether or not a system satisfies the acceptance criteria
and to enable the user, customers or other authorized entity to determine whether or not to
accept the system. [After IEEE 610]

Front 5

accessibility testing

Back 5

Testing to determine the ease by which users with disabilities can use a
component or system. [Gerrard]

Front 6

accuracy

Back 6

The capability of the software product to provide the right or agreed results or effects
with the needed degree of precision. [ISO 9126] See also functionality testing.

Front 7

accuracy testing

Back 7

The process of testing to determine the accuracy of a software product

Front 8

acting (IDEAL)

Back 8

The phase within the IDEAL model where the improvements are
developed, put into practice, and deployed across the organization. The acting phase
consists of the activities: create solution, pilot/test solution, refine solution and implement
solution. See also IDEAL.

Front 9

action word driven testing

Back 9

See keyword driven testing

Front 10

actual outcome

Back 10

See actual result.

Front 11

actual result

Back 11

The behavior produced/observed when a component or system is tested.

Front 12

ad hoc review

Back 12

See informal review.

Front 13

ad hoc testing

Back 13

Testing carried out informally; no formal test preparation takes place, no
recognized test design technique is used, there are no expectations for results and
arbitrariness guides the test execution activity.

Front 14

adaptability

Back 14

The 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. [ISO 9126] See also portability.

Front 15

agile manifesto

Back 15

A statement on the values that underpin agile software development. The
values are:
- individuals and interactions over processes and tools
- working software over comprehensive documentation
- customer collaboration over contract negotiation
- responding to change over following a plan.

Front 16

agile software development

Back 16

A group of software development methodologies based on
iterative incremental development, where requirements and solutions evolve through
collaboration between self-organizing cross-functional teams.

Front 17

agile testing

Back 17

Testing practice for a project using agile methodologies, such as extreme
programming (XP), treating development as the customer of testing and emphasizing the
test-first design paradigm. See also test driven development.

Front 18

algorithm test

Back 18

[TMap] See branch testing.

Front 19

alpha testing

Back 19

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 off-the-shelf software as a form of internal acceptance
testing.

Front 20

analyzability

Back 20

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. [ISO 9126] See
also maintainability.

Front 21

analyzer

Back 21

See static analyzer.

Front 22

anomaly

Back 22

Any condition that deviates from expectation based on requirements specifications,
design documents, user documents, standards, etc. or from someone’s perception or
experience. Anomalies may be found during, but not limited to, reviewing, testing,
analysis, compilation, or use of software products or applicable documentation. [IEEE
1044] See also bug, defect, deviation, error, fault, failure, incident, problem.

Front 23

arc testing

Back 23

See branch testing.

Front 24

assessment report

Back 24

A document summarizing the assessment results, e.g. conclusions,
recommendations and findings. See also process assessment.

Front 25

assessor

Back 25

A person who conducts an assessment; any member of an assessment team.

Front 26

attack

Back 26

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

Front 27

attractiveness

Back 27

The capability of the software product to be attractive to the user. [ISO 9126]
See also usability.

Front 28

audit

Back 28

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:
(1) the form or content of the products to be produced
(2) the process by which the products shall be produced
(3) how compliance to standards or guidelines shall be measured. [IEEE 1028]

Front 29

audit trail

Back 29

A path by which the original input to a process (e.g. data) can be traced back
through the process, taking the process output as a starting point. This facilitates defect
analysis and allows a process audit to be carried out. [After TMap]

Front 30

automated testware

Back 30

Testware used in automated testing, such as tool scripts.

Front 31

availability

Back 31

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

Front 32

back-to-back testing

Back 32

Testing in which two or more variants of a component or system are
executed with the same inputs, the outputs compared, and analyzed in cases of
discrepancies. [IEEE 610]

Front 33

balanced scorecard

Back 33

A strategic performance management tool for measuring whether the
operational activities of a company are aligned with its objectives in terms of business
vision and strategy. See also corporate dashboard, scorecard.

Front 34

baseline

Back 34

A specification or software product that has been formally reviewed or agreed upon,
that thereafter serves as the basis for further development, and that can be changed only
through a formal change control process. [After IEEE 610]

Front 35

basic block

Back 35

A sequence of one or more consecutive executable statements containing no
branches. Note: A node in a control flow graph represents a basic block.

Front 36

basis test set

Back 36

A set of test cases derived from the internal structure of a component or
specification to ensure that 100% of a specified coverage criterion will be achieved.

Front 37

bebugging

Back 37

See fault seeding

Front 38

behavior

Back 38

The response of a component or system to a set of input values and preconditions.

Front 39

benchmark test

Back 39

(1) A standard against which measurements or comparisons can be made.
(2) A test that is be used to compare components or systems to each other or to a standard
as in (1). [After IEEE 610]

Front 40

bespoke software

Back 40

Software developed specifically for a set of users or customers. The
opposite is off-the-shelf software.

Front 41

best practice

Back 41

A superior method or innovative practice that contributes to the improved
performance of an organization under given context, usually recognized as ‘best’ by other
peer organizations.

Front 42

beta testing

Back 42

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 off-the-shelf software
in order to acquire feedback from the market.

Front 43

big-bang testing

Back 43

A type of integration testing in which software elements, hardware
elements, or both are combined all at once into a component or an overall system, rather
than in stages. [After IEEE 610] See also integration testing.

Front 44

black box technique

Back 44

See black box test design technique.

Front 45

black box test design technique

Back 45

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 46

black box testing

Back 46

Testing, either functional or non-functional, without reference to the
internal structure of the component or system.

Front 47

blocked test case

Back 47

A test case that cannot be executed because the preconditions for its
execution are not fulfilled.

Front 48

bottom-up testing

Back 48

An incremental approach to integration testing where the lowest level
components are tested first, and then used to facilitate the testing of higher level
components. This process is repeated until the component at the top of the hierarchy is
tested. See also integration testing.

Front 49

boundary value

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

Front 50

boundary value analysis

Back 50

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

Front 51

boundary value coverage

Back 51

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

Front 52

boundary value testing

Back 52

See boundary value analysis.

Front 53

branch

Back 53

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.

Front 54

branch condition

Back 54

See condition.

Front 55

branch condition combination coverage

Back 55

See multiple condition coverage.

Front 56

branch condition combination testing

Back 56

See multiple condition testing.

Front 57

branch condition coverage

Back 57

See condition coverage.

Front 58

branch coverage

Back 58

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

Front 59

branch testing

Back 59

A white box test design technique in which test cases are designed to execute
branches.

Front 60

buffer

Back 60

A device or storage area used to store data temporarily for differences in rates of data
flow, time or occurrence of events, or amounts of data that can be handled by the devices
or processes involved in the transfer or use of the data. [IEEE 610]

Front 61

buffer overflow

Back 61

A memory access failure due to the attempt by a process to store data
beyond the boundaries of a fixed length buffer, resulting in overwriting of adjacent
memory areas or the raising of an overflow exception. See also buffer.

Front 62

bug

Back 62

See defect.

Front 63

bug report

Back 63

See defect report.

Front 64

bug taxonomy

Back 64

See defect taxonomy.

Front 65

bug tracking tool

Back 65

See defect management tool.

Front 66

business process-based testing

Back 66

An approach to testing in which test cases are designed
based on descriptions and/or knowledge of business processes.

Front 67

call graph

Back 67

An abstract representation of calling relationships between subroutines in a
program.

Front 68

Capability Maturity Model (CMM)

Back 68

A five level staged framework that describes the key
elements of an effective software process. The Capability Maturity Model covers bestpractices
for planning, engineering and managing software development and maintenance.
[CMM] See also Capability Maturity Model Integration (CMMI).

Front 69

Capability Maturity Model Integration (CMMI)

Back 69

A framework that describes the key
elements of an effective product development and maintenance process. The Capability
Maturity Model Integration covers best-practices for planning, engineering and managing
product development and maintenance. CMMI is the designated successor of the CMM.
[CMMI] See also Capability Maturity Model (CMM).

Front 70

capture/playback tool

Back 70

A type of test execution tool where inputs are recorded during
manual testing in order to generate automated test scripts that can be executed later (i.e.
replayed). These tools are often used to support automated regression testing.

Front 71

capture/replay tool

Back 71

See capture/playback tool.

Front 72

CASE

Back 72

Acronym for Computer Aided Software Engineering.

Front 73

CAST

Back 73

Acronym for Computer Aided Software Testing. See also test automation.

Front 74

causal analysis

Back 74

The analysis of defects to determine their root cause. [CMMI]

Front 75

cause-effect analysis

Back 75

See cause-effect graphing.

Front 76

cause-effect decision table

Back 76

See decision table.

Front 77

cause-effect diagram

Back 77

A graphical representation used to organize and display the
interrelationships of various possible root causes of a problem. Possible causes of a real or potential defect or failure are organized in categories and subcategories in a horizontal
tree-structure, with the (potential) defect or failure as the root node. [After Juran]

Front 78

cause-effect graph

Back 78

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

Front 79

cause-effect graphing

Back 79

A black box test design technique in which test cases are designed
from cause-effect graphs. [BS 7925/2]

Front 80

certification

Back 80

The process of confirming that a component, system or person complies with
its specified requirements, e.g. by passing an exam.

Front 81

change control

Back 81

See configuration control.

Front 82

change control board

Back 82

See configuration control board.change management: (1) A
structured approach to transitioning individuals, teams, and organizations from a current
state to a desired future state. (2) Controlled way to effect a change, or a proposed change,
to a product or service. See also configuration management.

Front 83

changeability

Back 83

The capability of the software product to enable specified modifications to be
implemented. [ISO 9126] See also maintainability.

Front 84

checklist-based testing

Back 84

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. See also experience-based testing.

Front 85

classification tree

Back 85

A tree showing equivalence partitions hierarchically ordered, which is
used to design test cases in the classification tree method. See also classification tree
method.

Front 86

classification tree method

Back 86

A black box test design technique in which test cases,
describedby means of a classification tree, are designed to execute combinations of
representatives of input and/or output domains. [Grochtmann]

Front 87

clear-box testing

Back 87

See white-box testing.

Front 88

Chow's coverage metrics

Back 88

See N-switch coverage. [Chow]

Front 89

code

Back 89

Computer instructions and data definitions expressed in a programming language or in
a form output by an assembler, compiler or other translator. [IEEE 610]

Front 90

code analyzer

Back 90

See static code analyzer.