Complete Glossary Flashcards
https://www.istqb.org/component/jdownloads/send/20-istqb-glossary/105-release-notes-for-the-complete-glossary.html
Procedure to derive and/or select test cases based on an analysis of the specification, either functional or non-functional, of a component or system without reference to its
internal structure
.black-box test design technique
A black-box test design technique in which test cases are designed based on boundary values.
boundary value analysis
An experience-based test design technique whereby the experienced tester uses a high-level list of items to be noted, checked, or remembered, or a set of rules or criteria
against which a product has to be verified.
checklist-based testing
Simulated or actual operational testing by potential users/customers or an independent test team at the developers’ site, but outside the development organization. Alpha
testing is often employed for commercial off-the-shelf software as a form of internal acceptance testing.
alpha testing
A black-box test design technique in which test cases are designed to execute the combinations of inputs and/or stimuli (causes) shown in a decision table.
decision table testing
Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers, to determine whether or not a component or
system satisfies the user/customer needs and fits within the business processes. Beta testing is often employed as a form of external acceptance testing for commercial offthe-shelf software in order to acquire feedback from the market.
beta testing
A black-box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle, test cases are designed to cover each
partition at least once.
equivalence partitioning
A test design technique where the experience of the tester is used to anticipate what defects might be present in the component or system under test as a result of errors
made, and to design tests specifically to expose them.
error guessing
The set of generic and specific conditions, agreed upon with the stakeholders for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task
from being considered completed when there are still outstanding parts of the task which have not been finished. Exit criteria are used to report against and to plan when to
stop testing.
exit criteria
Procedure to derive and/or select test cases based on the tester’s experience, knowledge and intuition.
experience-based test design technique
The percentage of boundary values that have been exercised by a test suite.
boundary value coverage
A basic block that can be selected for execution based on a program construct in which one of two or more alternative program paths is available, e.g., case, jump, go to, ifthen-else.
branch
An informal test design technique where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design
new and better tests.
exploratory testing
A test case without concrete (implementation level) values for input data and expected results. Logical operators are used: instances of the actual values are not yet defined
and/or available.
high-level test case
A test case with concrete (implementation level) values for input data and expected results. Logical operators from high-level test cases are replaced by actual values that
correspond to the objectives of the logical operators.
low-level test case
A risk directly related to the test object.
product risk
The process of assessing identified project or product risks to determine their level of risk, typically by estimating their impact and probability of occurrence (likelihood).
risk analysis
The process of identifying risks using techniques such as brainstorming, checklists and failure history.
risk identification
A software tool that translates programs expressed in a high-order language into their machine language equivalents
compiler
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.
risk level
Systematic application of procedures and practices to the tasks of identifying, analyzing, prioritizing, and controlling risk.
risk management
The process through which decisions are reached and protective measures are implemented for reducing risks to, or maintaining risks within, specified levels.
risk mitigation
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.
risk-based testing
A black-box test design technique in which test cases are designed to execute valid and invalid state transitions.
state transition testing
An aggregation of hardware, software or both, that is designated for configuration management and treated as a single entity in the configuration management process.
configuration item
A statement of test objectives, and possibly test ideas about how to test. Test charters are used in exploratory testing.
test charter
Testing that runs test cases that failed the last time they were run, in order to verify the success of corrective actions.
confirmation testing
A sequence of events (paths) in the execution through a component or system
control flow
A form of static analysis based on a representation of unique paths (sequences of events) in the execution through a component or system. Control flow analysis evaluates the
integrity of control flow structures, looking for possible control flow anomalies such as closed loops or logically unreachable process steps.
control flow analysis
An abstract representation of all possible sequences of events (paths) in the execution through a component or system.
control flow graph
An approach to structure-based testing in which test cases are designed to execute specific sequences of events. Various techniques exist for control flow testing, e.g.,
decision testing, condition testing, and path testing, that each have their specific approach and level of control flow coverage.
control flow testing
An entity or property used as a basis for test coverage, e.g., equivalence partitions or code statements.
coverage item
The maximum number of linear, independent paths through a program. Cyclomatic complexity may be computed as L = N + 2P, where L = the number of edges/links in a
graph, N = the number of nodes in a graph, P = the number of disconnected parts of the graph (e.g., a called graph or subroutine).
cyclomatic complexity
The process of transforming general test objectives into tangible test conditions and test case
test design
The percentage of decision outcomes that have been exercised by a test suite. 100% decision coverage implies both 100% branch coverage and 100% statement coverage.
decision coverage
The result of a decision (which therefore determines the branches to be taken).
decision outcome
A white-box test design technique in which test cases are designed to execute decision outcomes.
decision testing
The number of defects identified in a component or system divided by the size of the component or system (expressed in standard measurement terms, e.g., lines-of-code,
number of classes or function points).
defect density
The number of defects found by a test level, divided by the number found by that test level and any other means afterwards.
Defect Detection Percentage (DDP)
The process of developing and prioritizing test procedures, creating test data and, optionally, preparing test harnesses and writing automated test scripts.
test implementation
A test management task that deals with the activities related to periodically checking the status of a test project. Reports are prepared that compare the actuals to that which
was planned.
test monitoring
A high-level description of the test levels to be performed and the testing within those levels for an organization or programme (one or more projects).
test strategy
A black-box test design technique in which test cases are designed to execute scenarios of use cases.
use case testing
The exit criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authorized entity.
acceptance criteria
he capability of the software product to be adapted for different specified environments without applying actions or means other than those provided for this purpose for the
software considered.
adaptability
The capability of the software product to be diagnosed for deficiencies or causes of failures in the software, or for the parts to be modified to be identified.
analyzability
An independent evaluation of software products or processes to ascertain compliance to standards, guidelines, specifications, and/or procedures based on objective criteria,
including documents that specify: the form or content of the products to be produced, the process by which the products shall be produced, and how compliance to standards
or guidelines shall be measured.
audit
The degree to which a component or system is operational and accessible when required for use. Often expressed as a percentage.
availability
An input value or output value which is on the edge of an equivalence partition or at the smallest incremental distance on either side of an edge, for example the minimum or
maximum value of a range.
boundary value
The percentage of branches that have been exercised by a test suite. 100% branch coverage implies both 100% decision coverage and 100% statement coverage.
branch coverage
A minimal software item that can be tested in isolatio
component
The assessment of change to the layers of development documentation, test documentation and components, in order to implement a given change to specified requirements.
impact analysis
The testing of individual software components.
component testing
The process of recognizing, investigating, taking action and disposing of incidents. It involves logging incidents, classifying them and identifying the impact.
incident management
A tool that facilitates the recording and status tracking of incidents. They often have workflow-oriented facilities to track and control the allocation, correction and re-testing of
incidents and provide reporting facilities.
incident management tool
A document reporting on any event that occurred, e.g., during the testing, which requires investigation.
incident report
A review not based on a formal (documented) procedure.
informal review
The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite.
coverage
A program point at which the control flow has two or more alternative routes. A node with two or more links to separate branches.
decision
A program point at which the control flow has two or more alt
A table showing combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects), which can be used to design test cases.
decision table
A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g., an incorrect statement or data definition. A defect, if
encountered during execution, may cause a failure of the component or system.
defect
The process of recognizing, investigating, taking action and disposing of defects. It involves recording defects, classifying them and identifying the impact.
defect management
A tool that facilitates the recording and status tracking of defects and changes. They often have workflow-oriented facilities to track and control the allocation, correction and retesting of defects and provide reporting facilities.
defect management tool
A test plan that typically addresses multiple test levels
master test plan
The set of generic and specific conditions for permitting a process to go forward with a defined task, e.g., test phase. The purpose of entry criteria is to prevent a task from
starting which would entail more (wasted) effort compared to the effort needed to remove the failed entry criteria.
entry criteria
A portion of an input or output domain for which the behavior of a component or system is assumed to be the same, based on the specification.
equivalence partition
The leader and main person responsible for an inspection or other review process.
moderator
The leader and main person responsible for an inspectio
A software tool or hardware device that runs concurrently with the component or system under test and supervises, records and/or analyzes the behavior of the component or
system.
monitoring tool
The behavior predicted by the specification, or another source, of the component or system under specified conditions.
expected result
Deviation of the component or system from its expected delivery, service or result
failure
A software development approach whereby lines of code (production and/or test) of a component are written by two programmers sitting at a single computer. This implicitly
means ongoing real-time code reviews are performed
pair programming
A review characterized by documented procedures and requirements, e.g., inspection.
formal review
The percentage of paths that have been exercised by a test suite.
path coverage
A review of a software work product by colleagues of the producer of the product for the purpose of identifying defects and improvements. Examples are inspection, technical
review and walkthrough.
peer review
testing based on an analysis of the specification of the functionality of a component or system
functional testing
Any event occurring that requires investigation
incident
A development lifecycle where a project is broken into a series of increments, each of which delivers a portion of the functionality in the overall project requirements. The
requirements are prioritized and delivered in priority order in the appropriate increment. In some (but not all) versions of this lifecycle model, each subproject follows a mini Vmodel with its own design, coding and testing phases.
incremental development model
A type of peer review that relies on visual examination of documents to detect defects, e.g., violations of development standards and non-conformance to higher level
documentation. The most formal review technique and therefore always based on a documented procedure.
inspection
