Istqb Glossary Report - Foundation (V3.01) -- Part 7

Front 1

risk assessment

Back 1

The process of identifying and subsequently analyzing the identified project or product risk to determine its level of risk, typically by assigning likelihood and impact ratings.

Front 2

risk level

Back 2

The importance of a risk as defined by its characteristics impact and likelihood. It can be used to determine the intensity of testing to be performed. It can be expressed either qualitatively (e.g., high, medium, low) or quantitatively.

Front 3

risk likelihood

Back 3

The estimated probability that a risk will become an actual outcome or event.

Front 4

risk management

Back 4

Systematic application of procedures and practices to the tasks of identifying, analyzing, prioritizing, and controlling risk.

Front 5

risk control

Back 5

The process through which decisions are reached and protective measures are implemented for reducing risks to, or maintaining risks within, specified levels.

Front 6

risk-based testing

Back 6

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.

Front 7

robustness

Back 7

The degree to which a component or system can function correctly in the presence of invalid inputs or stressful environmental conditions.

Front 8

robustness testing

Back 8

Testing to determine the robustness of the software product.

Front 9

root cause

Back 9

A source of a defect such that if it is removed, the occurrence of the defect type is decreased or removed.

Front 10

safety

Back 10

The capability of the software product to achieve acceptable levels of risk of harm to people, business, software, property or the environment in a specified context of use.

Front 11

recorder

Back 11

The person who records each defect mentioned and any suggestions for process improvement during a review meeting, on a logging form. This person should ensure that the logging form is readable and understandable.

Front 12

scripting language

Back 12

A programming language in which executable test scripts are written, used by a test execution tool (e.g., a capture/playback tool).

Front 13

security

Back 13

Attributes of software products that bear on its ability to prevent unauthorized access, whether accidental or deliberate, to programs and data.

Front 14

security testing

Back 14

Testing to determine the security of the software product.

Front 15

security testing tool

Back 15

A tool that provides support for testing security characteristics and vulnerabilities.

Front 16

security tool

Back 16

A tool that supports operational security.

Front 17

severity

Back 17

The degree of impact that a defect has on the development or operation of a component or system.

Front 18

simulation

Back 18

The representation of selected behavioral characteristics of one physical or abstract system by another system.

Front 19

simulator

Back 19

A device, computer program or system used during testing, which behaves or operates like a given system when provided with a set of controlled inputs.

Front 20

site acceptance testing

Back 20

Acceptance testing by users/customers at their site, to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes, normally including hardware as well as software.

Front 21

software

Back 21

Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.

Front 22

software integrity level

Back 22

The degree to which software complies or must comply with a set of stakeholder-selected software and/or software-based system characteristics (e.g., software complexity, risk assessment, safety level, security level, desired performance, reliability or cost) which are defined to reflect the importance of the software to its stakeholders.

Front 23

software lifecycle

Back 23

The period of time that begins when a software product is conceived and ends when the software is no longer available for use. It typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement phase. Note these phases may overlap or be performed iteratively.

Front 24

specification

Back 24

A document that specifies, ideally in a complete, precise and verifiable manner, the requirements, design, behavior, or other characteristics of a component or system, and, often, the procedures for determining whether these provisions have been satisfied.

Front 25

stability

Back 25

The capability of the software product to avoid unexpected effects from modifications in the software.

Front 26

standard

Back 26

Formal, possibly mandatory, set of requirements developed and used to prescribe consistent approaches to the way of working or to provide guidelines (e.g., ISO/IEC standards, IEEE standards, and organizational standards).

Front 27

standard-compliant testing

Back 27

Testing that complies to a set of requirements defined by a standard, e.g., an industry testing standard or a standard for testing safety-critical systems.

Front 28

state table

Back 28

A grid showing the resulting transitions for each state combined with each possible event, showing both valid and invalid transitions.

Front 29

state transition

Back 29

A transition between two states of a component or system.

Front 30

state transition testing

Back 30

A black-box test design technique in which test cases are designed to execute valid and invalid state transitions.