- Safety-critical system
- Safety testing
- Simulator
- Single condition coverage
- Smoke test
- Software development process
- Software object
- Specification
- Standard software
- Statement
- State transition testing
- Statement coverage
- Static analysis
- Static testing
- Stub
- Stress testing
- Structural testing
- Syntax testing
- System Integration Testing (SIT)
- System testing
Safety-critical system
Refers to a software system whose failure or serious malfunction could lead to death or serious injury to people or cause severe loss or damages.
Safety testing
This is a series of tests designed to uncover safety flaws in programs, especially in terms of unauthorised access and data protection.
Simulator
Refers to the following:
- a tool used to simulate the environment in which a product will be used, primarily for test purposes;
- a simulation on another system of selected behaviours of a software system being tested.
For broader information on the term, see Wikipedia on simulation.
Single condition coverage
This is a part of white-box testing whereby each single condition in every decision statement has to be tested as true or false.
Smoke test
A smoke test is usually automated and covers a selected range of defined or planned test cases with the aim of making sure that all main functions of a software application or component are working to satisfaction. Finer details are ignored in this process.
Smoke tests are often conducted without comparisons to target results; the aim is to produce and recognise obvious mistakes or defects - e.g. in case of a program crash. A smoke test is therefore often reliant on cases from negative testing.
See smoke testing on Wikipedia for further information.
Software development process
This is a structure defining which tasks fall to which persons/roles at which point in time and in which order during software development. Furthermore, target results are set and then quality assurance used to check on progress towards them.
See software development process on Wikipedia for a good summary.
Software object
Describes an achievement within a software development process which is recognisable as such - e.g. source code or a document of some sort.
Specification
This is a document containing a formal description of the requirements a software product is expected to fill along with its structure, behaviour and characteristics. Ideally, a specification is exact, complete and specific enough to be used a basis for testing after product development.
The specification acts as the basis for developers in the programming stage and for testers designing black-box test scenarios. Sometimes specifications even contain instructions as to who suitability to requirements should be tested.
Cf. Spezifikation on Wikipedia.
Standard software
This is a software application developed for the mass market and distributed to a large number of customers in identlical form.
Standard software is often configured as it is introduced, which is refered to as customising: in this process, the exact configuration of components or small additions to the software allow it to be tailored down to the customer.
It is the opposite of custom (bespoke) software.
Statement
A syntactical entity in programming language - e.g. a function seleciton; a statement is typically the smallest indivisible unit of execution.State transition testing
In this approach to black-box testing, also called finite state testing, test cases are designed to execute state transitions - both valid and invalid.
Statement coverage
This is an approach to testing whereby the test flow checks that each statement in the test object has been carried out at least once. In this approach, each test sequence results in a number showing the percentage of statements that were activated in its course.Static analysis
Also know as static code analysis, this analysis of a program is carried out by checking, measuring and depicting software coding before it is actually executed - e.g. statements or source codes are analysed.
Cf. Wikipedia on static code analyse.
Static testing
In this approach to testing, software applications or components are tested withouth the software actually being executed; instead, reviews and/or static analyses are used.
Cf. Wikipedia entry on static software testing.
Stub
Stubs (full name: method stub) are used in component testing and Integration testing in order to simulate components on which the software will be dependent but that are not yet ready.
Cf. method stub on Wikipedia.
Stress testing
This approach to testing puts software beyond the capacity at which is it expected to perform optimally, or diminishes the resources to which it has access, in order to see how it behaves.
A typical way of achieving this is to increase the number of simultaneous users or to up the number of transactions. The overall aim to define the maximum limits and loads at which the system can operate - i.e. to determine robustness.
Cf. stress testing on Wikipedia.
Structural testing
This is a form of white-box testing in which the test cases take account of the internal structure of the software application being tested. Furthermore, structural elements (i.e. branches, paths/walks, data) are used in order to supervise the the coverage achieved by the testing.
Cf. control-flow-based and data-flow testing.
Syntax testing
An approach to testing (black-box) in which test cases are derived from formal specifications about the syntax for input and output.
System Integration Testing (SIT)
This form of testing is about checking the entire software system in terms of its performance and the completeness of its functionality.
System testing
The aim of this form of testing is to ascertain whether an integrated software system (i.e. with several different components) fulfills requirements; system testing is usually carried out by the contractor in a test environment using test data.
See also system testing on Wikipedia for detailed information.