Vocalulary Of Cste

Front 1

Access Modeling

Back 1

Used to verify that data requirements (represented in the form
of an entity-relationship diagram) support the data demands of
process requirements (represented in data flow diagrams and
process specifications.)

Front 2

Affinity Diagram

Back 2

A group process that takes large amounts of language data,
such as a list developed by brainstorming, and divides it into
categories.

Front 3

Application

Back 3

A single software product that may or may not fully support a
business function.

Front 4

Audit

Back 4

This is an inspection/assessment activity that verifies
compliance with plans, policies, and procedures, and ensures
that resources are conserved. Audit is a staff function; it serves
as the "eyes and ears" of management.

Front 5

Backlog

Back 5

Work waiting to be done; for IT this includes new systems to be
developed and enhancements to existing systems. To be
included in the development backlog, the work must have been
cost-justified and approved for development.

Front 6

Baseline

Back 6

A quantitative measure of the current level of performance.

Front 7

Benchmarking

Back 7

Comparing your company’s products, services, or processes
against best practices, or competitive practices, to help define
superior performance of a product, service, or support process.

Front 8

Benefits Realization
Test

Back 8

A test or analysis conducted after an application is moved into
production to determine whether it is likely to meet the
originating business case.

Front 9

Black-Box Testing

Back 9

A test technique that focuses on testing the functionality of the
program, component, or application against its specifications without knowledge of how the system is constructed; usually
data or business process driven.

Front 10

Boundary Value
Analysis

Back 10

A data selection technique in which test data is chosen from the
“boundaries” of the input or output domain classes, data
structures, and procedure parameters. Choices often include
the actual minimum and maximum boundary values, the
maximum value plus or minus one, and the minimum value
plus or minus one.

Front 11

Brainstorming

Back 11

A group process for generating creative and diverse ideas.

Front 12

Branch Testing

Back 12

A test method that requires that each possible branch on each
decision point be executed at least once.

Front 13

Bug

Back 13

A general term for all software defects or errors.

Front 14

Candidate

Back 14

An individual who has met eligibility requirements for a
credential awarded through a certification program, but who
has not yet earned that certification through participation in the
required skill and knowledge assessment instruments.

Front 15

Cause-Effect
Graphing

Back 15

A tool used to derive test cases from specifications. A graph
that relates causes (or input conditions) to effects is generated.
The information in the graph is converted into a decision table
where the columns are the cause-effect combinations. Unique
rows represent test cases.

Front 16

Certificant

Back 16

An individual who has earned a credential awarded through a
certification program.

Front 17

Certification

Back 17

A voluntary process instituted by a nongovernmental agency by
which individual applicants are recognized for having achieved
a measurable level of skill or knowledge. Measurement of the
skill or knowledge makes certification more restrictive than
simple registration, but much less restrictive than formal
licensure.

Front 18

Checklists

Back 18

A series of probing questions about the completeness and
attributes of an application system. Well-constructed checklists
cause evaluation of areas, which are prone to problems. It both
limits the scope of the test and directs the tester to the areas in
which there is a high probability of a problem.

Front 19

Checkpoint Review

Back 19

Held at predefined points in the development process to
evaluate whether certain quality factors (critical success
factors) are being adequately addressed in the system being
built. Independent experts for the purpose of identifying
problems conduct the reviews as early as possible.

Front 20

Checksheet

Back 20

A form used to record data as it is gathered.

Front 21

Client

Back 21

The customer that pays for the product received and receives
the benefit from the use of the product.

Front 22

Coaching

Back 22

Providing advice and encouragement to an individual or
individuals to promote a desired behavior.

Front 23

Code Comparison

Back 23

One version of source or object code is compared to a second
version. The objective is to identify those portions of computer
programs that have been changed. The technique is used to
identify those segments of an application program that have
been altered as a result of a program change.

Front 24

Compiler-Based
Analysis

Back 24

Most compilers for programming languages include diagnostics
that identify potential program structure flaws. Many of these
diagnostics are warning messages requiring the programmer to
conduct additional investigation to determine whether or not the
problem is real. Problems may include syntax problems,
command violations, or variable/data reference problems.
These diagnostic messages are a useful means of detecting
program problems, and should be used by the programmer.

Front 25

Complete Test Set

Back 25

A test set containing data that causes each element of prespecified
set of Boolean conditions to be true. In addition, each
element of the test set causes at least one condition to be true.

Front 26

Completeness

Back 26

The property that all necessary parts of an entity are included.
Often, a product is said to be complete if it has met all
requirements.

Front 27

Complexity-Based
Analysis

Back 27

Based upon applying mathematical graph theory to programs
and preliminary design language specification (PDLs) to
determine a unit's complexity. This analysis can be used to
measure and control complexity when maintainability is a
desired attribute. It can also be used to estimate test effort
required and identify paths that must be tested.

Front 28

Compliance Checkers

Back 28

A parse program looking for violations of company standards.
Statements that contain violations are flagged. Company
standards are rules that can be added, changed, and deleted
as needed.

Front 29

Condition Coverage

Back 29

A white-box testing technique that measures the number of, or
percentage of, decision outcomes covered by the test cases
designed. 100% condition coverage would indicate that every
possible outcome of each decision had been executed at least
once during testing.

Front 30

Configuration
Management Tools

Back 30

Tools that are used to keep track of changes made to systems
and all related artifacts. These are also known as version
control tools.

Front 31

Configuration Testing

Back 31

Testing of an application on all supported hardware and
software platforms. This may include various combinations of
hardware types, configuration settings, and software versions.

Front 32

Consistency

Back 32

The property of logical coherence among constituent parts.
Consistency can also be expressed as adherence to a given
set of rules.

Front 33

Consistent Condition
Set

Back 33

A set of Boolean conditions such that complete test sets for the
conditions uncover the same errors.

Front 34

Control Flow Analysis

Back 34

Based upon graphical representation of the program process.
In control flow analysis, the program graph has nodes, which
represent a statement or segment possibly ending in an
unresolved branch. The graph illustrates the flow of program
control from one segment to another as illustrated through
branches. The objective of control flow analysis is to determine
potential problems in logic branches that might result in a loop
condition or improper processing.

Front 35

Conversion Testing

Back 35

Validates the effectiveness of data conversion processes,
including field-to-field mapping, and data translation.

Front 36

Correctness

Back 36

The extent to which software is free from design and coding
defects (i.e., fault-free). It is also the extent to which software
meets its specified requirements and user objectives.

Front 37

Cost of Quality (COQ)

Back 37

Money spent beyond expected production costs (labor,
materials, equipment) to ensure that the product the customer
receives is a quality (defect free) product. The Cost of Quality
includes prevention, appraisal, and correction or repair costs.

Front 38

Coverage-Based
Analysis

Back 38

A metric used to show the logic covered during a test session,
providing insight to the extent of testing. The simplest metric for
coverage would be the number of computer statements
executed during the test compared to the total number of
statements in the program. To completely test the program
structure, the test data chosen should cause the execution of
all paths. Since this is not generally possible outside of unit
test, general metrics have been developed which give a
measure of the quality of test data based on the proximity to
this ideal coverage. The metrics should take into consideration
the existence of infeasible paths, which are those paths in the
program that have been designed so that no data will cause the
execution of those paths.

Front 39

Customer

Back 39

The individual or organization, internal or external to the
producing organization that receives the product.

Front 40

Cyclomatic Complexity

Back 40

The number of decision statements, plus one.

Front 41

Data Dictionary

Back 41

Provides the capability to create test data to test validation for
the defined data elements. The test data generated is based
upon the attributes defined for each data element. The test
data will check both the normal variables for each data element
as well as abnormal or error conditions for each data element.

Front 42

DD (Decision-to-
Decision) Path

Back 42

A path of logical code sequence that begins at a decision
statement or an entry and ends at a decision statement or an
exit.

Front 43

Debugging

Back 43

The process of analyzing and correcting syntactic, logic, and
other errors identified during testing.

Front 44

Decision Coverage

Back 44

A white-box testing technique that measures the number of, or
percentage of, decision directions executed by the test case
designed. 100% decision coverage would indicate that all
decision directions had been executed at least once during
testing. Alternatively, each logical path through the program
can be tested. Often, paths through the program are grouped
into a finite set of classes, and one path from each class is
tested.

Front 45

Decision Table

Back 45

A tool for documenting the unique combinations of conditions
and associated results in order to derive unique test cases for
validation testing.

Front 46

Defect
- From Customer's viewpoint
- From Producer's viewpoint

Back 46

Operationally, it is useful to work with two definitions of a
defect:
• From the producer's viewpoint a defect is a product
requirement that has not been met or a product attribute
possessed by a product or a function performed by a
product that is not in the statement of requirements that
define the product;
• From the customer's viewpoint a defect is anything that
causes customer dissatisfaction, whether in the statement
of requirements or not.

Front 47

Defect Tracking Tools

Back 47

Tools for documenting defects as they are found during testing
and for tracking their status through to resolution.

Front 48

Design Level

Back 48

The design decomposition of the software item (e.g., system,
subsystem, program, or module).

Front 49

Desk Checking

Back 49

The most traditional means for analyzing a system or a
program. Desk checking is conducted by the developer of a
system or program. The process involves reviewing the
complete product to ensure that it is structurally sound and that
the standards and requirements have been met. This tool can
also be used on artifacts created during analysis and design.

Front 50

Driver

Back 50

Code that sets up an environment and calls a module for test.

Front 51

Dynamic Analysis

Back 51

Analysis performed by executing the program code. Dynamic
analysis executes or simulates a development phase product,
and it detects errors by analyzing the response of a product to
sets of input data.

Front 52

Dynamic Assertion

Back 52

A dynamic analysis technique that inserts into the program
code assertions about the relationship between program
variables. The truth of the assertions is determined as the
program executes.

Front 53

Empowerment

Back 53

Giving people the knowledge, skills, and authority to act within
their area of expertise to do the work and improve the process.

Front 54

Entrance Criteria

Back 54

Required conditions and standards for work product quality that
must be present or met for entry into the next stage of the
software development process.

Front 55

Equivalence
Partitioning

Back 55

The input domain of a system is partitioned into classes of
representative values so that the number of test cases can be
limited to one-per-class, which represents the minimum
number of test cases that must be executed.

Front 56

Error or Defect

Back 56

A discrepancy between a computed, observed, or measured
value or condition and the true, specified, or theoretically
correct value or condition.
Human action that results in software containing a fault (e.g.,
omission or misinterpretation of user requirements in a
software specification, incorrect translation, or omission of a
requirement in the design specification).