Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

2018 ISTQB Foundation Level Mock Exams > Complete Glossary > Flashcards

Complete Glossary Flashcards

https://www.istqb.org/component/jdownloads/send/20-istqb-glossary/105-release-notes-for-the-complete-glossary.html

1
Q

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

A

.black-box test design technique

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

A black-box test design technique in which test cases are designed based on boundary values.

A

boundary value analysis

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

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.

A

checklist-based testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

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.

A

alpha testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

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.

A

decision table testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

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.

A

beta testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

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.

A

equivalence partitioning

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

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.

A

error guessing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

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.

A

exit criteria

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Procedure to derive and/or select test cases based on the tester’s experience, knowledge and intuition.

A

experience-based test design technique

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

The percentage of boundary values that have been exercised by a test suite.

A

boundary value coverage

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

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.

A

branch

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

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.

A

exploratory testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

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.

A

high-level test case

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

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.

A

low-level test case

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

A risk directly related to the test object.

A

product risk

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

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).

A

risk analysis

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

The process of identifying risks using techniques such as brainstorming, checklists and failure history.

A

risk identification

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

A software tool that translates programs expressed in a high-order language into their machine language equivalents

A

compiler

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

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.

A

risk level

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

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

A

risk management

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

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

A

risk mitigation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

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.

A

risk-based testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

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

A

state transition testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

An aggregation of hardware, software or both, that is designated for configuration management and treated as a single entity in the configuration management process.

A

configuration item

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

A statement of test objectives, and possibly test ideas about how to test. Test charters are used in exploratory testing.

A

test charter

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Testing that runs test cases that failed the last time they were run, in order to verify the success of corrective actions.

A

confirmation testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

A sequence of events (paths) in the execution through a component or system

A

control flow

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

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.

A

control flow analysis

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

An abstract representation of all possible sequences of events (paths) in the execution through a component or system.

A

control flow graph

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

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.

A

control flow testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

An entity or property used as a basis for test coverage, e.g., equivalence partitions or code statements.

A

coverage item

33
Q

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).

A

cyclomatic complexity

34
Q

The process of transforming general test objectives into tangible test conditions and test case

A

test design

35
Q

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.

A

decision coverage

36
Q

The result of a decision (which therefore determines the branches to be taken).

A

decision outcome

37
Q

A white-box test design technique in which test cases are designed to execute decision outcomes.

A

decision testing

38
Q

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).

A

defect density

39
Q

The number of defects found by a test level, divided by the number found by that test level and any other means afterwards.

A

Defect Detection Percentage (DDP)

40
Q

The process of developing and prioritizing test procedures, creating test data and, optionally, preparing test harnesses and writing automated test scripts.

A

test implementation

41
Q

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.

A

test monitoring

42
Q

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).

A

test strategy

43
Q

A black-box test design technique in which test cases are designed to execute scenarios of use cases.

A

use case testing

44
Q

The exit criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authorized entity.

A

acceptance criteria

45
Q

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.

A

adaptability

46
Q

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.

A

analyzability

47
Q

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.

A

audit

48
Q

The degree to which a component or system is operational and accessible when required for use. Often expressed as a percentage.

A

availability

49
Q

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.

A

boundary value

50
Q

The percentage of branches that have been exercised by a test suite. 100% branch coverage implies both 100% decision coverage and 100% statement coverage.

A

branch coverage

51
Q

A minimal software item that can be tested in isolatio

A

component

52
Q

The assessment of change to the layers of development documentation, test documentation and components, in order to implement a given change to specified requirements.

A

impact analysis

53
Q

The testing of individual software components.

A

component testing

54
Q

The process of recognizing, investigating, taking action and disposing of incidents. It involves logging incidents, classifying them and identifying the impact.

A

incident management

55
Q

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.

A

incident management tool

56
Q

A document reporting on any event that occurred, e.g., during the testing, which requires investigation.

A

incident report

57
Q

A review not based on a formal (documented) procedure.

A

informal review

58
Q

The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite.

A

coverage

59
Q

A program point at which the control flow has two or more alternative routes. A node with two or more links to separate branches.

A

decision

A program point at which the control flow has two or more alt

60
Q

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.

A

decision table

61
Q

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.

A

defect

62
Q

The process of recognizing, investigating, taking action and disposing of defects. It involves recording defects, classifying them and identifying the impact.

A

defect management

63
Q

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.

A

defect management tool

64
Q

A test plan that typically addresses multiple test levels

A

master test plan

65
Q

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.

A

entry criteria

66
Q

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.

A

equivalence partition

67
Q

The leader and main person responsible for an inspection or other review process.

A

moderator

The leader and main person responsible for an inspectio

68
Q

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.

A

monitoring tool

69
Q

The behavior predicted by the specification, or another source, of the component or system under specified conditions.

A

expected result

70
Q

Deviation of the component or system from its expected delivery, service or result

A

failure

71
Q

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

A

pair programming

72
Q

A review characterized by documented procedures and requirements, e.g., inspection.

A

formal review

73
Q

The percentage of paths that have been exercised by a test suite.

A

path coverage

74
Q

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.

A

peer review

75
Q

testing based on an analysis of the specification of the functionality of a component or system

A

functional testing

76
Q

Any event occurring that requires investigation

A

incident

77
Q

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.

A

incremental development model

78
Q

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.

A

inspection

2018 ISTQB Foundation Level Mock Exams (12 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions