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:
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:
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.
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.
These are made up of the following:
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.
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.
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:
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:
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.
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:
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:
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.
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.
Refers to source code that cannot be executed and is impossible to reach through other sections of code.