maintenance: Modification of a software product after delivery to correct defects, to improve
performance or other attributes, or to adapt the product to a modified environment. [IEEE
1219]
maintenance testing: Testing the changes to an operational system or the impact of a
changed environment to an operational system.
maintainability: The ease with which a software product can be modified to correct defects,
modified to meet new requirements, modified to make future maintenance easier, or
adapted to a changed environment. [ISO 9126]
maintainability testing: The process of testing to determine the maintainability of a software
product.
management review: A systematic evaluation of software acquisition, supply, development,
operation, or maintenance process, performed by or on behalf of management that
monitors progress, determines the status of plans and schedules, confirms requirements and
18
their system allocation, or evaluates the effectiveness of management approaches to
achieve fitness for purpose. [After IEEE 610, IEEE 1028]
maturity: (1) The capability of an organization with respect to the effectiveness and
efficiency of its processes and work practices. See also Capability Maturity Model, Test
Maturity Model. (2) The capability of the software product to avoid failure as a result of
defects in the software. [ISO 9126] See also reliability.
master test plan: See project test plan.
measure: The number or category assigned to an attribute of an entity by making a
measurement [ISO 14598].
measurement: The process of assigning a number or category to an entity to describe an
attribute of that entity. [ISO 14598]
measurement scale: A scale that constrains the type of data analysis that can be performed
on it. [ISO 14598]
memory leak: A defect in a program's dynamic store allocation logic that causes it to fail to
reclaim memory after it has finished using it, eventually causing the program to fail due to
lack of memory.
metric: A measurement scale and the method used for measurement. [ISO 14598]
migration testing: See conversion testing.
milestone: A point in time in a project at which defined (intermediate) deliverables and
results should be ready.
mistake: See error.
moderator: The leader and main person responsible for an inspection or other review
process.
modified condition decision coverage: See condition determination coverage.
modified condition decision testing: See condition determination coverage testing.
modified multiple condition coverage: See condition determination coverage.
modified multiple condition testing: See condition determination coverage testing.
module: See component.
module testing: See component testing.
monitor: A software tool or hardware device that run concurrently with the component or
system under test and supervises, records and/or analyses the behavior of the component or
system. [After IEEE 610]
multiple condition: See compound condition.
multiple condition coverage: The percentage of combinations of all single condition
outcomes within one statement that have been exercised by a test suite. 100% multiple
condition coverage implies 100% condition determination coverage.
multiple condition testing: A white box test design technique in which test cases are
designed to execute combinations of single condition outcomes (within one statement).
mutation analysis: A method to determine test suite thoroughness by measuring the extent to
which a test suite can discriminate the program from slight variants (mutants) of the
program.
19
{mosgoogle}
N
N-switch coverage: The percentage of sequences of N+1 transitions that have been exercised
by a test suite. [Chow]
N-switch testing: A form of state transition testing in which test cases are designed to execute
all valid sequences of N+1 transitions. [Chow] See also state transition testing.
negative testing: Tests aimed at showing that a component or system does not work.
Negative testing is related to the testers attitude rather than a specific test approach or test
design technique. [After Beizer].
non-conformity: Non fulfillment of a specified requirement. [ISO 9000]
non-functional requirement: A requirement that does not relate to functionality, but to
attributes of such as reliability, efficiency, usability, maintainability and portability.
non-functional testing: Testing the attributes of a component or system that do not relate to
functionality, e.g. reliability, efficiency, usability, maintainability and portability.
non-functional test design techniques: Methods used to design or select tests for nonfunctional
testing.
O
off-the-shelf software: A software product that is developed for the general market, i.e. for a
large number of customers, and that is delivered to many customers in identical format.
operability: The capability of the software product to enable the user to operate and control it.
[ISO 9126] See also usability.
operational environment: Hardware and software products installed at users or customers
sites where the component or system under test will be used. The software may include
operating systems, database management systems, and other applications.
operational profile testing: Statistical testing using a model of system operations (short
duration tasks) and their probability of typical use. [Musa]
operational testing: Testing conducted to evaluate a component or system in its operational
environment. [IEEE 610]
oracle: See test oracle.
outcome: See result.
output: A variable (whether stored within a component or outside) that is written by a
component.
output domain: The set from which valid output values can be selected. See also domain.
output value: An instance of an output. See also output.
P
pair programming: 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.
pair testing: Two testers work together to find defects. Typically, they share one computer
and trade control of it while testing.
partition testing: See equivalence partitioning. [Beizer]
20
pass: A test is deemed to pass if its actual result matches its expected result.
pass/fail criteria: Decision rules used to determine whether a test item (function) or feature
has passed or failed a test. [IEEE 829]
path: A sequence of events, e.g. executable statements, of a component or system from an
entry point to an exit point.
path coverage: The percentage of paths that have been exercised by a test suite. 100% path
coverage implies 100% LCSAJ coverage.
path sensitizing: Choosing a set of input values to force the execution of a given path.
path testing: A white box test design technique in which test cases are designed to execute
paths.{mosgoogle}
peer review: See technical review.
performance: The degree to which a system or component accomplishes its designated
functions within given constraints regarding processing time and throughput rate. [After
IEEE 610] See efficiency.
performance indicator: A high level metric of effectiveness and/or efficiency used to guide
and control progressive development, e.g. Defect Detection Percentage (DDP) for testing.
[CMMI]
performance testing: The process of testing to determine the performance of a software
product. See efficiency testing.
performance testing tool: A tool to support performance testing and that usually has two
main facilities: load generation and test transaction measurement. Load generation can
simulate either multiple users or high volumes of input data. During execution, response
time measurements are taken from selected transactions and these are logged. Performance
testing tools normally provide reports based on test logs and graphs of load against
response times. {mosgoogle}
phase test plan: A test plan that typically addresses one test level.
portability: The ease with which the software product can be transferred from one hardware
or software environment to another. [ISO 9126]
portability testing: The process of testing to determine the portability of a software product.
postcondition: Environmental and state conditions that must be fulfilled after the execution
of a test or test procedure.
post-execution comparison: Comparison of actual and expected results, performed after the
software has finished running.
precondition: Environmental and state conditions that must be fulfilled before the component
or system can be executed with a particular test or test procedure.
predicted outcome: See expected result.
pretest: See intake test.
priority: The level of (business) importance assigned to an item, e.g. defect.
process cycle test: A black box test design technique in which test cases are designed to
execute business procedures and processes. [TMap]
problem: See defect.
21
problem management: See defect management.
problem report: See defect report.
process: A set of interrelated activities, which transform inputs into outputs. [ISO 12207]
project: A project is a unique set of coordinated and controlled activities with start and finish
dates undertaken an objective conforming to specific requirements, including the
constraints of time, cost and resources. [ISO 9000]
program instrumenter: See instrumenter.
program testing: See component testing.
project test plan: A test plan that typically addresses multiple test levels.
pseudo-random: A series which appears to be random but is in fact generated according to
some prearranged sequence.
Q
quality: The degree to which a component, system or process meets specified requirements
and/or user/customer needs and expectations. [After IEEE 610]
quality assurance: Part of quality management focused on providing confidence that quality
requirements will be fulfilled. [ISO 9000]
quality attribute: A feature or characteristic that affects an items quality. [IEEE 610]
quality characteristic: See quality attribute.
quality management: Coordinated activities to direct and control an organization with regard
to quality. Direction and control with regard to quality generally includes the establishment
of the quality policy and quality objectives, quality planning, quality control, quality
assurance and quality improvement. [ISO 9000]
R
random testing: A black box test design technique where test cases are selected, possibly
using a pseudo-random generation algorithm, to match an operational profile. This
technique can be used for testing non-functional attributes such as reliability and
performance.
recorder: See scribe.
record/playback tool: See capture/playback tool.
recoverability: The capability of the software product to re-establish a specified level of
performance and recover the data directly affected in case of failure. [ISO 9126] See also
reliability.
recoverability testing: The process of testing to determine the recoverability of a software
product. See also reliability testing.
recovery testing: See recoverability testing.
regression testing: Testing of a previously tested program following modification to ensure
that defects have not been introduced or uncovered in unchanged areas of the software, as a
result of the changes made. It is performed when the software or its environment is
changed.
22
release note: A document identifying test items, their configuration, current status and other
delivery information delivered by development to testing, and possibly other stakeholders,
at the start of a test execution phase. [After IEEE 829]
reliability: The ability of the software product to perform its required functions under stated
conditions for a specified period of time, or for a specified number of operations. [ISO
9126]
reliability testing: The process of testing to determine the reliability of a software product.
replaceability: The capability of the software product to be used in place of another specified
software product for the same purpose in the same environment. [ISO 9126] See also
portability.
requirement: A condition or capability needed by a user to solve a problem or achieve an
objective that must be met or possessed by a system or system component to satisfy a
contract, standard, specification, or other formally imposed document. [After IEEE 610]
requirements-based testing: An approach to testing in which test cases are designed based
on test objectives and test conditions derived from requirements, e.g. tests that exercise
specific functions or probe non-functional attributes such as reliability or usability.
requirements management tool: A tool that supports the recording of requirements,
requirements attributes (e.g. priority, knowledge responsible) and annotation, and
facilitates traceability through layers of requirements and requirements change
management. Some requirements management tools also provide facilities for static
analysis, such as consistency checking and violations to pre-defined requirements rules.
requirements phase: The period of time in the software life cycle during which the
requirements for a software product are defined and documented. [IEEE 610]
resource utilization: The capability of the software product to use appropriate amounts and
types of resources, for example the amounts of main and secondary memory used by the
program and the sizes of required temporary or overflow files, when the software performs
its function under stated conditions. [After ISO 9126] See also efficiency.
resource utilization testing: The process of testing to determine the resource-utilization of a
software product.
result: The consequence/outcome of the execution of a test. It includes outputs to screens,
changes to data, reports, and communication messages sent out. See also actual result,
expected result.
resumption criteria: The testing activities that must be repeated when testing is re-started
after a suspension. [After IEEE 829]
re-testing: Testing that runs test cases that failed the last time they were run, in order to
verify the success of corrective actions.
review: An evaluation of a product or project status to ascertain discrepancies from planned
results and to recommend improvements. Examples include management review, informal
review, technical review, inspection, and walkthrough. [After IEEE 1028]
reviewer: The person involved in the review who shall identify and describe anomalies in the
product or project under review. Reviewers can be chosen to represent different viewpoints
and roles in the review process.
risk: A factor that could result in future negative consequences; usually expressed as impact
and likelihood.
23
risk analysis: The process of assessing identified risks to estimate their impact and
probability of occurrence (likelihood).
risk-based testing: Testing oriented towards exploring and providing information about
product risks. [After Gerrard]
risk control: The process through which decisions are reached and protective measures are
implemented for reducing risks to, or maintaining risks within, specified levels.
risk identification: The process of identifying risks using techniques such as brainstorming,
checklists and failure history.
risk management: Systematic application of procedures and practices to the tasks of
identifying, analyzing, prioritizing, and controlling risk.
risk mitigation: See risk control.
robustness: The degree to which a component or system can function correctly in the
presence of invalid inputs or stressful environmental conditions. [IEEE 610] See also errortolerance,
fault-tolerance.
root cause: An underlying factor that caused a non-conformance and possibly should be
permanently eliminated through process improvement.
Subscribe to this comment's feed
| < Prev | Next > |
|---|
