Sue Nethercott :: Testing Glossary

Testing Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z other

A	Back to top
Acceptance Testing	Formal, hopefully final testing that lets a user, customer, or whoever else is authorised to, to decide whether or not to accept a system or component.
Actual Outcome	The behaviour that an object actually produces when is tested under specified conditions.
Ad Hoc Testing	Testing carried without the benefit of a recognised test case design technique, possibly by people who know the system well.
Alpha Testing	In-house testing carried out by end-users or others (not by programmers or testers) in operational or simulated conditions when development is near completion. It may result in minor design changes.
ANSI	American National Standards Institute (US Standards)
Arc Testing	Branch testing.
ASQ	American Society for Quality (sells ISO standards)
ASTM	American Society for Testing and Materials (ISO)
ATP	Acceptance Testing Plan (V-model)
AWI	Approved Work Item (ISO)
B	Back to top
Backus-Naur Form	A metalanguage that formally describes the syntax of a language. See ISO 14977.
Basic Block	One or more consecutive executable statements, in sequence, without any branch.
Basis Test Set	A set of test cases, derived from the code logic, chosen to ensure that there is full branch coverage.
BCS	British Computer Society
Bebugging	See error seeding.
Behaviour	The required response for a function of a system to the combination of input values and preconditions. One or more behaviours are generally included in a specification.
Beta Testing	Operational testing carried out just before final release. It is usually done on a different site to that used by the developers, and is carried out by end-users or others, not by the programmers or testers.
Big-Bang Testing	Integration testing without prior incremental testing of the individual components before they are combined to form the system.
Black Box Testing	Testing of requirements and functionality without any knowledge of the interior design or code of the system. Contrast with white box testing. See functional test case design. Black box approaches include: data driven test data flow driven test event driven test function driven test logic driven test random test state driven test statistical (usage profile driven) test transaction flow driven test
Boolean Expression	A Boolean expression is one which compares two or more values, and returns a Boolean variable (true or false).
Bottom-up Testing	Testing that starts with the lowest level components, then uses them to test the next level, and so on until all components have been tested. It is used for Integration testing
Boundary Value	An input value or output value which is on the boundary between equivalence classes, or an incremental distance either side of the boundary.
Boundary Value Analysis:	A test case design technique. Test cases are designed for a component which include representatives of boundary values.
Boundary Value Coverage	The percentage of boundary values of the component's equivalence classes which a test case suite has exercised.
Boundary Value Testing	See boundary value analysis.
Branch	Transfer of control from one statement in a component to another. This may be unconditionally to any other statement except the immediately following one, or conditionally to any statement. If a component has more than one entry point, the transfer of control can be to an entry point of the component.
Branch Condition	See decision condition.
Branch Condition Combination Coverage	The percentage of combinations of all branch condition outcomes in every decision that have been exercised by a test case suite .
Branch Condition Combination Testing	A test case design technique. Test cases are selected to execute combinations of branch condition outcomes.
Branch Condition Coverage	The percentage of branch condition outcomes in each decision that a test case suite has exercised.
Branch Condition Testing	A test case design technique. Test cases are selected to execute branch condition outcomes.
Branch Point	See decision.
Bug	See fault.
Bug seeding	See error seeding.
Branch Coverage	The percentage of branches that a test case suite has had exercised.
Branch Outcome	A decision outcome.
Branch Testing	In this component test case design technique, test cases are designed to execute branch outcomes.
C	Back to top
C-use	See computation data use.
Capture/Playback Tool	A test tool that records the test input sent to the software under test. The input cases thus stored can then be used to reproduce the test at a later time.
Capture/Replay Tool	See capture/playback tool.
CASCO	ISO Committee on conformity assessment
CAST	Computer-Aided Software Tools or Testing
Cause-Effect Graph	A graphical representation of inputs or stimuli (causes) with their associated outputs (effects). This can be used to design test cases.
Cause-Effect Graphing	A test case design technique. Test cases are designed by considering cause-effect graphs.
Certification	Confirmation that a system or component complies with its specified requirements and is acceptable for operational use.
Chow's Coverage Metrics	See N-switch coverage.
CI	Configuration Item
CMM	Capability Maturity Model. Developed by SEI.
Code Coverage	Analysing which parts of the software have been executed (covered) by the test case suite and which have not.
Code-Based Testing	Testing of objectives related to implementation (e.g., executing specific data items or control flow paths.
Comparison Testing	Comparing the software with that of the competition.
Compatability Testing	Testing now the software works with a particular operating system or network, with particular software, in a particualr environment, or an particular hardware.
Compatibility Testing	Testing the system's compatibility with other systems it ought to work with.
Compile	Translate into object code
Complete Path Testing	See exhaustive testing.
Component	The smallest item of software for which there is a separate specification.
Component Testing	Testing individual software components.
Computation Data Use	A data use not in a condition. Also called C-use.
Condition	A Boolean expression that contains no Boolean operators, such as A>B (but not A or B).
Condition Coverage	See branch condition coverage.
Condition Outcome	Whether a condition evaluates to TRUE or FALSE.
Conformance Criterion	A way of deciding if component's behaviour in reaction to a particular specified input value meets the specification.
Conformance Testing	Testing that an implementation meets its specification.
Conformity	An organisation that meets the relevant ISO 9001, ISO 9002, and ISO 9003 quality system requirements is said to be behaving in conformity with those requirements.
Contract Review	A review to check that the customer contracts specify which quality requirements apply, and that they are achievable.
Control Flow	Control Flow represents all possible sequences of events in a program's execution.
Control Flow Graph	A diagram showing the alternative control flow paths possible through a component.
Control Flow Path	See path.
Conversion Testing	Testing the programs or procedures which convert data from existing systems for use in the new systems.
Corrective Actions	Steps taken to remove the cause(s) of a nonconformity or to make quality improvements.
Correctness	How well software meets its specification.
Coverage	The percent by which a test case suite has exercised a specified coverage item
Coverage Item	An entity or property used for testing.
Customer	Any recipient (within or outside the supplier's organisation) of products or services from a supplier.
D	Back to top
Data Definition	An executable statement that assigns a value to a variable.
Data Definition C-Use Coverage	The percentage of data definition C-use pairs in a component that a test case suite exercises.
Data Definition C-Use Pair	A data definition and computation data use, where the data use uses the value defined in the data definition.
Data Definition P-Use Coverage	The percentage of data definition P-use pairs in a component that a test case suite exercises.
Data Definition P-Use Pair	A data definition and predicate data use, where the data use uses the value defined in the data definition.
Data Definition-Use Coverage	BCS: The percentage of data definition-use pairs in a component that a test case suite exercises.
Data Definition-Use Pair	A data definition and data use, where the data use uses the value defined in the data definition.
Data Definition-Use Testing	A test case design technique for a component in which test cases are designed to execute data definition-use pairs.
Data Driven Test	See component test.
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.
Data Flow Driven Test	Checking that the data flow is not broken.
Data Flow Testing	Use of test cases based on variable usage within the code.
Data Use	An executable statement that accesses the value of a variable.
Debugging	Finding and removing causes of software failures.
Decision	A point in a program at which the control flow can take two or more alternative routes.
Decision Condition	A condition within a decision.
Decision Coverage	The percentage of decision outcomes that have been exercised by a test case suite.
Decision Outcome	The result of a decision. It determines the control flow alternative taken.
Design-Based Testing	Testing based on the architectural or detail design of the software. This may include testing the worst case behaviour of algorithms, or executing specific invocation paths.
Design Review	Reviewing a product to determine how well it meets quality requirements; identifying problems and developing solutions.
Design Validation	Examining a product to confirm objectively that it meets user needs.
Design Verification	Examining design outputs to confirm objectively that they meet input requirements.
Desk Checking	Testing software by manually simulating its execution.
Dirty Testing	See negative testing.
Documentation Testing	Testing to ensure that the documentation is accurate.
Domain	The set from which values are selected.
Domain Testing	See equivalence partition testing.
Dynamic Analysis	Evaluating a system or component on the basis of its behaviour during execution.
E	Back to top
Elements	Components which combine to form a quality system, such as functions, policies, procedures, practices, resources, responsibilities, authorities, relationships and processes.
Emulator	Something (such as a device, computer program, or system) which takes the same inputs as a given system and produces the same outputs.
End-to-End Testing	'Macro' system testing - testing in a simulated complete real-world environment, perhaps involving interaction with a database, other hardware, applications, and/or systems, and communicating with other networks.
Entity	An organisation, company, department, system, product, process or person, for example.
Entry Point	The first executable statement of a component.
Equivalence Class	A portion of the component's input or output domains for which the component's behaviour is assumed to be the same from the component's specification.
Equivalence Partition	See equivalence class.
Equivalence Partition Coverage	The percentage of a component's equivalence classes which have been exercised by a test case suite.
Equivalence Partition Testing	A test case design technique. Test cases are designed to execute representatives from equivalence classes for a component .
Error	An incorrect result produced by human action.
Error Guessing	A test case design technique. The tester guesses what faults might occur on the basis of experience, and designs tests specifically for them.
Error Seeding	Adding known faults to a computer program that still has faults in, in order to monitor the rate of detection and removal. This helps in estimating the number of faults remaining in the program
EVV	Evaluation, Verification & Validation
Event Driven Test	Most embedded systems are event-driven. Event driven testing tests how the system handles events arriving at different ties and in different orders, race conditions and deadlocks.
Executable Statement	A statement that will be executed procedurally when the program is running.
Exercise	A test case exercises a program element (e.g. statement, branch) when an input value causes the execution of that element.
Exhaustive Testing	A test case design technique. Test cases are selected to cover all combinations of preconditions and input values for component variables.
Exit Point	The final executable statement in a component.
Expected Outcome	Predicted outcome.
Exploratory Testing	Informal testing, not using test plans. It can be useful to help testers get to know the system.
F	Back to top
Facility Testing	See functional test case design.
Failure	A failure occurs when the software does not provide the delivery or service expected.
Fault	The manifestation of an error in software. It may cause a failure.
Feasible Path	When there is a set of input values and execution conditions which cause a path to be executed, it is said to be feasible
Feature Testing	See functional test case design.
FTR	Formal Technical Review
Functional Specification	A detailed specification describing the characteristics of the product with regard to its intended capability.
Functional Test Case Design	The selection of test cases using the specification of the component and not its internal workings.
Function Driven Test	Used to smoke test the higher level tests by covering each function at least once.
Functional Testing	Black box testing, performed by testers rather than developers, checking that a program carries out the required functions.
G	Back to top
Glass Box Testing	See structural test case design.
GQM	Goal-Question-Metric
GTP	Generic Test Process
H	Back to top
HISSA	High Integrity Software Systems Assurance
I	Back to top
Input	A variable that is read by the component. It does not have to be stored within the component.
ICS	International Classification for Standards
IEEE	Institute of Electrical and Electronics Engineers (US)
Incremental Integration Testing	Testing, carried out by programmers or testers, where first one part of the system is tested, then more functionality is added and tested, then more, and so on. This requires separate parts of the system to be able to work independently, or for test drivers to be developed.
Incremental Testing	Testing by integrating one component at a time until you end up with full integration testing.
Independence	Ensuring objective evaluation by separating responsibilities.
INFCO	ISO Committee on information systems and services (disbanded).
Infeasible Path	When a path cannot be exercised whatever input values are used, it is saif to be infeasible.
Input	A variable (whether stored within a component or outside it) that is read by the component.
Input Domain	The set of all possible inputs.
Input Value	An instance of an input.
ISEB	Information Systems Examination Board of the BCS
Inspection	A group review. A small team of people including a moderator, reader, and a recorder to take notes thoroughly read the document to be inspected looking for problems, errors and omissions. These are then discussed and recorded at an inspection meeting and recorded. A cost-effective way of achieving quality, both in document production and inspection.
Install/Uninstall Testing	Testing of new or upgraded install/uninstall processes.
Installability Testing	Testing the installation procedures for a system.
Instrumentation	Adding extra code to collect information about program behaviour during program execution.
Instrumenter	A software tool used for instrumentation.
Integration	Combining components into larger assemblies.
Integration Testing	Testing concentrating on the interfaces and interaction between integrated components. Parts of the application (e.g. code modules, individual applications, client and server applications on a network) are combined to check that they function together correctly.
Interface Testing	Integration testing involving the interfaces between system components.
Internal Quality Audit	Examination my own personnel to check that the elements of a system comply with quality system requirements.
ISO	International Organisation for Standardisation
Isolation Testing	Component testing individual components in isolation by simulating the surrounding components by stubs.
ITP	Integration Testing Plan (V-model)
IV & V	Independent Verification and Validation.
J	Back to top
K	Back to top
L	Back to top
LCSAJ	A Linear Code Sequence And Jump, which consists of: the start of the linear sequence of executable statements, the end of the linear sequence, the target line to which control flow is transferred at the end of the linear sequence. These are usually identified by line numbers in a source code listing.
LCSAJ Coverage	The percentage of LCSAJs of a component that a test case suite exercises.
LCSAJ Testing	In this test case design technique, test cases for a component are designed to execute LCSAJs.
Load Testing	Testing how an application behaves under heavy loads.
Logic-Coverage Testing	See structural test case design.
Logic-Driven Testing	See structural test case design.
M	Back to top
Metalanguage	A definition or description of language
Maintainability testing	Testing whether a system is as maintainable as specified.
Modified Condition/Decision Coverage	The percentage of all branch condition outcomes that independently affect a decision outcome that have been exercised by a test case suite.
Modified Condition/Decision Testing	A test case design technique in which test cases are designed to execute branch condition outcomes that independently affect a decision outcome.
Multiple Condition Coverage	See branch condition combination coverage.
Mutation Analysis	Creating slight variants (mutants) of the program and seeing how well a test case suite can discriminate between the variants and the original. This tests the test case suite's thoroughness. See also error seeding.
Mutation Testing	Deliberately introduce various code changes ('bugs') and retest with the original test data/cases to determine if the 'bugs' are detected. This helps detrmine if a set of test data or test cases is useful, but requires large computational resources.
N	Back to top
N-switch Coverage	BCS: The percentage of sequences of N-transitions that a test case suite has exercised.
N-switch Testing	A form of state transition testing. Test cases are designed to execute all valid sequences of N-transitions.
N-transitions	A sequence of N+ transitions.
Negative Testing	Testing that is designed to show that software does not work.
Nonconforming Products	Products which deviate from quality requirements, failing to meet specified requirements..
Nonconformity	A noconformity occurs when a product, process, procedure, system, structure or organisation deviates from ISO 9001, ISO 9002, or ISO 9003 requirements.td>
Non-functional Requirements Testing	Testing performance, usability, or any other requirements that do not relate to functionality.
O	Back to top
Operational Testing	Testing aimed at evaluating a system or component within its intended operational environment.
Oracle	A way of producing predicted outcomes to compare with the actual outcomes of the software under test.
Organisation	A company, corporation, firm, or institution that has its own functions and administration.
Organisational Structure	The pattern of responsibilities, authorities, and relationships controlling how people perform their functions and how they interact with one another.
Output Domain	The set of all possible outputs.
Outcome	The outcome of a test, whether an actual outcome or a predicted outcome. An outcome can also be a branch outcome, a condition outcome or a decision outcome.
Output	A variable written to by the component. It may be stored within or outside the component.
Output Value	An instance of an output.
P	Back to top
P-Use	See predicate data use.
Partition Testing	See equivalence partition testing.
Path	A route through a component, consisting of a sequence of executable statements going from an entry point to an exit point.
Path Coverage	The percentage of a component's paths that are exercised by a test case suite.
Path Sensitizing	Forcing the execution of a component to take a given path by judicious choice of a set of input values.
Path Testing	A test case design technique. Test cases are designed to execute paths of a component.
Penetration Testing
Performance Testing	Testing that a component or system complies with the performance requirements documented in requirements documentation or QA or Test Plans. Often used interchangeably with stress testing or load testing.
Portability Testing
Progressive Testing
PMP	Project Management Plan (V-model)
Portability Testing	Testing that the software can be ported to specified hardware or software platforms.
Precondition	An environmental or state condition that has to be fulfilled before a component can be executed with a particular input value.
Predicate	A logical expression which evaluates to TRUE or FALSE. This is usually used to determine which path in the code to execute.
Predicate Data Use	A data use in a predicate.
Predicted outcome	The behaviour that a specification predicts for an object under specified conditions.
Preventive Actions	Steps taken to remove the causes of potential nonconformities or to make quality improvements.
Procedure	A procedure controls a logically distinct set of activities, defining the work to be done, how it should be done, who should do it, under what circumstances, who is responsible, who has the authority, and the resources and documentation required.
ProcePT	Process Programming and Testing (V-model)
Process	A process uses resources to transform inputs into outputs, carrying out some kind of work, activity, or function.
Product	An output that results from a process, whether tangible or intangible. It may also mean service.
Product Inspection	An activity that compares product characteristics with product requirements in order to establish conformity.
Product Nonconformity	When one or more characteristics of a product fail to meet specified requirements, they are referred to as product nonconformities.
Program Instrumenter	See instrumenter.
Progressive Testing	Testing new features after regression testing of previous features.
Pseudo-Random	A series generated according to some prearranged sequence, yet which happears to be random.
Q	Back to top
QA	Quality Assurance
QAP	Quality Assurance Plan (V-model)
Quality	The characteristics of an entity which meet stated or implied needs, such as dependability.
Quality Assurance	A set of activities designed to demonstrate that an entity meets all quality requirements.
Quality Audits	Checking how well the elements which combine to form a quality system meet quality system requirements.
Quality Control	The set of activities (such as monitoring, perfromance problem solution) or techniques intended to ensure that all quality requirements are being met.
Quality Improvement	The set of activities aimed at improving the efficiency and effectiveness of the organization.
Quality Management	All the activities, such as quality planning, quality control and quality assurance, aimed at implementing a quality policy.
Quality Manual	A document stating a quality policy and describing a quality system, including the relevant roles, relationships, functions, processes, procedures, systems, and resources.
Quality Planning	The activities which define quality system policies, objectives, and requirements. It will include an explanation of how to apply policies, how to achieve objectives, and how to meet requirements.
Quality Plan	A document describing how quality policies will be applied, quality objectives achieved, and quality system requirements met.
Quality Policy	A statement defining how an organisation is committed to quality.
Quality Record	Objective evidence showing how well a quality requirement is met or how well a quality system element performs.
Quality Requirement	A characteristic, such as dependability, that is required of an entity.
Quality Surveillance	Monitoring an entity and reviewing its records to show that quality requirements are being met.
Quality System	The network of processes made up of elements whose purpose is to satisfy quality requirements.
Quality System Element	The quality system elements which combine to form a quality system.
Quality System Requirement	A quality or characteristic that a system element must have.
R	Back to top
Random Test	An easy way to generate test cases, using a test oracle.
RD	Requirements Definition (V-model)
Record	A document containing objective evidence which showing how well activities are being performed or what kind of results are being achieved.
Recovery Testing	Testing a system's ability to recover from varying degrees of hardware failure, crashes, and other catastrophes.
Regression Testing	Retesting of a previously tested program after it or its environment has been modified. It is carried out to check that no faults have been introduced or uncovered by the changes. It lends itself to the use of automated testing tools.
Requirements-Based Testing	These tests are designed using the specified requirements for the software component. They can test functions or non-functional constraints such as security or performance. See functional test case design.
Resources	People, money, equipment, skill, knowledge, for example.
Result	See outcome.
Review	A meeting where one or more work products is presented for comment or approval.
RISQ	Reference Information for Software Quality
S	Back to top
Sanity Testing	Preliminary testing to decide whether the system is in performing well enough for it to be worthwhie starting the main testing effort.
Security Testing
SCI	Software Configuration Item
SCM	Software Configuration Management
Security Testing	Testing whether a system's ability to deal with unauthorized access, hacking, willful damage, etc. meets specified security objectives.
Serviceability Testing	See maintainability testing.
Service	An activity aimed at meeting customer needs.
Service Delivery	A suppliers's activity aimed at meeting customer needs.
SEI	Software Engineering Institute (Carnegie-Mellon University, U.S. Defense Department). Developed CMM.
SEPT	Software Engineering Process Technology
SES	Systems External Specification (V-model)
Simple Subpath	A subpath of the control flow graph in which no program part is executed more than necessary.
Simulation	Using one physical or abstract system to represent another.
Simulator	Something which acts like a given system when supplied with a set of controlled inputs. Simulators are used during software verification.
SIS	Systems Internal Design (V-model)
Smoke Testing
Software Life Cycle	The conception, birth, life and death (discarding) of an application, including requirements analysis, functional design, internal design, documentation, test planning, coding, integration, testing, maintenance, updating and retesting.
Software Quality Assurance	Monitoring and improving the entire software development process, ensuring that agreed-upon standards and procedures are followed, and that problems are found and dealt with.
Software Testing	Operating a system or application under controlled conditions and evaluating how well it works under both normal and abnormal conditions.
Source Statement	See statement.
Specification	A specification describes a component's function: the output values required for specified input values under specified preconditions.
Specified Input	A specification predicts an outcome for a specified input.
SPICE	Software Process Improvement and Capability Determination (ISO/IEC 15504)
SPQP	Software Project Quality Plan
SQA	Software Quality Assurance
SQS	Software Quality System
Standard	A model for how things should be, or be done.
State Driven Test	Ttesting of state machines, such as most OO and real time software. State machines can be verified using simulation, models or static analysis. State driven tests should cover how test cases can be derived.
Statement	The smallest indivisible unit of execution in a programming language.
State Transition	A transition between two allowable states of a system or component.
State Transition Testing	A test case design technique. Test cases are selected to execute state transitions.
Statement	An entity in a programming language which is typically the smallest indivisible unit of execution.
Statement Coverage	The percentage of executable statements in a component that a test case suite exercises
Statement Testing	A test case design technique. Test cases are designed to execute a component's statements.
Static Analysis	Analysing a program without executing it.
Static Analyzer	A static analysis tool.
Static Testing	Testing an object without executing it on a computer.
Statistical Testing	A test case design technique. Representative test cases are constructed using a model of the statistical distribution of the input. Used to certify trliability. A high level approach used in hardware testing and certain software testing.
Storage Testing	Testing if a system meets its specified storage objectives.
STORM	Software Testing Online Resources at MTSU
STP	System Testing Plan (V-model)
Stress Testing	Testing to evaluate a system or component at or beyond the limits of its specified requirements. The term is often used interchangeably with load testing and performance testing It may involve unusually heavy loads, heavy repetition, massive numerical input values, very complex database queries, etc.
Structural Coverage	Coverage measures based on the internal structure of the component.
Structural Test case design	Analysis of the internal structure of a component then selecting test cases on the basis of that analysis.
Structural Testing	See structural test case design.
Structured Basis Testing	A test case design technique. Test cases are derived from the code logic to achieve % branch coverage.
Structured Walkthrough	See walkthrough.
Stub	A special software module that simulates a module that the component under development or test calls or is otherwise dependent on.
Subpath	A sequence of executable statements within a component.
Supplier	An organisation providing products to internal or external customers.
Symbolic Evaluation	See symbolic execution.
Symbolic Execution	A static analysis technique.A symbolic expression is derived for program paths.
Syntax Testing	A test case design technique. Test case design for a component or system is based upon the syntax of the input.
System	A set of interrelated elements.
System Testing	Black-box testing of an entire integrated system to verify that it meets the overall specified requirements.
T	Back to top
Technical Requirements Testing	See non-functional requirements testing.
Test Automation	Using software for controlling test execution, comparing actual outcomes with predicted outcomes, setting up test preconditions, etc.
Test Case	The inputs, execution preconditions, and expected outcomes selected to test a particular objective. This might be to verify compliance with a specified requirement or to test a particular program path, for example.
Test Case Design Technique	A method chosen to derive or select test cases.
Test Case Suite	A set of one or more test cases designed to test a particular software item.
Test Comparator	A test tool used to compare actual outputs produced by the software for that test case with the expected outputs.
Test Completion Criterion	A criterion for determining when planned testing is complete. It is defined in terms of a test measurement technique.
Test Coverage	See coverage.
Test Driver	A program or test tool used to execute software against a test case suite.
Test Environment	The hardware and software environment in which the tests will be run, or with which the software under test will interact (including stubs and test drivers).
Test Execution	Running a test case suite using the software under test, and producing an outcome.
Test Execution Technique	The method used to perform the actual test execution. This could be manual, or capture/playback tool, for example.
Test Generator	A program to generate test cases in accordance with a specified strategy or heuristic.
Test Harness	A testing tool comprising a test driver and a test comparator.
Testing	Running software to verify that it meets specified requirements, and to find errors.
Test Measurement Technique	A method used to measure test coverage items.
Test Outcome	See outcome.
Test Plan	The product of test planning detailing the degree of tester indedendence, the test environment, the test case design techniques and test measurement techniques to be used, and why they were chosen.
Test Procedure	Detailed instructions for the execution of one or more test cases.
Test Records	Clear documentation of the identities and versions of the component under test, the test specification, and the actual outcome for each test.
Test Script	The automated test procedure used with a test harness.
Test Specification	Includes the coverage item, the initial state of the software under test, the input, and the predicted outcome for each test case.
Test Target	A set of test completion criteria.
Thread Testing	Like top-down testing, but the progressive integration of components follows the implementation of subsets of the requirements, rather than the integration of components by successively lower levels.
TMM	Test Maturity Model
Top-Down Testing	A form of integration testing where the first component to be tested is the one at the top of the hierarchy, using stubs to simulate the lower levels. The next lower level is then tested, and so on until all components have been tested.
Total Quality Management	A management seeking long-term organizational success by encouraging employee feedback and participation, satisfying customer needs and expectations, respecting societal values and beliefs, and obeying governmental statutes and regulations.
TPI	Test Process Improvement
TQM	Total Quality Management
Transaction Flow Driven Test	Similar to event driven testing, used for database systems.
U	Back to top
Unit Testing	Component testing. Testing of the smallest modules, such as functions or code modules. This may involve the development of test driver modules or test harnesses.
Usability Testing	Testing that a product is 'user-friendly' - that they can easily learn and use it.
User Acceptance Testing	Testing that a product is satisfactory to an end-user or customer.
V	Back to top
Variable
Validation	Checking the correctness of software development products - that they meet user needs and requirements. Validation ususally follows verification and requires actual testing.
Verification	Verification is the evaluation of a system or component to determine if they satisfy the conditions imposed at the start of that phase. Verification generally involves meetings and reviews to evaluate documents, plans, code, requirements, and specifications. Checklists, issues lists, walkthroughs, and inspection meetings may be used.
Volume Testing	Testing a system by subjecting it to large volumes of data.
W	Back to top
Walkthrough	An informal review of an object guided by its author, evaluating or enumerating requirements, designs or code.
WAS	Web Application Stress tool (Microsoft)
White Box Testing	Testing designed using knowledge of the application's code, testing statements, branches, paths, and conditions. Contrast with black box testing. See structural test case design.
X	Back to top
Y	Back to top
Z	Back to top
other	Back to top

Working draft of BS 7295-1 http://www.testingstandards.co.uk/bs_7925-1_online.htm

Other standards

ISO 8402:1986. Quality Vocabulary.

ISO/IEC 2382-1:1993. Data processing - Vocabulary - Part 01:Fundamental terms.

BS 6154:1981. Method of defining Syntactic Metalanguage.

Note, although this glossary is fairly heavily based on various standards, it is not a copy of any of them. If you want the glossary for a particular testing standard, you will need look elsewhere. Names of, and links to some sources of standards are included in this glossary.

Software Sue

Top Links

Testing Glossary

Other standards

Software Links