Het vakgebied Software Testen maakt gebruik van een internationaal jargon, waar de International Software Testing Qualifications Board (ISTQB) een rol speelt in het handhaven van een consistente uitleg van de termen en begrippen. We hebben voor u een doorzoekbaar mechanisme gerealiseerd waarmee u niet alleen de woorden kunt vinden, maar ook de definities ervan kunt doorzoeken.
Mocht u een begrip of definitie missen, laat het ons dan weten.
Standard Glossary of Terms used in Software Testing
Er zijn 42 termen in deze lijst die beginnen met de letter R.
See Rational Unified Process.
A factor that could result in future negative consequences; usually expressed as impact and likelihood.
The consequence/outcome of the execution of a test. It includes outputs to screens, changes to data, reports, and communication messages sent out. See also actual result, expected result.
An evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements. Examples include management review, informal review, technical review, inspection, and walkthrough. [After IEEE 1028]
The person involved in the review that identifies and describes anomalies in the product or project under review. Reviewers can be chosen to represent different viewpoints and roles in the review process.
A set of risks grouped by one or more common factors such as a quality attribute, cause, location, or potential effect of risk;. A specific set of product risk types is related to the type of testing that can mitigate (control) that risk type. For example the risk of user-interactions being misunderstood can be mitigated by usability testing.
A black box test design technique where test cases are selected, possibly using a pseudo-random generation algorithm, to match an operational profile. This technique can be used for testing non-functional attributes such as reliability and performance.
Rational Unified Process
A proprietary adaptable iterative software development process framework consisting of four project lifecycle phases: inception, elaboration, construction and transition.
Testing that runs test cases that failed the last time they were run, in order to verify the success of corrective actions.
See capture/playback tool.
The capability of the software product to re-establish a specified level of performance and recover the data directly affected in case of failure. [ISO 9126] See also reliability.
The process of testing to determine the recoverability of a software product. See also reliability testing.
See recoverability testing.
Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed.
See compliance testing.
A document identifying test items, their configuration, current status and other delivery information delivered by development to testing, and possibly other stakeholders, at the start of a test execution phase. [After IEEE 829]
The ability of the software product to perform its required functions under stated conditions for a specified period of time, or for a specified number of operations. [ISO 9126]
reliability growth model
A model that shows the growth in reliability over time during continuous testing of a component or system as a result of the removal of defects that result in reliability failures.
The process of testing to determine the reliability of a software product.
The capability of the software product to be used in place of another specified software product for the same purpose in the same environment. [ISO 9126] See also portability.
A condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. [After IEEE 610]
An approach to testing in which test cases are designed based on test objectives and test conditions derived from requirements, e.g. tests that exercise specific functions or probe non-functional attributes such as reliability or usability.
requirements management tool
A tool that supports the recording of requirements, requirements attributes (e.g. priority, knowledge responsible) and annotation, and facilitates traceability through layers of requirements and requirements change management. Some requirements management tools also provide facilities for static analysis, such as consistency checking and violations to pre-defined requirements rules.
The period of time in the software lifecycle during which the requirements for a software product are defined and documented. [IEEE 610]
The capability of the software product to use appropriate amounts and types of resources, for example the amounts of main and secondary memory used by the program and the sizes of required temporary or overflow files, when the software performs its function under stated conditions. [After ISO 9126] See also efficiency.
resource utilization testing
The process of testing to determine the resource-utilization of a software product. See also efficiency testing.
The testing activities that must be repeated when testing is re-started after a suspension. [After IEEE 829]
A meeting at the end of a project during which the project team members evaluate the project and learn lessons that can be applied to the next project.
A tool that provides support to the review process. Typical features include review planning and tracking support, communication support, collaborative reviews and a repository for collecting and reporting of metrics.
The process of assessing identified risks to estimate their impact and probability of occurrence (likelihood).
See risk type.
The process through which decisions are reached and protective measures are implemented for reducing risks to, or maintaining risks within, specified levels.
The process of identifying risks using techniques such as brainstorming, checklists and failure history.
The importance of a risk as defined by its characteristics impact and likelihood. The level of risk can be used to determine the intensity of testing to be performed. A risk level can be expressed either qualitatively (e.g. high, medium, low) or quantitatively.
Systematic application of procedures and practices to the tasks of identifying, analyzing, prioritizing, and controlling risk.
See risk control.
An approach to testing to reduce the level of product risks and inform stakeholders of their status, starting in the initial stages of a project. It involves the identification of product risks and the use of risk levels to guide the test process.
The degree to which a component or system can function correctly in the presence of invalid inputs or stressful environmental conditions. [IEEE 610] See also error-tolerance, fault-tolerance.
Testing to determine the robustness of the software product.
A source of a defect such that if it is removed, the occurence of the defect type is decreased or removed. [CMMI]
root cause analysis
An analysis technique aimed at identifying the root causes of defects. By directing corrective measures at root causes, it is hoped that the likelihood of defect recurrence will be minimized.