Software Testing Glossary of Terms

Acceptance Criteria

The
definition of the results is expected from the test cases used for
acceptance testing. The product must meet these criteria before
implementation can be approved.

Acceptance Testing

Formal
testing conducted to determine wheter or not a system or component
satisfies its acceptance criteria and to enable the client to determine
wheter or not to accept that system or component.

Acceptance Test Plan

Describes
the steps the client will use to verify that theconstructed system
meets the acceptance criteria. It defines the approach to be taken for
acceptance testing activities. The plan identifies the items to be
tested, the test objectives, the acceptance criteria, the testing to be
performed, test schedules, entry/exit criteria, staff requirements,
reporting requirements, evaluation criteria, and any risks requiring
contingency planning.

Ad Hoc Testing

Goal oriented passing through the product. Sometimes to prove or
disprove a notion of how the product will behave. A loosely structured
testing approach that allows test developers to be creative in their
test selection and execution. Ad-hoc testing is targeted as known or
suspected problem areas.
 

Alpha Test

The
part of the Test Phase of the PLC where code is complete and the
product has achieved a degree of stability. The product is fully
testable (determined by QA). All functionality has been implemented and
QA has finished the implementation of the test plans/cases. Ideally,
this when development feels the product is ready to be shipped.

Audit and Controls Testing

A functional type of test that verifies the adequacy and effectiveness of controlsand completeness of data processing results.

Auditability

A test focus area defined as the ability to provide supporting evidence to trace processing of data.

Automated Testing

Creation of individual tests created to run without direct tester intervention.

Backup and Recovery Testing

A structural type of test that verifies the capability of the application to be restarted after a failure.

BCS ISEB

British Computer Society Information Systems Examination Board

Beta Test

The
part of the Test Phase of the PLC where integration testing plans are
finished, depth testing coverage goals met; Ideally, QA says product is
ready to ship. The product is stable enough for external testing
(determined by QA).

Black Box Test

Tests in
which the software under test is treated as a black box. You can't "see" into it. The test provides inputs and
responds to outputs without considering how the software works.

Bottom-up Testing

Approach to integration testing where the lowest level components
are tested first then used to facilitate the testing of higher level
components. This process is repeated until the component at the top of
the heirachy is tested. See "Top-down".
 

Boundary Testing

Test which focus on the boundary or limit conditions of the software being tested. (Some of these tests are stress tests).

Boundary Value Analysis

A test case selection technique that selects test data that lie
among "boundaries" or extremes among input and output possibilities.
Boundary Value Analysis can apply to parameters, classes, data
structures, variables, loops, etc.

Branch Testing

A white box testing technique that requires each branch or decision point to be taken once.

Breadth Testing

Matrix
tests which generally cover all product components and functions on an
individual basis. These are usually the first automated tests available
after the functional specifications have been completed and test plans
have been drafted.
 

Breath Testing

Generally a
good thing to do after eating garlic and before going out into public.
Or you may have to take a breath test if you're DUI.

Build

(1) An operational version of a system or component that
incorporates a specified subset of the capabilites that the final
product will provide. Builds are defined whenever the complete system
cannot be developed and delivered in a single increment.
(2) A
collection of programs within a system that are functionally
independent. A build can be tested as a unit and can be installed
independent of the rest of the system.

Bug

A phenomenon with an understanding of why it happened.

Business Function

A set of related activities that compromise a stand-alone unit of
business. It may be defined as a process that results in the
achievement of a business objective. It is characterised by
well-defined start and finish activities and a workflow or pattern.

Capability Mature Model (CMM)

A model of the stages through which software organisations progress
as they define, implement, evolve, and improve their software process.
This model provides a guide for selecting process improvement
strategies by determining current process capabilities and identifying
the issues most critical to software quality and process improvement.
This concept was developed by the Software Engineering Institute (SEI)
at Carnegie Mellon University.

Casual Analysis

The evaluation of the cause of major errors, to determine actions that will prevent reoccurence of similar errors.

Change Control

The process, by which a change is proposed, evaluated, approved or rejected, scheduled, and tracked. 

Change Management

A process methodology to identify the configuration of a release and
to manage all changes through change control, data recording, and
updating of baselines.

Change Request

A documented proposal for change of one or more work items or work item parts.

Code Complete

Phase of the PLC where functionality is coded in entirety; bug fixes are all that are left. All functions found in the Functiona
l Specifications have been implemented.
 

Code Freeze

When development has finished all new functional code. This is when development is in a "bug fixing" stage.
 

Coding Phase

Phase
of the PLC where development is coding product to meet
Functional/Architectural Specifications. QA develops test tools and
test cases during this phase.
 

Compatibility Test

Tests that check for compatibility of other software or hardware with the software being tested.

Component Testing

The first level of dynamic testing and is the verification of new or
changed code in an individual component (module, program, object, etc.)
to determine whether all new and/or modified logic functions correctly.
Also known as Unit testing.

Concept Phase

Phase
of the PLC where an idea for a new product is developed and a
preliminary definition of the product is established. Research plans
should be put in place and an initial analysis of the competition
should be completed. The main goal of this phase is to determine
product viability and obtain funding for further research.

Condition Testing

A white box test method that requires all decision conditons be executed once for true and once for false.

Configuration Management

(1) The process of identifying and defining the configuration items
in a system, controlling the release and change of these items
throughout the system life cycle, recording and reporting the status of
configuration items and change requests, and verifying the completeness
and correctness of configuration items.
(2) A discipline applying
technical and administrative direction and surveillance to (a) identify
and document the functional and physical characteristics of a
configuration items, (b) control changes to those characteristics, and
(c) record and report change processing and implementation status.

Conversion Testing

A functionaltype of test that verifies the compatability of
converted programs, data and procedures with the "old" ones that are
being converted or replaced. Also known as Migration Testing. 

Coverage

The extent to which tests exercise a program's functions,
parameters, inputs, paths, branches, statements, conditions, modules or
data flow paths.

Coverage Matrix

Documentation procedure to indicate the testing coverage of test
cases compared to possible elements of a program environment (i.e.
inputs, outputs, parameters, paths, cause-effects, equivalence
partitioning, etc.)

Continuity of Processing

A test focus area defined as the ability to continue processing if
problems occur. Included is the ability to backup and recover after a
failure.

Correctness

A test focus area defined as the ability to process data
according to prescribed rules. Controls over transactions and data
field edits provide an assurance on accuracy and completeness of
data. 

Coverage Analysis

Shows which functions (i.e., GUI and C code level) have been touched and which have not.
 

CSV’s

The
comma-separated values (or CSV; also known as a comma-separated list or
comma-separated variables) file format is a file type that stores
tabular data. The format dates back to the early days of business
computing. For this reason, CSV files are common on all computer
platforms.

CSV is one implementation of a delimited text file,
which uses a comma to separate values (where many implementations of
CSV import/export tools allow an alternate separator to be used; as is
shown in the MS Access screen shot, below). However CSV differs from
other delimiter separated file formats in using a " (double quote)
character around fields that contain reserved characters (such as
commas or newlines). Most other delimiter formats either use an escape
character such as a backslash, or have no support for reserved
characters.

In computer science terms, this type of format is
called a "flat file" because only one table can be stored in a CSV
file. Most systems use a series of tables to store their information,
which must be "flattened" into a single table, often with information
repeated over several rows, to create a delimited text file.

Data Flow Testing

Testing in which test cases are designed basedon variable usage within the code 

Data Swapping

A
disclosure control method for microdata that involves swapping the
values of variables for records that match on a representative key.
 In the literature this technique is also sometimes referred to as
multidimensional transformation.  It is a transformation technique
that guarantees (under certain conditions) that the maintenance of a
set of statistics, such as means, variances and univariate
distributions.

 

Data Validation

Verification of data to assure that it is still correct.

Date shifted

For date dependant applications.
 

DB2

DB2
is IBM's brand name for their database products. Each platform supports
a slightly different set of features from the others.

DCC

Data and Communications Centre
 

Debug

To search for and eliminate malfunctioning elements or errors in the software.

Decision Coverage

Percentage of decision outcomes that have been exercised through (white box) testing.

Defect

See Fault.

Defect Management

A set of processes to manage the tracking and fixing of defects found during testing and to perform casual analysis.

Definition Phase

See Design Phase.
 

Dependency

This
is when a component of a product is dependent on an outside group. The
delivery of the product or the reaching a certain milestone is affected.
 

Depth Testing

Encompasses Integration testing, real world testing, combinatorial testing, I
nteroperability and compatibility testing.
 

Design Phase

Phase
of the PLC where functions of the product are written down. Features
and requirements are defined in this phase. Each department develops
their departments' plan and resource requirements for the product
during this phase.

Design Review

(1) A formal meeting at which the preliminary or detailed design of
a system is presented to the user, customer or other interested parties
for comment and approval.
(2) The formal review of an existing or
proposed design for the purpose of detection and remedy of design
deficiencies that could attract fitness-for-use and environmental
aspects of the product, process or service, and/or for identification
of potential improvements of performance, safety and economic aspects.

Desk Check

Testing of software by the manual simulation of its execution. It is one of the static testing techniques.

Detailed Test Plan

The detailed plan for a specific level of dynamic testing. It
defines what is to be tested and how it is to be tested. The plan
typically identifies the items to be tested, the test objectives, the
testing to be performed, test schedules, personnel requirements,
reporting requirements, evaluation criteria, and any risks requiring
contingency planning. It also includes the testing tools and
techniques, test environment set up, entry and exit criteria, and
administrative procedures and controls. 

Documentation and Procedures Testing

A functional type of test that verifies that the interface between
the system and the people works and is usable. It also verifies that
the instruction guides are helpful and accurate.

Dot Release

A major update to a product.

Driver

A program that exercises a system or system component by simulating
the activity of a higher level component. Will either form a Test
Harness, or be part of one.

Dynamic Testing

Testing that is carried out by executing the code. Dynamic testing
is a means of validating a work product by observing its behaviour in
response to inputs.
 

End To End Testing and System Testing

Putting the components together and making sure they work.

Entry Criteria

A checklist of activities or work items that must be complete or
exist, respectively, before the start of a given task within an
activity or sub-activity.

Environment

See Test Environment.

Equivalence Partitioning

Portion of the component's input or output domains for which the
component's behaviour should be the same according to its
specification. 

Error

(1) A discrepancy between a computed, observed or measured value or
condition and the true specified or theoretically correct value or
condition.
(2) A human action that results in software containing a
fault. This includes omissions or misinterpretations, etc. See Variance.

Error Guessing

A test case selection process that identifies test cases based on
knowledge and ability of the individual to anticipate problem errors.

Execution Procedure

A sequence of manual or automated steps required to carry out part
of or all of a test design or execute a set of test cases. 

Exit Criteria

(1) Actions that must happen before an activity is considered complete.
(2)
A checklist of activities or work items that must be complete or exist,
respectively, prior to the end of a given process stage, activity, or
sub-activity.

Expected Results

Predicted output data and file conditions associated with a
particular test case. Expected results, if achieved, will indicate
whether the test was successful or not. Generated and documented with
the test case prior to execution of the test.

Failure

Deviation of the software from its expected delivery or servicev (BS 7925-1, after Fenton).

Fault

A manifestation of an error in software. A fault if encountered may cause a failure. Also known as defect, or bug. 

Feature

A bug that no one wants to admit to.
 

Flat files

A
flat file is a file that contains records, and in which each record is
specified in a single line. Fields from each record may simply have a
fixed width with padding, or may be delimited by whitespace, tabs,
commas (CSV) or other characters. Extra formatting may be needed to
avoid delimiter collision. There are no structural relationships. The
data are "flat" as in a she
et of paper, in contrast to more complex models such as arelational
database.

The
classic example of a flat file database is a basic name-and-address
list, where the database consists of a small, fixed number of fields:
Name, Address, and Phone Number. Another example is a simple HTML
table, consisting of rows and columns. This type of database is
routinely encountered, although often not expressly recognized as a
database.

Focus

The center of interest or activity. In software, focus refers to the area of the screen where the insertion point is active.

Full Lifestyle Testing

The process of verifying the consistency, completeness, and
correctness of software and related work products (such as documents
and processes) at each stage of the development life cycle.

Function

(1) A specific purpose of an entity or its characteristic action. 
(2) A set of related control statements that perform a related operation. Functions are sub-units of modules.

Function Testing

A functional type of test, which verifies that each business
function operates according to the detailed requirements, the external
and internal design specifications.

Functional

Phase of the PLC defining modules.

Functional Testing

All
of these have to be across different versions - that would be across
development, production, system testing, and repair and all of these
then have new releases.

Functional Testing Types 

Those kinds of test used to assure that the system meets the
business requirements, including business functions, interfaces,
usability, audit & controls, and error handling etc. See also
Structural Test Types
 

Global Recoding 

Problems of confidentiality can be tackled by changing the structure
of data. Thus, rows or columns in tables can be combined into larger
class intervals or new groupings of characteristics.  This may be
a simpler solution than the suppression of individual items, but it
tends to reduce the descriptive and analytical value of the table.
 This protection technique may also be used to protect
microdata.  

GM

See Green Master.

Green Master (GM)

Phase of the PLC where the certification stage begins.
All bugs, regressed against the product, must pass. Every build is a release candidate (determined by development).
 

GUI

Graphical User Interface.

IEEE

Institute for Electrical and Electronical Engineering

Implementation

(1) A realisation of an abstraction in more concrete terms; in particular, in terms of hardware, software, or both.
(2) The process by which a software release is installed in production and made available to end users.

Incident

An incident is an event which occurs during testing that requires
subsequent investigation or correction. Usually, the event is a
mismatch between the actual and expected results of a test. The cause
can be one of a number of things:

- a defect in the software

- a fault in the test e.g. expected result was wrong

- the environment was wrong

- the test was run incorrectly e.g. enteredthe wrong input

- a documentation or specification fault i.e. the specification is wrong

Inline

Phase
of the PLC after shipping (STM) where bugs are fixed for interim
release. Maintenance of the product involves cleaning up bugs that are
found after STM. Inlines are created to address these problems.

Inspection

(1) A group review quality improvement process for written material,
consisting of two aspects: product (document itself) improvement and
process improvement (of both document production and inspection).
(2)
A formal evaluation technique in which software requirements, design,
or code are examined in detail by a person or group other than the
author to detect faults, violations of devolpment standards, and other
problems. Contrast with walk-through. 

Installation Testing

A non-functional type of test which verifies that the hardware,
software and applications can be easily installed and run in the target
environment.

Integration Testing

Depth testing which covers groups of functions at the subsystem level.
 

Interoperability Test

Tests that verify operability between software and hardware.

IT

Information Technology

JAD

An acronym for Joint Application Design. Formal session(s) involving
clients and developers used to develop and document consensus on work
products, such as client requirements, design specifications, etc.

Level of Testing

Refers to the progression of software testing through static and dynamic testing. 
Examples
of static testing levels are: Project Objectives Review, Requirements
Walkthrough, Design (External and Internal) Review, and Code
Inspection. 
Examples of dynamic testing levels are: Unit
Testing, Integration Testing, System Testing, Acceptance Testing,
Systems Integration Testing and Operability Testing.
Also known as test level.

Lifecycle

The software development process stages. Requirements, Design, Construction (Code/Program, Test), and Implementation.

Link Testing

A level of dynamic testing which verifies that individual components
of an application or sub-system will communicate satisfactorily with
one another; does not require that the application under test interface
with other applications. Also known as Small-scale Integration Testing,
or String testing.
 

Load Test

Load
tests study the behavior of the program when it is working at its
limits. Types of load tests are Volume tests, Stress tests, and Storage
tests.
 

Localization

This term refers to making software specifically designed for a specific locality.

Logical Path

A path that begins at an entry or decision statement and ends at a decision statement or exit.

Maintainability

A test focus area defined as the ability to locate and fix an error
in the system. Can also be the ability to make dynamic changes to the
system environment without making system changes.

Maintenance Release

See Inline.

Master Test Plan

A plan that addresses testing from a high-level system viewpoint. It
ties togetherall levels of testing (unit test, integration test, system
test, acceptance test, systems integration, and operability). It
includes test objectives, test team organisation and responsibilities,
high-level schedule, test scope, test focus, test levels and types,
test facility requirements, and test management procedures and
controls. 

Metadata

Metadata
is data about data. An item of metadata may describe an individual
datum, or content item, or a collection of data including multiple
content items.

Metadata (sometimes written 'meta data') is used
to facilitate the understanding, use and management of data. The
metadata required for effective data management varies with the type of
data and context of use. In a library, where the data is the content of
the titles stocked, metadata about a title would typically include a
description of the content, the author, the publication date and the
physical location. In the context of a camera, where the data is the
photographic image, metadata would typically include the date the
photograph was taken and details of the camera settings. On a portable
music player such as an Apple iPod, the album names, song titles and
album art embedded in the music files are used to generate the artist
and song listings, and are metadata. In the context of an information
system, where the data is the content of the computer files, metadata
about an individual data item would typically include the name of the
field and its length. Metadata about a collection of data items, a
computer file, might typically include the name of the file, the type
of file and the name of the data administrator.
 

Metrics

A
standard of measurement. Software metrics are the statistics describing
the structure or content of a program. A metric should be a real
objective measurement of something such as number of bugs per lines of
code.

Microaggregation

Records
are grouped based on a proximity measure of variables of interest, and
the same small groups of records are used in calculating aggregates for
those variables.  The aggregates are released instead of the
individual record values.

Milestones

Events in the Product Life Cycle which define particular goals.

MS

Microsoft Corporation

MTP

Master Test Plan

Negative Testing

A functional type of test that verifies that the system does not do
anything other than those things which it is supposed to do. As a
by-product, this will exercise the system function for detecting and
responding to execption conditions, thus verifying that incorrect
transactions are properly handled.

NF

Non - Functional

NFR

Non - Functional Requirements
 

OAT

Operational Acceptance Testing

OLAP (on-line analytical processing)

This
was a term coined by E.F. Codd & Associates who published a white
paper in 1994, commissioned by Arbor Software (now Hyperion Solutions),
entitled ‘Providing OLAP (On-line Analytical Processing) to
User-Analysts: An IT Mandate’.

OLAP stands for ‘On-Line
Analytical Pr
ocessing’. But that is not only not a definition, it’s not even a clear
description of what OLAP means. It certainly gives no indication of why
you would want to use an OLAP tool, or even what an OLAP tool actually
does. And it gives you no help in deciding if a product is an OLAP tool
or not.

Online
Analytical Processing, or OLAP (IPA), is an approach to quickly provide
answers to analytical queries that are multidimensional in nature. OLAP
is part of the broader category business intelligence, which also
includes Extract transform load (ETL), relational reporting and data
mining.

The typical applications of OLAP are in business
reporting for sales, marketing, management reporting, business process
management (BPM), budgeting and forecasting, financial reporting and
similar areas. The term OLAP was created as a slight modification of
the traditional database term OLTP (Online Transaction Processing).

Databases configured for OLAP employ a multidimensional data mod
el, allowing for complex analytical and ad-hoc queries with a rapid execution time.

Nigel
Pendse has suggested that an alternative and perhaps more descriptive
term to describe the concept of OLAP is Fast Analysis of Shared
Multidimensional Information (FASMI). They borrow aspects of
navigational databases and hierarchical databases that are speedier
than their relational kin.

The output of an OLAP query is
typically displayed in a matrix (or pivot) format. The dimensions form
the row and column of the matrix; the measures, the values.
 

Offsite Development

Sometimes sending your work off shore.

Operability

A test focus area defined as the effort required (of support
personnel) to learn and operate a manual or automated system. Contrast
with Usability.
 

Operability Testing

A type of dynamic testing in which the operations of the system are
validated in the real or closely simulated production environment. This
includes verification of production JCL, installation procedures and
operations procedures. Operability Testing considers such factors as
resource consumption and adherence to standards. It is normally
performed by Operations to assess the readiness of the system for the
implementation in the production environment.

Parallel Testing

A functional type of test, which verifies that the same input to "old" and "new" systems produces the same results.

Path Testing

A white box testing technique that requires all code or logic paths
to be executed once. Complete path testing is usually impractical and
often uneconomical.

Performance

A test focus area defined as the ability of the system to perform certain functions within a prescribed time.

Performance Test

Test that measures how long it takes to do a function.

Performance Testing

A structural type of test which verifies that the application meets
the expected level of performance in a production-like environment.
 

Portability

A test focus area defined as ability for a system to operate in multiple operating environments.

Phenomenon

A flaw without an understanding.
 

PLC

Product Life Cycle - see Software Product Life Cycle.
 

Pre-Alpha

Pre-build 1; product definition phase. (Functional Specification may still be in proces
s of being created).
 

Problem

(1) A call or report from a user. The call or report may or may not be defect orientated.
(2) A software or process deficiency found during development. 
(3) The inhibitors and other factors that hinder an organisation's ability to achieve its goals and critical success factors.
(4) An issue that a project manager has the authority to resolve without escalation. Compare to 'defect' or 'error'.

Product Life Cycle(PLC)

The
stages a product goes through from conception to completion. Phases of
product development includes: Definition Phase,
Functional/Architectural Specification Phase, Coding Phase, Code
Complete Phase, Alpha, Beta, Zero Bug Build Phase, Green Master Phase,
STM, and Maintenance/Inline Phase.
 

Proposal Phase

Phase of the PLC where the product must be defined with a prioritized feature list and system and compatibility requirements.

QA Plan

A
general test plan given at the macro level which defines the activities
of the test team through the stages of the Product Life Cycle.

Quality Plan

A document which decribes the organisation, activities, and project
factors that have been put in place to achieve the target level of
quality for all work products in the application domain. It defines the
approach to be taken when planning and tracking the quality of
application development work products to ensure conformance to
specified requirements and to ensure the client's expectations are
met. 

Real World Testing

Integration testing which attempt to create environments which mirror how the product will be used in the "real world".

Regression Testing

Retesting
bugs in the system which had been identified as fixed, usually starting
from Alpha on. Test
ing is focussed on making sure none of the existing functionality has
been broken by the new applications, this is often the final phase of
the testing that is automated.

Reliability

A test focus area defined as the extent to which the system will provide the intended function without failing. 
 

Requirement

(1) A condition or capability needed by the user to solve a problem or achieve an objective.
(2) A condition or capacbility that must be met or possesed by a system or system component to satisfy a contract, standard,
specification, or other formally imposed document. The set of all
requirements forms the basis for subsequent development of the system
or system component.

Resource

People, software, hardware, tools, etc. that have unique qualities and talents that can be utilized for a purpose.
 

Risk

Something that could potentially contribute to failing to reach a milestone.

Review

A process or meeting during which a work product, or set of
work products, is presented to project personnel, managers, users or
other interested parties for comment or approval.
 

Root Cause Analysis

See Causal Analysis.

Scaffolding

See Test Harness.

Schema

The
structure of a database system, described in a formal language
supported by the database management system (DBMS). In a relational
database, the schema defines the tables, the fields in each table, and
the relationships between fields and tables.

Schemas are
generally stored in a data dictionary. Although a schema is defined in
text database language, the term is often used to refer to a graphical
depiction of the database structure.

SD

Service Delivery.
 

Security

A test focus area defined as the assurance that the system/data
resources will be protected against accidental and/or intentional
modification or misuse.

Security Testing

A test which verifies that the application provides an adeqaute
level of protection for confidential information and data belonging to
other systems.

Software Quality

(1) The totatily of features and characteristics of a software
product that bear on its ability to satisfy given needs; for example,
conform to specifications. 
(2) The degree to which software posseses a desired combination of attributes.
(3) The degree to which a customer or user perceives that software meets his or her composite expectations.
(4)
The composite characteristics of software that determine the degree to
which the software in use will meet the expectations of the customer.

Software Reliability

(1) The probability that software will not cause the failure of a
system for a specified time under specified conditions. The probability
is a function of the inputs to and use of the system as well as a
function of the existence of faults in the software. The inputs to the
system determine whether existing faults, if any, are encountered.
(2) The ability of a program to perform a required function under stated conditions for a stated period of time.

Specifications

Their implementation requirements and approach, and exposed API. Eac
h function is specified here. This includes the expected results of each function.

Statement Testing

A white box testing technique that requiresall code or logic statements to be executed at least once.
 

Static Testing

(1) The detailed examination of a work product's
characteristics to an expected set of attributes, experiences and
standards. The product under scrutiny is static and not exercised and
therefore its behaviour to changing inputs and environments cannot be
assessed.
(2) The process of evaluating a program without executing the program. See also desk checking, inspection, walk-through.

STM

See Ship To Manufacturing.
 

Storage Tests

Test how memory and space is used by the program, either in resident memory or on disk.
 

Stress Test

Determining
the durability of a system by pushing it to its limits. Software stress
testing is done by feeding the program erroneous data as well as
activating all interface options in all possible sequences.

Structural Function

Structural functions describe the technical attributes of a system.
 

Structural Testing

Evaluation techniques that are executed with the knowledge of the
structure of the product under test. At component level, the objective
of structural testing is to test the component's statements, code
paths, conditions, or data flow paths at the level of technical design
and implementation. At higher levels, some non-funcational tests may be
structural in nature e.g. performance and security tests. Also known as
White Box Testing or Glass Box Testing.

Stub

(1) A dummy program element or module used during the development and testing of a higher level element or module.
(2)
A program statement substituting for the body of a program unit and
indicating that the unit is or will be defined elsewhere.
The inverse of a Test Harness

Syncopated Test

A test that works in harmony with other tests. The timing is such that both tests work together, but yet independently.
 

System

A collection of components organised to accomlplish a specific function or a det of functions.

System Integration Testing

A dynamic level of testing which verifies that the application or
sub-system under test integrates satisfactorily with its target
infrastructure platforms and with the other applications/sub-systems
with which it should interface. Also known as Large-scale Integration
Testing, or Interface Testing.

System Testing

A dynamic level of testing in which all the components thay
compromise a system are tested to verify that the system functions
together as a whole. 

Test Bed

(1) A test environment containing the hardware, instrumental tools,
simulators, and other support software necessary for testing a system
or system component.
(2) A set of test files, (including databases
and reference files), in a known state, used with input test data to
test one or more test conditions, measuring against expected results.

Test Case

(1) A set of test inputs, execution conditions, and expected results
developed for a particular objective, such as to exercise a particular
program path ot to verify compliance with a specified requirement.
(2) The detailed objectives, data, procedures, and expected results to conduct a test or part of a test.

Test Condition

A functional or structural attribute of an application, system, network, or component thereof to be tested.
 

Test Conditions Coverage Matrix

A worksheet that is used for planning and for illustrating that all
test conditions are covered by one or more test cases. Each test set
has a Test Conditions Coverage Matrix. Rows are used to list the test
conditions and columns are used to list all test cases in the test set.

Test Conditions Matrix

A worksheet usedto formulate the test conditions that, if met, will
produce the expected result. It is a tool used to assist in the design
of test cases.

Test Coverage Matrix

A worksheet used to plan and cross check to ensure all requirements and functions are covered adequately by test cases.

Test Data

The input data and file conditions associated with a specific test case.

Test Environment

The external conditions or factors that can directly or indirectly
influence the execution and results of a test. This includes the
physical as well as operational environments. Examples of what is
included in a test environment are: I/O and storage devices, data
files, programs, JCL, communication lines, access control and security,
databases, reference tables and files (version controlled), etc.

Test Focus Areas

Those attributes of an application that must be tested in order to
assure that the business and structural requirements are satisfied.

Test Harness 

A program provided specifically to aid in the testing of another
component or sub-system in isolation, by simulating the environment in
which it will execute (e.g. by creating input messages for it). Also
known as Scaffolding.

Test Level

See Level of Testing.

Test Log

A chronological record of all relevant details of a testing activity.

Test Matrices

A collection of tables and matrices used to relate functions to be
tested with the test cases that do so. Worksheets used to assist in the
design and verification of test cases.

Test Objectives

The tangible goals for assuring that the Test Focus areas previously
selected as being relevant to a particular Business or Structural
Function are being validated by the test.

Test Phase

Phase
of the PLC where the entire product is tested, both internally and
externally. Alpha and Beta Tests occur during this phase.
 

Test Plan

A specific plan that breakdown testing approaches on a functional
area basis. The plan typically identifies the items to be tested, the
test objectives, the testing to be performed, test schedules,
entry/exit criteria, personnel requirements, reporting requirements,
evaluation criteria, and any risks requiring contingency planning. 

Test Procedure

Detailed instructions for the set-up, operation, and evaluation of
results for a given test. "A document providing detailed instructions
for the execution of one or more test cases" [BS7925-1]
 

Test Report

A document describing the conduct and results of the testing carried out for a system or system component.

Test Run

A dated, time-stamped execution of a set of test cases.

Test Scenario

A high-level description of how a given business or technical
requirement will be tested, including the expected outcome; later
decomposed into sets of test conditions, each in turn, containing test
cases.

Test Script

A sequence of actions that executes a test case. Previously
synonymous with Test Procedure, but now has specialised use in
automated testing. One or more test scripts may be part of a Test
Procedure. 

Test Set

A collection of test consitions. Test sets are created for purposes
of test execution only. A test set is created such that its size is
manageable to run and its grouping of test conditions facilitates
testing. The grouping reflects the application build strategy.

Test Sets Matrix

A worksheet that relates the test conditions to the test set in
which the condition is to be tested. Rows list the test conditions and
columns list the test sets. A checkmark in a cell indicated the test
set will be used for the corresponding test condition.

Test Specification

A set of documents that define and describe the actual test
architecture, elements, approach, data and expected results. Test
Specification uses the various functional and non-functional
requirement documents along with the quality and test plans. It
provides the complete set of test cases and all supporting detail to
achieve the objectives documented in the detailed test plan.

Test Strategy

A high level description of major system-wide activities which
collectively achieve the overall desired result as expressed by the
testing objectives, given the constraints of time and money and the
target level of quality. It outlines the approach to be used to ensure
that the critical attributes of the system are tested adequately.

Test Suite

A set of test cases.

Test Type

See Type of Testing.
 

Testability

(1) The extent to which software facilitates both the establishment
of test criteria and the evaluation of the software with respect to
those criteria.
(2) The extent to which the definition of requirements facilitates analysis of the requirements to establish test criteria.

Testing

The process of exercising or evaluating a program, product, or
system, by manual or automated means, to verify that it satisfies
specified requirements, to identify differences between expected and
actual results.

Testware

The elements that are produced as part of the testing process.
Testware includes plans, designs, test cases, test logs, test reports,
etc.

Top-down

Approach to integration testing where the component at the top of
the component hierachy is tested first, with lower level components
being simulated by stubs. Tested components are then used to test lower
level components. The process is repeated until the lowest level
components have been tested.

Top and bottom coding

It
consists in setting top-codes or bottom-codes on quantitative
variables.  A top-code for a variable is an upper limit on all
published values of that variable.  Any value greater than this
upper limit is replaced by the upper limit or is not published on the
microdata file at all.  Similarly, a bottom-code is a lower limit
on all published values for a variable.  Different limits may be
used for different quantitative variables, or for different
subpopulations.

Transaction Flow Testing

A functional type of test that verifies the proper and complete
processing of a transaction from the time it enters the system to the
time ofits completion or exit from the system.

TS

Technology Solutions

Type of Testing

Tests a functional or structural attribute of the system. E.g. Error Handling, Usability. Also known as test type.

Unit Testing

See Component Testing.

Usability

The degree to which the intended target users can accomplish their intended goals.

Usability Testing

(1) A functional type of test which verifies that the final product is user-friendly and easy to use.
(2) A test focus area defined as the end-user effort required to learn and use the system. Contrast with Operability Testing.
 

User Acceptance Testing (UAT)

The
final trial often undertaken by the users or customers themselves. Is
the system or application "fit for use" by the intended user? See Acceptance Testing.

Validation

(1) The act of demonstrating that a work item is in compliance with
the original requirement. For example, the code of a module would be
validated against the input requirements it is intended to implement.
Validation answers the question "Is it the right system to build?"
(2)
Confirmation by examination and provision of objective evidence that
the particular requirements for a specific intended use have been
fulfilled. See also "Verification".
 

Variance

A mismatch between the actual and expected results occuring in
testing. It may result from errors in the item being tested, incorrect
expected results, invalid test data, etc. See "Error".

Verification

(1) The act of demonstrating that a work item is satisfactorily by
using its predecessor work item. For example, code is verified against
module level design. Verification answers the question "Is the system
being built right?"
(2) Confirmation by examination and provision of
objective evidence that specified requirements have been fulfilled. See
also "Validation".

Volume Tests

Test the largest tasks a program can deal with.
 

Walk-through

A review technique characterised by the author of the object under
review guiding the progression of the review. Observations made in the
review are documented and addressed. Less formal evaluation technique
that an inspection.

White Box Test

It is used to test areas that cannot be reached from a black box level. (Sometimes called Glass Box testing).
 

Work Item

A software development lifecycle work product.

XML

The
Extensible Markup Language (XML) is a general-purpose markup language.
It is classified as an extensible language because it allows its users
to define their own tags. Its primary purpose is to facilitate the
sharing of structured data across different information systems,
particula
rly via the Internet. It is used both to encode documents and serialize
data.
 

Zero Bug Build

Phase
of the PLC where the product has stabilized in terms of bugs found and
fixed. Development is fixing bugs as fast as they are found, the net
resulting in zero bugs on a daily basis. This is usually determined
when after a few builds have passed. This is the preliminary stage
before Green Master.

from http://www.grid-tools.com/glossary.php