Home / TMap / Glossary

GLOSSARY


Acceptance test 
A test executed by the user(s) and manager(s) in an environment simulating the operational environment to the greatest possible extent, that should demonstrate that the developed system meets the functional and quality requirements.

Adaptive
The ability to split up an element into sub-elements that, in a different combination, result in a new, valuable element for the specific situation.

Basic technique
The method of deriving test situations from the test basis to achieve the required coverage type.

BDTM
Business driven test management is aimed at enabling the client to manage the test process on rational and economic grounds. Important BDTM aspects are: result, risk, time and cost.

Boundary value analysis
Test principle based on the fact that a test around a boundary has a greater chance to detect a defect.

Business case
The business case provides the economic justification for the project and answers the questions: why do we do this project, which investments are needed, what does the client wish to achieve with the result?

Central starting point
See Starting point.

Chain test
See End-to-end test.

Checklist (coverage type)
All the situations are tested that are summed up in an unstructured list.

Code review
A method of improving the quality of written code by evaluating the work against the specifications and/or guidelines and subjecting it to peer review.

Combined test
Test approach by which the system test and the functional acceptance test are combined to a single test level.

Completeness
The certainty that all inputs and changes are processed by the system.

Condition coverage
The possible outcomes of (“true” or “false”) for each condition are tested at least once.

Condition/decision coverage
The possible outcomes of each condition and of the decision are tested at least once. This implies both “condition coverage” and “decision coverage”.

Connectivity
How easy a link with a different information system or within the information system can be made and modified.

Continuity
The certainty that the information system will continue uninterruptedly, which means that it can be resumed within a reasonable time even after serious interruptions.

Correctness
The degree to which the system processes the input and changes entered correctly, in accordance with the specifications, to produce consistent data sets.

Coverage
Coverage is the ratio between that which can be tested and that which is tested with the test set.

Coverage ratio
The percentage of test situations, as defined by the coverage type, that is covered by the test.

Coverage type
The form in which the covering of test situations deducible from the test basis, is expressed.

Data controllability
The ease with which the correctness and completeness of the information (in the course of time) can be checked.

Decision coverage
The possible outcomes of the decision are tested at least once.

Decision point
A combination of one or more conditions that define the conditions for the various possibilities in the subsequent system behaviour.

Defect (fault)
The result of an error residing in the code or document.

Degradation factor
The ease with which the core of the information system can continue after a part has failed.

Driver
A simulation program that replaces a program that should take care of the control and/or the calling of the test object.

Dynamic testing
Testing by execution of the test object and/or the running of software.

Effectivity
The degree to which the information system meets the demands of the organisation and the profile of the end users for whom it is intended, as well as the degree to which the information system contributes to the achievement of business objectives.

Efficiency
The relationship between the performance level of the system (expressed in the transaction volume and overall speed) and the amount of resources (CPU cycles, I/O time, memory and network capacity, etc.) that are used.

End-to-end test
A test type where the end-to-end functionality of one or more systems is tested with end-to-end test cases.

Equivalence class
In the application of equivalence classes, the entire value range of a parameter is partitioned into classes, in which the system behaviour is similar (equivalent).

Error
Human mistake; this action takes place prior to any faults and/or failures.

Evaluation
Evaluation is assessing the intermediary products in the system development process.

Exploration Testing
Is the simultaneous learning, designing and executing of tests, in other words every form of testing in which the tester designs his tests during test execution and the information obtained is reused to design new and improved test cases.

Fail-over possibilities
The ease with which (part of) the information system can continue elsewhere.

Failure
The result or manifestation of one or more faults. When the system is performing differently from the required behaviour, from a viewpoint outside the system. Users will see the failure.

Fault (defect)
The result of an error residing in the code or document. Fault is the view from inside the system. Fault is the state where mistake or error exists. Developers will see the fault.

Flexibility
The degree to which the user may introduce extensions or modifications to the information system without changing the program itself. Or: the degree to which the system can be modified by the controlling organisation without being dependent on the IT department for maintenance.

FPA functions
Subdivision of user functions in FPA functions: logical set of data, links, input functions, output functions, reading functions. These FPA functions are the elementary building blocks to determine the functionality of a system.

Function point
Unit to measure the functionality and/or the size of application software.

Function point analysis (FPA)
A method aiming to measure the size of the functionality of an automated system. The measurement is independent of the technology. This measurement may be used as a base for the measurement of productivity, the estimation of the needed resources, and project control.

Functional acceptance test
A test carried out by the future user(s) in an optimally simulated production environment, with the aim of demonstrating that the developed system meets the functional requirements.

Functionality
The certainty that data processing is correct and complete, in accordance with the description in the functional specifications.

Generic Test Agreements
The overall approach for the setup and organisation of test processes that applies to more than one project or release. General agreements on e.g. the test process, standard strategy, estimating method, procedures, organisation, communication, documentation, etc.

Infrastructure (suitability of)
The suitability of hardware, network, systems software and DBMS for the application concerned and the degree to which the elements of this infrastructure interrelate.

Initial situation
Everything that is needed to prepare the system for receiving the required input. This includes not only the data that are needed for the processing, but also the condition in which the system and its environment must be. For instance, one might think of setting a specific system date, or running specific week and month batches that bring the system to a specific status.

Inspection
A formal evaluation technique, with products being read thoroughly by a group of experts. In addition to determining whether the solution is adequately processed, an inspection focuses primarily on achieving consensus on the quality of a product. The aim of the inspection is to help the author find as many deviations as possible in the available time.

Known errors
Defects that have been found but have not been solved (yet).

Logical test case
Describes, in logical terms, the circumstances in which the system behaviour is examined by indicating which test situations are covered by the test case.

Maintainability
The ease with which the information system can be adapted to new demands from the user, to changing external environments, or in order to correct defects.

Manageability
The effort needed to get and keep the information system in its operational state.

Master test plan
Test plan by which the various test levels are geared to one another.

Modified condition/decision coverage
Every possible outcome of a condition is the determinant of the outcome of the decision, at least once.

Multiple condition coverage
All the possible combinations of outcomes of conditions in a decision (therefore the complete decision table) are tested at least once. This implies “modified condition/decision coverage”.

Object part
A logically coherent part of the test object from the perspective of the characteristic to be tested.

Online
Function mode of an information system in which the information system immediately processes the commands and directly shows the answer (output) on the screen (or otherwise).

Orthogonal array
An orthogonal array LN(sk, t) is a 2-dimensional array of N rows and k columns consisting of elements that can assume s values, whereby every combination of t columns contains all the combinations of the s values in equal proportion.

Pairwise testing
Tests all the possibilities of any combination of 2 factors.

Performance
The speed with which the information system processes interactive and batch transactions.

Permanent test organisation
A line organisation that offers test services.

Physical test case
The concrete elaboration of a logical test case, with choices having been made for the values of all required the input and settings of the environmental factors.

Portability
The diversity of the hardware and software platforms on which the information system can run, and how easy it is to transfer the system from one environment to another.

Pre-test
Testing the delivered product in such a way that it is determined whether or not the product is of sufficient quality to execute a complete test of this product.

Product risk
The chance that the product fails in relation to the expected damage if this occurs:
Product risk = Chance of failure * Damage where Chance of failure = Chance of defects * Frequency of use

Product risk analysis
Analysing the product to be tested with the aim of achieving a joint view, for the test manager and other stakeholders, of the more or less risky characteristics and parts of the product to be tested so that the thoroughness of testing can be related to this view.

Production acceptance test
A test carried out by the future administrator(s) in an optimally simulated production environment, with the aim of demonstrating that the developed system meets the requirements set by system management.

Quality
The totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs.

Quality assurance
All the planned and systematic activities necessary to provide adequate confidence that a product or service meets the requirements for quality.

Quality characteristic
A quality characteristic describes a property of an information system.

Recoverability
The ease and speed with which the information system can be restored after an interruption. 

Regression
Regression is the phenomenon that the quality of a system deteriorates as a whole as a result of individual amendments.

Regression test
A regression test is aimed at verifying that all the unchanged parts of a system still function correctly after the implementation of a change.

Reliability
The degree to which the information system remains free from interruptions.

Reusability
The degree to which parts of the information system, or the design, can be reused for the development of different applications.

Review
An evaluation technique where a product (60-80% complete) is submitted to a number of reviewers with the question to assess it from a certain perspective (depending on the review type). A review focuses primarily on finding courses for a solution on the basis of the knowledge and competencies of the reviewers, and on finding and correcting defects. There are various review types, such as: technical review (e.g. selecting solution direction/alternative), management review (e.g. determining project status), peer review (review by colleagues), and expert review (review by experts).

Risk reporting
A description of the extent to which the system meets the specified quality requirements and the risks associated with bringing a particular version into production, including any available alternatives.

Robustness
The degree to which the information system proceeds as usual even after an interruption.

Role 
Describes one or more tasks and the knowledge and skills required to carry them out.

Security
The certainty that data can be viewed and changed only by those who are authorized to do so.

Starting point
Initial situations often contain the same data for several test cases. Such data are therefore included in a so-called starting point for the entire test and not separated for each test case. It is called a central starting point if this is intended for more tests or testers.

Static testing
Testing by examining products (such as manuals or source code) without any programs being executed.

Stub
A simulation program.

Suitability
The degree to which manual procedures match the automated information system and the fitness for use of these manual procedures for the organisation.

System integration test
A test carried out by the future user(s) in an optimally simulated production environment, with the aim of demonstrating that (sub)system interface agreements have been met, correctly interpreted and correctly implemented.

System management
System management is responsible for technical operation of the software in its intended infrastructure in production.

System test
A test carried out by the supplier in a (manageable) laboratory environment, with the aim of demonstrating that the developed system, or parts of it, meet with the functional and non-functional specifications and the technical design.

Test basis
The test basis is the information that defines the required system behaviour.

Test case
Used to examine whether the system displays the desired behaviour under specific circumstances.

Test depth level
Test depth level N = the certainty that all the combinations of N consecutive paths are covered.

Test design technique
A standardised method of deriving test cases from a particular test basis that will achieve a certain coverage.

Test environment
A composition of parts, such as hardware and software, connections, environment data, maintenance tools and management processes in which a test is carried out.

Test goal
A goal that, for the client, is relevant for testing, often formulated in terms of business processes supported by IT, realised user requirements or use cases, critical success factors, change proposals or cited risks to be covered.

Test harness
A collection of software and test data configured for a development environment with the purpose of dynamically testing one unit or a series of units, whereby the behaviour and output are checked.

Test infrastructure
Consists of the facilities and resources necessary to facilitate the satisfactory execution of the test. A distinction is made between test environments, test tools and workplaces.

Test level
A test level is a group of test activities that are managed and executed collectively.

Test line
The operational organisation to provide test services to one or more clients. A test line has a fixed team of testers, infrastructure, test tools and standardised work procedures.

Test object
The test object is the information system (or part thereof) to be tested.

Test organisation
The whole of the test functions, facilities, procedures and activities including their relationships.

Test pattern
A general solution for a specific recurring test problem.

Test plan
In a test plan the general structure and the strategic choices with respect to the test to be executed are formulated. The test plan forms the scope of reference during the execution of the test and also serves as an instrument to communicate with the client of the test. The test plan is a description of the test project, including a description of the activities and the planning; therefore it is not a description of the tests themselves.

Test point
Unit of measurement for the size of the high-level test to be executed.

Test point analysis (TPA)
A method with the possibility to perform a technology-independent measurement of the test depth level of an information system, on the basis of a function point analysis, and to use this measurement as a basis for a productivity measurement, an estimate of the required resources, and project management.

Test policy
Describes how an organisation deals with the people, resources and methods involved with the test process in the various situations.

Test process
The collection of tools, techniques and working methods used to perform a test.

Test script
Combines multiple physical test cases to be able to execute them in an efficient and simple manner.

Test situation
An isolated condition under which the test object displays a specific behaviour that needs to be tested.

Test strategy
The distribution of the test effort and coverage over the parts to be tested or aspects of the test object aimed at finding the most important defects as early and cheaply as possible.

Test team
A group of people who, led by a test manager, undertake test activities.

Test technique
A set of actions aimed at creating a test deliverable by a universal method.

Test tool
An automated instrument that supports one or more test activities, such as planning, control, specification and execution.

Test tool policy
Describes how an organisation handles the acquisition, implementation and use of test tools in the various situations.

Test type 
A group of test activities with the intention of checking the information system in respect of a number of correlated (part aspects of) quality characteristics.

Test unit
A collection of processes, transactions and/or functions that are tested collectively.

Testability
The ease and speed with which characteristics of the system can be tested (following each adjustment).

Testability review
The detailed check of the test basis on testability.

Testing
Testing is a process that provides insight into, and advice on, quality and the related risks.

Testing (ISO)
Technical operation that consists of the determination of one or more characteristics of a given product, process or service according to a specified procedure [ISO/IEC Guide 2, 1991].

Testware
All the test documentation produced in the course of the test process that can be used for maintenance purposes and that should therefore be transferable and maintainable.

Unit integration test
A test carried out by the developer in the development environment, with the aim of demonstrating that a logical group of units meets the requirements defined in the technical specifications.

Unit test
A test carried out in the development environment by the developer, with the aim of demonstrating that a unit meets the requirements defined in the technical specifications.

User function
A property recognized by the user which the delivered product should meet. Generally speaking the user functions may best be described as objects and processes.

User-friendliness
How easy it is for end users to use the system. This general definition is often divided into how easy it is for end users to learn to work with the information system, and how easy it is to work with for trained users.

Users acceptance test
A test carried out by the future user(s) in an optimally simulated production environment, with the aim of demonstrating that the developed system meets the requirements of the users.

Walkthrough 
An evaluation technique by which the author explains the contents of a product during a meeting. Several different objectives are possible: bringing all participants to the same starting point, transfer of information, asking the participants for additional information or letting the participants choose from the alternatives proposed by the author.


International Copyright © Sogeti Legal Notice