Terms with letter "T"

Target state

Refers to the state in which software applications or components should be adter a test case with reference to the original speculation or other sources.

The target state needs to be defined for each test case.

Technical review

This kind of review is a systematic evaluation of a software application carried out by several members of staff, each with an equal say in the process. Their task is to check whether the application is being developed appropriately to carry out its intended function; they look for divergences from the specification and standards.

Technical reviews are also referred to as peer reviews.

Test/testing

Test and testing refer in this context to the following:

• the whole process of systematically executing software with the aim of proving that it fulfills all requirements adequately, or in order to uncover specific defects and faults;
• each execution of the software application being testing under specific conditions with the aim of comparing results with the attributes expected; these tests are usually randomized.
• testing as a general term means all tasks and steps in the software testing process.

See the Wikipedia entry on software testing for a detailed explanation of all aspects of testing.

Test comparator

This is an automatic tool for measuring the actual results of a test against the expected ones.

Test case leading to error

This is the terms for a test case which shows up a discrepancy or unexpected behaviour and thus detects a fault.

Test coverage

See coverage.

Test effort

Refers to the resources that will be required/are being planned on in order to carry out testing. Testing requires human resources, hard- and software and considerations of quality, testability and strategy influence the amount of effort required.

Cf. Wikipedia test effort.

Test evaluation

In this process, test logs are examined to show up faults and defects which are then categorised.

Test automation

Refers to using software support in the test process: i.e. to produce and program test cases, or to implement tests automatically at set intervals.

Software used in testing is usually refered to as a test automation tool.

Cf. Wikipedia entry on test automation.

Testability

Refers to the following:

• the ease with which a software application can be tested, including after each time the software in question has been updated;
• access to the software to be tested for testing - this includes an evaluation of how accessible test interfaces are, how good documentation is, how easily the program and smaller testable components can be separated and tested and to which degree a realistic operating environment can be simulated.

Test basis

This is composed of all documents in which test object requirements are described. Test basis documentation can also refer to all documentation from which an actual test case is derived.

Test summary report

This document summarizes all test activities and results, producing an overall evaluation of the software application which was tested.

Test data

Refers to descriptive values or input for software being tested, as well as the target values which should result from the test case.

Test execution

Executing a test case or a test scenario as part of a testing process.

Test exit criteria

These are made up of the following:

• conditions set before execution which must be fulfilled for a test case or process to be considered closed; a test coverage value might be used, for example;
• a general list of conditions (both generic and specific to the test process at hand) which are agreed on by all participants as being exit criteria, the aim being to make sure the test process is only terminated once all parts of it the task have been completed.

Test unit

A Test unit exists in order to group test cases. When operating with a large number of test cases, it is advisable to group test cases together, e.g. place all logically related test cases into one group.

Test units can be nested as and where needed and each test unit can contain an unlimited number of test cases. Test units are in a way similar to folders inside Windows Explorer which group files (for Zeta Test: test cases) together.

Tester

This is a skilled professional who works in testing software, especially in terms of carrying out tests and reporting results. Testers also have experience of the area in which the software being tested is going to be used.

Generally, however, the word tester can be used to refer to all people involved in the test process.

Test results

Refers to all documents produced during a test process; they may lead either to the release or rejection of a software application as a function of the amount of defects and faults they document.

Test case

A test case is a specific description of a single test to be carried out. A test plan usually contains many test cases that are carried out one after each other (or in a random order) by a tester.

A test case is always contained within a test unit.

Test cases are created globally, i.e. all test units created are independent of any specific test plan. Test cases are assigned to units when selecting them for a specific test plan.

Read more about test cases.

Test case explosion

This is what happens when, as test parameters are pushed outwards, the number of test cases developed increases exponentially, along with the effort required for a comprehensive test.

Test case specification

This document defines a number of tests for a test object, including test data, test preconditions and test post-conditions.

The accepted standard for this process is the IEEE 829 Standard for Software Test Documentation (Wikipedia).

Test-first programming

A method of software development in which the result to be achieved is defined by completion of a test case before code programming begins; it is used for comparatively small projects.

This way of working is often known as test-first design or test-first development. Cf. test-driven development on Wikipedia.

Test infrastructure

This refers to all components required to execute test projects. Normally, the following points are included under test infrastructure:

• work-stations for testers
• hardware and software
• test environments
• further tools (e-mail, browser, word processing, etc).

Test plan

This document describes the operational procedure to be followed during testing, the resources allocated and the time scale for the project - including all related activities (i.e. not just raw testing but meetings, handovers and other tasks).

See IEEE 829 Standard for Software Test Documentation (Wikipedia) for further information.

Test execution

This refers to the carrying out of one or more test cases on any one given version of a software application.

Test management

This can mean either:

• planning: estimating effort and resources required, running and evaluating test-related activities - usually carried out by a test manager;

or,

• people: the manangement team responsible for testing.

Test method

The term test method refers to a way of testing that has been planned and is applied both to the conception and selection of test cases, as well as the way in which they are carried out.

Testware

This refers to all material produced during a testing project for software applications; by extension, it covers all tools needed to plan, design and execute tests.

Due to the fact that all documents and tools involved must be available for reuse in post-release maintenance and upkeep of software, they must all be transferable and updatable.

Test metric

The measurable attribute in a test case or testing project, given along with the unit in which it has been measured.

Test object

This refers to the software application or component that is to undergo testing. A test object is not the software as a whole, but always a specified version.

Test oracle

This is tool or source used to fix expected or target results for test cases - e.g. requirements may be used as test oracles.

Test phase

Refers to groups of test activities related by their content or focus which, once accomplish, result in the completion of a quantifiable piece of work - e.g. a test specification, a system test, or test reports

Test plan

A Test plan is a concrete description of test cases to perform, as well as their results. Test plans can be grouped inside test folders, although this is usually unnecessary for small projects, where they can added directly to the root.

Read more about test plans here.

Test planning

Activities related to producing a fixed test plan.

Test log

This sequential record of test exection is kept in writing and records not just the course of the test, but also the results produced. Automatic test tools usually produce an automatic test log.

A test log must show which parts of a test object were tested, by who, to what degree and the results of this.

See IEEE 829 Software Test Documentation on Wikipedia.

Test logging

Refers to the process of producing a test log - i.e. information about tests execution. Test logging is often carried out automatically during a test by software tools.

Test process

Refers to a set of sequential activities that structure a test project: planning, design, analysis, control, implementation, execution, evaluation and reporting as well as closing the test project once it is complete.

Test harness/bed

A collection of all programs, stubs and drivers needed to conduct and evaluate a test and record it in test logs.

Cf. testbed on Wikipedia.

Test robot

Refers to tools used to execute tests by entering software through open or accessible interfaces - e.g. test robots can enter inputs via GUI and then record reactions.

Test interface

See point of control (PoC) and point of observation (PoO) for exact descriptions of test interfaces.

Test suite/sequence

A series of test cases in which the post-condition of the previous test is the precondition for the following one.

Our Zeta Test software refers to this a test unit. A test unit can be used to group several cases and can also contain sub test-units in a tree structure.

Test script

Contains commands for an automated test case or test suite; a test script is written in a suitable programming language.

A test script can affect overriding processes carried out by other test tools.

Test strategy

Encompasses the following:

• the way in which test effort is spread to cover various objects or to uphold quality standards in a software application being tested; single test methods are chosen and the order in which they are executed, the way in which they interact and the target coverage defined;
• abstract design of test structure along with entry and exit criteria; usually, this kind of test strategy can be adapted to different test projects.

Test level/stage

Refers to sets of test-related activities that are grouped together and managed as levels; test stages can then be assigned to the responsibility of various members of staff.

The the V-model defines the following test levels:

• Component testing (module tests, unit tests)
• Integration testing
• System testing
• Acceptance test

Test scenario

This is a grouping of different test suites.

Driver

A software tool used to run a test object, to input test data and to receive output and reactions.

Test environment

Refers to the entire spectrum of hard- and software components required to run test cases on a software application.

Test process

See test method.

Some well known rest process are:

• Control-flow testing
• Dynamic software testing
• Static software testing
• Statistical testing

Test procedure specification

Refers to:

• detailed instructions relating to the preparation, implementation and evaluation of a test case;
• a document describing a series of tasks which amount to instructions for carrying out a test.

Test aim/goal

The general aim behind all testing is discovering faults. More specifically, the operational aim of all testing is to develop custom test cases in order to show up specific faults.

Test goals can also be specific results expected of functioning software after the execution of a given test case.

Test cycle

A series of test cases is referred to as a test cycle; most frequently, this means having implemented a test method on a certain version of a software application, resulting in requests for corrections or changes to the software developers.

Unreachable code (dead code)

Refers to source code that cannot be executed and is impossible to reach through other sections of code.