efficiency: The capability of the software product to provide appropriate performance,
relative to the amount of resources used under stated conditions. [ISO 9126]
efficiency testing: The process of testing to determine the efficiency of a software product.
elementary comparison testing: A black box test design techniques in which test cases are
designed to execute combinations of inputs using the concept of condition determination
coverage. [TMap]
emulator: A device, computer program, or system that accepts the same inputs and produces
the same outputs as a given system. [IEEE 610] See also simulator.
entry criteria: 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. [Gilb and Graham]
entry point: The first executable statement within a component.
equivalence class: See equivalence partition.
equivalence partition: 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.
13
equivalence partition coverage: The percentage of equivalence partitions that have been
exercised by a test suite.
equivalence partitioning: 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.
error: A human action that produces an incorrect result. [After IEEE 610]
error guessing: 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.
error seeding: The process of intentionally adding known defects to those already in the
component or system for the purpose of monitoring the rate of detection and removal, and
estimating the number of remaining defects. [IEEE 610]
error tolerance: The ability of a system or component to continue normal operation despite
the presence of erroneous inputs. [After IEEE 610].
evaluation: See testing.
exception handling: Behavior of a component or system in response to erroneous input, from
either a human user or from another component or system, or to an internal failure.
executable statement: A statement which, when compiled, is translated into object code, and
which will be executed procedurally when the program is running and may perform an
action on data.
exercised: A program element is said to be exercised by a test case when the input value
causes the execution of that element, such as a statement, decision, or other structural
element.
exhaustive testing: A test approach in which the test suite comprises all combinations of
input values and preconditions.
exit criteria: 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 by testing to report against and
to plan when to stop testing. [After Gilb and Graham]
exit point: The last executable statement within a component.
expected outcome: See expected result.
expected result: The behavior predicted by the specification, or another source, of the
component or system under specified conditions.
exploratory testing: Testing 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. [Bach]
F
fail: A test is deemed to fail if its actual result does not match its expected result.
failure: Actual deviation of the component or system from its expected delivery, service or
result. [After Fenton]
14
failure mode: The physical or functional manifestation of a failure. For example, a system in
failure mode may be characterized by slow operation, incorrect outputs, or complete
termination of execution.
Failure Mode and Effect Analysis (FMEA): A systematic approach to risk identification
and analysis of identifying possible modes of failure and attempting to prevent their
occurrence.
failure rate: The ratio of the number of failures of a given category to a given unit of
measure, e.g. failures per unit of time, failures per number of transactions, failures per
number of computer runs. [IEEE 610]
{mosgoogle left}
fault: See defect.
fault density: See defect density.
Fault Detection Percentage (FDP): See Defect Detection Percentage (DDP).
fault masking: See defect masking.
fault tolerance: The capability of the software product to maintain a specified level of
performance in cases of software faults (defects) or of infringement of its specified
interface. [ISO 9126] See also reliability.
fault tree analysis: A method used to analyze the causes of faults (defects).
feasible path: A path for which a set of input values and preconditions exists which causes it
to be executed.
feature: An attribute of a component or system specified or implied by requirements
documentation (for example reliability, usability or design constraints). [After IEEE 1008]
field testing: See beta testing.
finite state machine: A computational model consisting of a finite number of states and
transitions between those states, possibly with accompanying actions. [IEEE 610]
finite state testing: See state transition testing.
formal review: A review characterized by documented procedures and requirements, e.g.
inspection.
frozen test basis: A test basis document that can only be amended by a formal change control
process. See also baseline.
Function Point Analysis (FPA): Method aiming to measure the size of the functionality of
an information system. The measurement is independent of the technology. This
measurement may be used as a basis for the measurement of productivity, the estimation of
the needed resources, and project control.
functional integration: An integration approach that combines the components or systems
for the purpose of getting a basic functionality working early. See also integration testing.
functional requirement: A requirement that specifies a function that a component or system
must perform. [IEEE 610]
functional test design technique: Documented procedure to derive and select test cases
based on an analysis of the specification of the functionality of a component or system
without reference to its internal structure. See also black box test design technique.
functional testing: Testing based on an analysis of the specification of the functionality of a
component or system. See also black box testing.
15
functionality: The capability of the software product to provide functions which meet stated
and implied needs when the software is used under specified conditions. [ISO 9126]
functionality testing: The process of testing to determine the functionality of a software
product.
G
glass box testing: See white box testing.
H
heuristic evaluation: A static usability test technique to determine the compliance of a user
interface with recognized usability principles (the so-called heuristics).
high level test case: A test case without concrete (implementation level) values for input data
and expected results.
horizontal traceability: The tracing of requirements for a test level through the layers of test
documentation (e.g. test plan, test design specification, test case specification and test
procedure specification).
I
impact analysis: The assessment of change to the layers of development documentation, test
documentation and components, in order to implement a given change to specified
requirements.
incremental development model: A development life cycle 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 life cycle model, each
subproject follows a mini V-model with its own design, coding and testing phases.
incremental testing: Testing where components or systems are integrated and tested one or
some at a time, until all the components or systems are integrated and tested.
incident: Any event occurring during testing that requires investigation. [After IEEE 1008]
incident management: The process of recognizing, investigating, taking action and disposing
of incidents. It involves recording incidents, classifying them and identifying the impact.
[After IEEE 1044]
incident management tool: A tool that facilitates the recording and status tracking of
incidents found during testing. They often have workflow-oriented facilities to track and
control the allocation, correction and re-testing of incidents and provide reporting facilities.
incident report: A document reporting on any event that occurs during the testing which
requires investigation. [After IEEE 829]
independence: Separation of responsibilities, which encourages the accomplishment of
objective testing. [After DO-178b]
infeasible path: A path that cannot be exercised by any set of possible input values.
informal review: A review not based on a formal (documented) procedure.
input: A variable (whether stored within a component or outside) that is read by a
component.
input domain: The set from which valid input values can be selected.. See also domain.
16
input value: An instance of an input. See also input.
inspection: A type of 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. [After IEEE 610, IEEE 1028]
inspection leader: See moderator.
inspector: See reviewer.
installability: The capability of the software product to be installed in a specified
environment [ISO 9126]. See also portability.
installability testing: The process of testing the installability of a software product. See also
portability testing.
installation guide: Supplied instructions on any suitable media, which guides the installer
through the installation process. This may be a manual guide, step-by-step procedure,
installation wizard, or any other similar process description.
installation wizard: Supplied software on any suitable media, which leads the installer
through the installation process. It normally runs the installation process, provides
feedback on installation results, and prompts for options.
instrumentation: The insertion of additional code into the program in order to collect
information about program behavior during execution. {mosgoogle}
instrumenter: A software tool used to carry out instrumentation.
intake test: A special instance of a smoke test to decide if the component or system is ready
for detailed and further testing. An intake test is typically carried out at the start of the test
execution phase.
integration: The process of combining components or systems into larger assemblies.
integration testing: Testing performed to expose defects in the interfaces and in the
interactions between integrated components or systems. See also component integration
testing, system integration testing.
integration testing in the large: See system integration testing.
integration testing in the small: See component integration testing.
interface testing: An integration test type that is concerned with testing the interfaces
between components or systems.
interoperability: The capability of the software product to interact with one or more
specified components or systems. [After ISO 9126] See also functionality.
interoperability testing: The process of testing to determine the interoperability of a
software product. See also functionality testing.
invalid testing: Testing using input values that should be rejected by the component or
system. See also error tolerance.
isolation testing: Testing of individual components in isolation from surrounding
components, with surrounding components being simulated by stubs and drivers, if needed.
item transmittal report: See release note.
17
K
key performance indicator: See performance indicator.
keyword driven testing: A scripting technique that uses data files to contain not only test
data and expected results, but also keywords related to the application being tested. The
keywords are interpreted by special supporting scripts that are called by the control script
for the test. See also data driven testing.
L
LCSAJ: A Linear Code Sequence And Jump, consisting of the following three items
(conventionally identified by line numbers in a source code listing): the start of the linear
sequence of executable statements, the end of the linear sequence, and the target line to
which control flow is transferred at the end of the linear sequence.
LCSAJ coverage: The percentage of LCSAJs of a component that have been exercised by a
test suite. 100% LCSAJ coverage implies 100% decision coverage.
LCSAJ testing: A white box test design technique in which test cases are designed to execute
LCSAJs.
learnability: The capability of the software product to enable the user to learn its application.
[ISO 9126] See also usability.
link testing: See component integration testing.
load test: A test type concerned with measuring the behavior of a component or system with
increasing load, e.g. number of parallel users and/or numbers of transactions to determine
what load can be handled by the component or system.
logic-coverage testing: See white box testing. [Myers]
logic-driven testing: See white box testing.
logical test case: See high level test case.
low level test case: A test case with concrete (implementation level) values for input data and
expected results.
Subscribe to this comment's feed
| < Prev | Next > |
|---|
