- Target state
- Technical review
- Test comparator
- Test case leading to error
- Test coverage
- Test effort
- Test evaluation
- Test automation
- Test basis
- Test summary report
- Test data
- Test execution
- Test exit criteria
- Test unit
- Test results
- Test case
- Test case explosion
- Test case specification
- Test-first programming
- Test infrastructure
- Test plan
- Test execution
- Test management
- Test method
- Test metric
- Test object
- Test oracle
- Test phase
- Test plan
- Test planning
- Test log
- Test logging
- Test process
- Test harness/bed
- Test robot
- Test interface
- Test suite/sequence
- Test script
- Test strategy
- Test level/stage
- Test scenario
- Test environment
- Test process
- Test procedure specification
- Test aim/goal
- Test cycle
- Unreachable code (dead code)
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.
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 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.
This is an automatic tool for measuring the actual results of a test against the expected ones.
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.
In this process, test logs are examined to show up faults and defects which are then categorised.
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.
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.
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.
Refers to descriptive values or input for software being tested, as well as the target values which should result from the test case.
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.
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.
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.
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.
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.
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).
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.
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).
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.
This refers to the carrying out of one or more test cases on any one given version of a software application.
This can mean either:
- planning: estimating effort and resources required, running and evaluating test-related activities - usually carried out by a test manager;
- people: the manangement team responsible for testing.
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.
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.
The measurable attribute in a test case or testing project, given along with the unit in which it has been measured.
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.
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.
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.
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.
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.
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.
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.
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.
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
This is a grouping of different test suites.
A software tool used to run a test object, to input test data and to receive output and reactions.
Refers to the entire spectrum of hard- and software components required to run test cases on a software application.
Test procedure specification
- 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.
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.
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.