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.
This is a series of tests designed to uncover safety flaws in programs, especially in terms of unauthorised access and data protection.
Refers to the following:
For broader information on the term, see Wikipedia on simulation.
This is a part of white-box testing whereby each single condition in every decision statement has to be tested as true or false.
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.
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.
Describes an achievement within a software development process which is recognisable as such - e.g. source code or a document of some sort.
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.
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.
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.
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.
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.
An approach to testing (black-box) in which test cases are derived from formal specifications about the syntax for input and output.
This form of testing is about checking the entire software system in terms of its performance and the completeness of its functionality.
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.