Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

ISTQB-CTFL Certified Tester > ISTQB-CTFL-CT Definitions > Flashcards

ISTQB-CTFL-CT Definitions Flashcards

(107 cards)

Start Studying
1
Q

Acceptance testing

A

Formal testing with respect to user needs, requirements and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers, or other authorized entities to determine whether or not to accept the system.

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

Ad-hoc review

A

A review in which reviewers are provided with little to no guidance, read the work product sequentially, identifying and documenting issues as they encounter them.

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

Alpha testing

A

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 off-the-shelf software as a form of internal acceptance testing

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

Beta testing

A

Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers, to determine whether 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 off-the-shelf software to acquire feedback from the market

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

Black-box test technique

A

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.

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

Boundary value analysis

A

A black box test design technique in which test cases are designed based on boundary values (input or output values 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).

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

Change-related testing

A

Testing done to confirm that changes to a component or system have not caused any unforeseen adverse consequences

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

Checklist-based review

A

A review in which reviewers detect issues based on systematic checklist distributed at the review initiation

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

Commercial off-the-shelf (COTS)

A

A software product that is developed for the general market, i.e. for a large number of customers, and that is delivered to many customers in identical format

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

Component integration testing

A

Testing performed to expose defects in the interfaces and interaction between integrated components

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

Component testing

A

The testing of individual software components

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

Configuration management

A

A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, and record and report change processing and implementation status, and verify compliance with specified requirements.

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

Confirmation testing

A

(or “re-testing”) Testing that runs test cases that failed the last time they were run, in order to verify the success of corrective action.

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

Contractual acceptance testing

A

Testing performed against a contract’s acceptance criteria for producing custom-developed software.

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

Coverage

A

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

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

Data-driven testing

A

A scripting technique that stores test input and expected results in a table or spreadsheet, so that a single control script can execute all of the tests in the table. Data driven testing is often used to support the application of test execution tools such as capture/playback tools.

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

Debugging

A

The process of finding, analyzing, and removing the causes of failures in software

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

Decision coverage

A

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.

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

Decision table testing

A

A black box test design technique in which test cases are designed to execute the combinations of inputs and/or stimuli shown in a decision table (a table showing combinations of inputs and/or stimuli/causes – with their associated outputs and/or actions/effects).

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

Defect

A

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

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

Defect management

A

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

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

Defect report

A

A document reporting on any flaw in a component or system that can cause the component or system to fail to perform its required function.

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

Dynamic testing

A

Testing that involves the execution of the software of a component or system

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

Entry criteria

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Equivalence partitioning
Divide data into partitions in such a way that all the members of a given partition are expected to be processed in the same way (this can be done for invalid as well as valid values)
26
Error
A human action that produces an incorrect result
27
Error guessing
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 because of errors made, and to design tests specifically to expose them.
28
Equivalence partitioning
Divide data into partitions in such a way that all the members of a given partition are expected to be processed in the same way (this can be done for invalid as well as valid values)
29
Exit criteria
The set of generic and specific conditions, agreed upon with 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.
30
Experience-based test technique
Procedure to derive and/or select test cases based on the tester’s experience, knowledge, and intuition.
31
Exploratory testing
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.
32
Formal review
A review characterized by team participation, documented results of the review, and documented procedures for conducting the review. (See ISO/IEC 20246 for more on review processes for work products)
33
Functional testing
Testing based on an analysis of the specification of the functionality of a component or system. (See also black box testing).
34
Impact analysis
The assessment of change to the layers of development documentation, test documentation, and components, in order to implement a given change to specified requirements
35
Informal review
A review characterized by not following a defined process and not having formal documented output.
36
Inspection
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.
37
Integration testing
Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems.
38
Keyword-driven testing
A scripting technique that uses data files to contain not only test data and expected results, but also keywords related to the application being tested. They keywords are interpreted by special supporting scripts that are called by the control script for the test.
39
Maintenance testing
Testing the changes to an operational system or the impact of a changed environment to an operational system.
40
Non-functional testing
Testing the attributes of a component or system that do not relate to functionality, e.g., reliability, efficiency, usability, maintainability, and portability.
41
Operational acceptance testing
Operational testing in the acceptance test phase, typically performed in a (simulated) operational environment by operations and/or systems administration staff focusing on operational aspects, e.g., recoverability, resource-behaviour, installability, and technical compliance.
42
Perspective-based review
A review characterized by reviewers taking on different stakeholder viewpoints in individual reviews, e.g., marketing, designer, tester, or operations. Similar to role-based review.
43
Product risk
Possibility that a work product may fail to satisfy the legitimate needs of its users and/or stakeholders. Where these risks are associated with specific quality characteristics of a product, they are also called quality risks.
44
Project risk
Situations that, should they occur, may have a negative effect on a project’s ability to achieve its objectives
45
Quality
The degree to which a component, system, or process meets specified requirements and/or user/customer needs and expectations
46
Quality assurance
Part of quality management focused on providing confidence that quality requirements will be fulfilled
47
Regression 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.
48
Regulatory acceptance testing
The process of testing to determine the compliance of the component or system
49
Review
An evaluation of a work product to ascertain discrepancies from expectations and to recommend improvements. Examples include informal review, walkthrough, technical review, and inspection.
50
Risk
Risk involves the possibility of an event in the future which has negative consequences. The level of risk is determined by the likelihood of the event and the impact (harm) from that event.
51
Risk level
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.
52
Risk-based testing
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 process.
53
Role-based review
A review characterized by reviewers evaluating a work product form the perspective of individual stakeholder roles, e.g., experience user, senior, child, system administrator, performance tester, etc. Similar to perspective-based review
54
Root cause
A source of a defect such that if it is removed, the occurrence of the defect type is decreased or removed.
55
Scenario-based review
A review in which reviewers are provided with “scenarios” representing expected usage of the work product and conduct “dry runs” through the work product looking for defects that arise because of these use cases.
56
Sequential development model
A sequential development model describes the software development process as a linear, sequential flow of activities. This means that any phase in the development process should begin when the previous phase is complete.
57
State transition testing
A black-box test design technique in which test cases are designed to execute valid and invalid state transition.
58
Statement coverage
The percentage of executable statements that have been exercised by a test suite
59
Static analysis
Analysis of software artifacts e.g., requirements or code, carried out without execution of these software development artifacts. Static analysis is usually carried out by means of a supporting tool.
60
Static testing
Static testing is the manual examination or tool-driven evaluation of work products to identify defects without executing the software, often prior to or during development.
61
System integration testing
Testing the integration of systems and packages; testing interfaces to external organizations (e.g., Electronic Data Interchange, Internet).
62
System testing
The process of testing an integrated system to verify that it meets specified requirements
63
Technical review
A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken.
64
Test analysis
The process of analyzing the test basis to identify testable features and define the test conditions (with traceability) considering functional, non-functional, structural characteristics, and other business/technical factors. Also involves identifying ambiguities, omissions, contradictions, etc. in the test basis. This is particularly important on a team without a formal review process or where testing is closely connected to that process, in order to shift testing left and ensure that requirements are of sufficient quality.
65
Test approach
The starting point for selecting the test techniques, test levels, and test types and defining entry and exit criteria in order to tailor the organization’s test strategy to a particular project or release.
66
Test automation
The use of software to perform or support test activities, e.g., test management, test design, test execution, and results checking.
67
Test basis
All documents from which the requirements of a component or system can be inferred. The documentation on which the test cases are based. If a document can be amended only by way of formal amendment procedure, then the test basis is called a frozen test basis.
68
Test case
A set of input values, execution preconditions, expected results, and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement
69
Test completion
The final stage of test activities, wherein data is collected from completed test activities and consolidated at project milestones such as when a test project is completed (or cancelled), an Agile iteration is finished, etc. Defects not yet closed are triaged, Test Summary Report is written, testware is archived/finalized, and information is gathered and analyzed to find lessons to improve process future maturity.
70
Test condition
An item or event of a component or system that could be verified by one or more test cases, e.g., a function, transaction, feature, quality attribute, or structural element.
71
Test control
A test management task that deals with developing and applying a set of guiding or corrective actions to get a test project on track when monitoring shows a deviation from what was planned or as a result of information and metrics gathered and (possibly) reported
72
Test data
Data that exists (for example, in a database) before a test is executed, and that affects or is affected by the component or system under test
73
Test design
(1) A document specifying the test conditions (coverage items) for a test item, the detailed test approach and identifying the associated high level test cases. (2) The process of transforming general testing objectives into tangible test conditions and test cases.
74
Test environment
An environment containing hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test
75
Test estimation
The calculated approximation of a result related to various aspects of testing (e.g., effort spent, completion date, costs involved, number of test cases, etc.) which is usable even if input data may be incomplete, uncertain, or noisy.
76
Test execution
The process of running a test on the component or system under test, producing actual results.
77
Test execution tool
A type of test tool that is able to execute other software using an automated test script, e.g., capture/playback.
78
Test implementation
The process of developing and prioritizing test procedures, creating test data, and, optionally, preparing test harnesses and writing automated test scripts.
79
Test level
A group of test activities that are organized and managed together. A test level is linked to the responsibilities in a project. Examples of test levels are component test, integration test, system test, and acceptance test
80
Test management tool
A tool that provides support to the test management and control part of a test process. It often has several capabilities, such as testware management, scheduling of tests, the logging of results, progress tracking, incident management, and test reporting.
81
Test manager
The person responsible for project management of testing activities and resources, and evaluation of a test object. The individual who direct, controls, administers, plans, and regulates the evaluation of a test object.
82
Test monitoring
A test management task that deals with gathering info and providing feedback about test activities to periodically assess test progress and measure whether the exit criteria / definition of done have been satisfied. Reports are prepared that compare the actuals to which was planned.
83
Test object
The component or system to be tested.
84
Test objective
A reason or purpose for designing and executing a test.
85
Test oracle
A source to determine expected results to compare with the actual result of the software under test. An oracle may be the existing system (for a benchmark), other software, a user manual, or an individual’s specialized knowledge, but should not be the code.
86
Test plan
A document describing the scope, approach, resources, and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques, and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process.
87
Test planning
The activity of establishing or updating a test plan.
88
Test procedure
A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script.
89
Test process
The fundamental test process comprises test planning and control, test analysis and design, test implementation and execution, evaluating exit criteria and reporting, and test closure activities.
90
Test progress report
A document summarizing testing activities and results, produced at regular intervals, to report on progress of testing activities against a baseline (such as the original test plan) and to communicate risks and alternatives requiring a decision to management.
91
Test strategy
A generalized description of the test process in an organization
92
Test suite
A set of several test cases for a component or system under test, where the post condition of one test is often used as the precondition for the next one.
93
Test summary report
A document summarizing testing activities and results. It also contains an evaluation of the corresponding test items against exit criteria.
94
Test technique
A procedure used to derive and/or select test cases
95
Test type
A group of test activities aimed at testing a component or system focused on a specific test objective, i.e., functional test, usability test, regression test, etc. A test type may take place on one or more test levels or test phases.
96
Tester
A skilled professional who is involved in the testing of a component or system.
97
Testing
A way to assess the quality of the software and reduce the risk of failure in operation
98
Testware
Artifacts produced during the test process required to plan, design, and execute tests, such as documentation, scripts, inputs, expected results, set-up and clear-up procedures, files, databases, environment, and any additional software or utilities used in testing.
99
Traceability
The ability to identify related items in documentation and software, such as requirements with associated tests.
100
Use case testing
A black box test design technique in which test cases are designed to execute scenarios of use cases
101
User acceptance testing
Formal testing with respect to user needs, requirements, and business processes, conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers, or other authorized entities to determine whether or not to accept the system.
102
Validation
Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled.
103
Verification
Confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled.
104
Walkthrough
A step-by-step presentation by the author of a work product in order to gather information and to establish a common understanding of its content.
105
White-box test technique
Testing based on an analysis of the internal structure of the component or system.
106
Failure
Deviation of the component or system from its expected delivery, service, or result.
107
Checklist-based testing
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

ISTQB-CTFL Certified Tester (3 decks)

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