Glossary of Software Testing Terms:
This glossary of software testing
terms and conditions is a compilation of knowledge, gathered
over time, from many different sources. It is provided as-is
in good faith, without any warranty as to the accuracy or
currency of any definition or other information contained
herein. If you have any questions or queries about the contents
of this glossary, please contact
Project Realms directly.
Ramp-up time specifies the rate at which the VU for a particular
scenario should start (We can specify either a number or a
percentage starting after "X" time or "X"
number of iterations.
Continuously raising an input signal until the system breaks
A black box
testing approach in which software is tested by choosing
an arbitrary subset of all possible input values. Random testing
helps to avoid the problem of only testing what you know will
The capability of the software product to re-establish a specified
level of performance and recover the data directly affected
in case of failure.
The activity of testing how well the software is able to recover
from crashes, hardware failures and other similar problems.
Recovery testing is the forced failure of the software in
a variety of ways to verify that recovery is properly performed.
Recovery testing is an antagonistic process where the application
or system is exposed to extreme conditions (or simulated conditions)
to cause a failure, such as device I/O failures, invalid database
pointers / keys / triggers, and queue failures. Recovery processes
are invoked and the application or system is monitored and
inspected to verify proper system and data recovery was achieved.
Typically performed with Failover Testing, this testing type
focuses on hardware device failures within a system to see
if the system can recover from device failures.
Examples of recovery testing:
- While the application is running, suddenly restart the
computer and after that check the validness of application's
- While application receives data from the network, unplug
and then in some time plug-in the cable, and analyze the
application's ability to continue receiving data from that
point, when network connection disappeared.
- Restart the system while the browser has a number of sessions
open. After rebooting check that it is able to recover all
A script or set of results containing the steps required to
reproduce a desired outcome.
Any type of software testing which seeks to uncover regression
bugs. Regression bugs occur whenever software functionality
that previously worked as desired, stops working or no longer
works in the same way that was previously planned. Typically
regression bugs occur as an unintended consequence of program
changes. Common methods of regression testing include re-running
previously run tests and checking whether previously fixed faults
Experience has shown that as software is developed, this kind
of reemergence of faults is quite common. Sometimes it occurs
because a fix gets lost through poor revision control practices
(or simple human error in revision control), but often a fix
for a problem will be "fragile" in that it fixes the
problem in the narrow case where it was first observed but not
in more general cases which may arise over the lifetime of the
software. Finally, it has often been the case that when some
feature is redesigned, the same mistakes will be made in the
redesign that were made in the original implementation of the
Therefore in most software development situations it is considered
good practice that when a bug is located and fixed, a test that
exposes the bug is recorded and regularly retested after subsequent
changes to the program. Although this may be done through manual
testing procedures using programming techniques, it is often
done using automated
Conditions such as "is equal to" or "is less
thank" that link an attribute name with an attribute value
in a rule's premise to form logical expressions that can be evaluated
true or false.
A pre-release version, which contains the desired functionality
of the final version, but which needs to be tested for bugs
(which ideally should be removed before the final version is
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.
The ability of the system/software to perform its required functions
under stated conditions for a specified period of time, or for
a specified number of operations.
A specification of the required reliability for the system/software.
Testing to determine whether the system/software meets the specified
A feature or function of the system to be built or changed,
which ties back to the business objectives of the project. Requirements
should be gathered regarding data, process flow, interfaces,
and interactions. A good requirement is ambiguous, concise,
consistent, complete, valid, testable, traceable, and design
independent. It is also easily understood by business associates,
developers, and testers. Use Cases are one form of requirement.
Requirements can be functional or non-functional.
Requirements Based Testing
An approach to testing in which test cases are designed based
on test objectives and test conditions derived from requirements.
For example: tests that exercise specific functions or probe
non-functional attributes such as reliability or usability.
Requirements Traceability Matrix
A requirements traceability matrix is created from the business
requirements in order to map the individual test cases to their
respective requirement to ensure full coverage. Test cases however
are not just limited to the mapping of this document. This is
also referred to as Test Coverage Matrix.
The consequence or outcome of a test.
Testing that runs test cases that failed the last time they
were run, in order to verify the success of corrective actions.
Return on Investment (ROI)
A performance measure used to evaluate the efficiency of an
investment or to compare the efficiency of a number of different
investments. To calculate ROI, the benefit (return) of an investments
is divided by the cost of the investment; the result is expressed
as a percentage or a ratio.
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.
A chance of negative consequences.
Systematic application of procedures and practices to the tasks
of identifying, analyzing, prioritizing, and controlling risk.
The degree to which a component or system can function correctly
in the presence of invalid inputs or stressful environmental
An underlying factor that caused a non-conformance and possibly
should be permanently eliminated through process improvement.
A statement of the form: if X then Y else Z. The "if"
part is the rule premise, and the "then" part is the
consequent. The "else" component of the consequent
is optional. The rule fires when the if part is determine to
be true or false.
The encoded knowledge for an expert system. In a rule-based
expert system, a knowledge base typically incorporates definitions
of attributes and rules along with control information..
| Contact us for more info