| Definition |
Source |
| 1 acceptance testing: Formal
testing conducted to enable a user, customer, or other authorized
entity to determine whether to accept a system or component.
[IEEE] |
BCS SIGIST Version 6.2 |
| 11 beta testing: Operational
testing at a site not otherwise involved with the software developers.
|
BCS SIGIST Version 6.2 |
| 13 black box testing:
See functional test case design. |
BCS SIGIST Version 6.2 |
| 16 boundary value analysis:
A test case design technique for a component in which test cases
are designed which include representatives of boundary values.
|
BCS SIGIST Version 6.2 |
| 28 branch testing: A test
case design technique for a component in which test cases are
designed to execute branch outcomes. |
BCS SIGIST Version 6.2 |
| 37 certification: The
process of confirming that a system or component complies with
its specified requirements and is acceptable for operational
use. From [IEEE]. |
BCS SIGIST Version 6.2 |
| 41 compatibility testing:
Testing whether the system is compatible with other systems
with which it should communicate. |
BCS SIGIST Version 6.2 |
| 50 conformance testing: The
process of testing that an implementation conforms to the specification
on which it is based. |
BCS SIGIST Version 6.2 |
| 56 coverage: The degree,
expressed as a percentage, to which a specified coverage item
has been exercised by a test case suite. |
BCS SIGIST Version 6.2 |
| 66 data flow coverage:
Test coverage measure based on variable usage within the code.
Examples are data definition-use coverage, data definition P-use
coverage, data definition C-use coverage, etc. |
BCS SIGIST Version 6.2 |
| 74 design-based testing:
Designing tests based on objectives derived from the architectural
or detail design of the software (e.g., tests that execute specific
invocation paths or probe the worst case behaviour of algorithms).
|
BCS SIGIST Version 6.2 |
| 87 error: A human action
that produces an incorrect result. [IEEE] |
BCS SIGIST Version 6.2 |
| 96 failure: Deviation
of the software from its expected delivery or service. [Fenton]
|
BCS SIGIST Version 6.2 |
| 97 fault: A manifestation
of an error in software. A fault, if encountered may cause a
failure. [do178b] |
BCS SIGIST Version 6.2 |
| 100 functional specification:
The document that describes in detail the characteristics
of the product with regard to its intended capability. [BS 4778,
Part2] |
BCS SIGIST Version 6.2 |
| 109 inspection: A group
review quality improvement process for written material. It
consists of two aspects; product (document itself) improvement
and process improvement (of both document production and inspection).
After [Graham] |
BCS SIGIST Version 6.2 |
| 114 integration testing:
Testing performed to expose faults in the interfaces and in
the interaction between integrated components. |
BCS SIGIST Version 6.2 |
| 115 interface testing:
Integration testing where the interfaces between system components
are tested. |
BCS SIGIST Version 6.2 |
| 119 LCSAJ testing: A test
case design technique for a component in which test cases are
designed to execute LCSAJs. |
BCS SIGIST Version 6.2 |
| 130 negative testing:
Testing aimed at showing software does not work. [Beizer] |
BCS SIGIST Version 6.2 |
| 131 non-functional requirements
testing: Testing of those requirements that do not relate
to functionality. i.e. performance, usability, etc. |
BCS SIGIST Version 6.2 |
| 132 operational testing:
Testing conducted to evaluate a system or component in its operational
environment. [IEEE] |
BCS SIGIST Version 6.2 |
| 144 performance testing:
Testing conducted to evaluate the compliance of a system or
component with specified performance requirements. [IEEE] |
BCS SIGIST Version 6.2 |
| 145 portability testing:
Testing aimed at demonstrating the software can be ported to
specified hardware or software platforms. |
BCS SIGIST Version 6.2 |
| 154 regression testing:
Retesting of a previously tested program following modification
to ensure that faults have not been introduced or uncovered
as a result of the changes made. |
BCS SIGIST Version 6.2 |
| 155 requirements-based testing:
Designing tests based on objectives derived from requirements
for the software component (e.g., tests that exercise specific
functions or probe the non-functional constraints such as performance
or security). See functional test case design. |
BCS SIGIST Version 6.2 |
| 164 specification: A description
of a component's function in terms of its output values for
specified input values under specified preconditions. |
BCS SIGIST Version 6.2 |
| 176 stress testing: Testing
conducted to evaluate a system or component at or beyond the
limits of its specified requirements. [IEEE] |
BCS SIGIST Version 6.2 |
| 180 structured basis testing:
A test case design technique in which test cases are derived
from the code logic to achieve 100% branch coverage. |
BCS SIGIST Version 6.2 |
| 187 system testing: The
process of testing an integrated system to verify that it meets
specified requirements. [Hetzel] |
BCS SIGIST Version 6.2 |
| 190 test case: A set of
inputs, execution preconditions, and expected outcomes developed
for a particular objective, such as to exercise a particular
program path or to verify compliance with a specific requirement.
After [IEEE,do178b] |
BCS SIGIST Version 6.2 |
| 192 test case suite: A
collection of one or more test cases for the software under
test. |
BCS SIGIST Version 6.2 |
| 195 test coverage: See
coverage. |
BCS SIGIST Version 6.2 |
| 197 test environment:
A description of the hardware and software environment in which
the tests will be run, and any other software with which the
software under test interacts when under test including stubs
and test drivers. |
BCS SIGIST Version 6.2 |
| 198 test execution: The
processing of a test case suite by the software under test,
producing an outcome. |
BCS SIGIST Version 6.2 |
| 204 test plan: A record
of the test planning process detailing the degree of tester
indedendence, the test environment, the test case design techniques
and test measurement techniques to be used, and the rationale
for their choice. |
BCS SIGIST Version 6.2 |
| 205 test procedure: A
document providing detailed instructions for the execution of
one or more test cases. |
BCS SIGIST Version 6.2 |
| 206 test records: For
each test, an unambiguous record of the identities and versions
of the component under test, the test specification, and actual
outcome. |
BCS SIGIST Version 6.2 |
| 207 test script: Commonly
used to refer to the automated test procedure used with a test
harness. |
BCS SIGIST Version 6.2 |
| 208 test specification:
For each test case, the coverage item, the initial state of
the software under test, the input, and the predicted outcome.
|
BCS SIGIST Version 6.2 |
| 210 testing: The process
of exercising software to verify that it satisfies specified
requirements and to detect errors. After [do178b] |
BCS SIGIST Version 6.2 |
| 211 thread testing: A
variation of top-down testing where the progressive integration
of components follows the implementation of subsets of the requirements,
as opposed to the integration of components by successively
lower levels. |
BCS SIGIST Version 6.2 |
| 213 unit testing: See
component testing. |
BCS SIGIST Version 6.2 |
| 214 usability testing:
Testing the ease with which users can learn and use a product.
|
BCS SIGIST Version 6.2 |
| 215 validation: Determination
of the correctness of the products of software development with
respect to the user needs and requirements. |
BCS SIGIST Version 6.2 |
| 216 verification: The
process of evaluating a system or component to determine whether
the products of the given development phase satisfy the conditions
imposed at the start of that phase. [IEEE] |
BCS SIGIST Version 6.2 |
| 217 volume testing: Testing
where the system is subjected to large volumes of data. |
BCS SIGIST Version 6.2 |
| 219 white box testing:
See structural test case design. |
BCS SIGIST Version 6.2 |
