ISTQB 4.0 - Theories Flashcards
I.Fundamentals of Testing
The degree to which specified coverage items are exercised by a test suite, expressed as a percentage.
a. coverage
b. debugging
c. defect
d. error
Coverage
Synonym: test coverage
I.Fundamentals of Testing
The process of finding, analyzing, and removing the causes of failures in a component or system.
a. defect
b. error
c. debugging
d. quality
Debugging
I.Fundamentals of Testing
An imperfection or deficiency in a work product where it does not meet its requirements or specifications.
a. error
b. defect
c. failure
d. quality
Defect
Synonyms: bug, fault
I.Fundamentals of Testing
A human action that produces an incorrect result.
a. failure
b. defect
c. error
d. debugging
Error
Synonyms: mistake
I. Fundamentals of Testing
An event in which a component or system does not perform a required function within specified limits.
a. failure
b. defect
c. error
d. debugging
Failure
I. Fundamentals of Testing
The degree to which a work product satisfies stated and implied needs of its stakeholders
a. quality assurance
b. root cause
c. quality
d. failure
Quality
I. Fundamentals of Testing
Activities focused on providing confidence that quality requirements will be fulfilled.
a. quality assurance
b. root cause
c. quality
d. failure
Quality Assurance
Abbreviation: QA
I. Fundamentals of Testing
A source of a defect such that if it is removed, the occurrence of the defect type is decreased or removed.
a. quality assurance
b. test analysis
c. root cause
d. test basis
Root Cause
I. Fundamentals of Testing
The activity that identifies test conditions by analyzing the test basis.
a. test analysis
b. test basis
c. test case
d. test completion
Test Analysis
I. Fundamentals of Testing
The body of knowledge used as the basis for test analysis and design.
a. test analysis
b. test basis
c. test case
d. test completion
Test Basis
I. Fundamentals of Testing
A set of preconditions, inputs, actions (where applicable), expected results and postconditions, developed based on test conditions.
a. test analysis
b. test basis
c. test case
d. test completion
Test Case
I. Fundamentals of Testing
The activity that makes testware available for later use, leaves test environments in a satisfactory condition and communicates the results of testing to relevant stakeholders.
a. test analysis
b. test basis
c. test case
d. test completion
Test Completion
I. Fundamentals of Testing
A testable aspect of a component or system identified as a basis for testing.
a. test condition
b. test control
c. test data
d. test design
Test Condition
Synonyms: test situation, test requirement
I. Fundamentals of Testing
The activity that develops and applies corrective actions to get a test project on track when it deviates from what was planned.
a. test condition
b. test control
c. test data
d. test design
Test Control
I. Fundamentals of Testing
Data needed for test execution
a. test condition
b. test control
c. test data
d. test design
Test Data
Synonym: test dataset
I. Fundamentals of Testing
The activity that derives and specifies test cases from test conditions
a. test condition
b. test control
c. test data
d. test design
Test Design
I. Fundamentals of Testing
The activity that runs a test on a component or system producing actual results.
a. test execution
b. test implementation
c. test monitoring
d. test object
Test Execution
I. Fundamentals of Testing
The activity that prepares the testware needed for test execution based on test analysis and design.
a. test execution
b. test implementation
c. test monitoring
d. test object
Test Implementation
I. Fundamentals of Testing
The activity that checks the status of testing activities, identifies any variances from planned or expected, and reports status to stakeholders.
a. test execution
b. test implementation
c. test monitoring
d. test object
Test Monitoring
I. Fundamentals of Testing
The work product to be tested.
a. test execution
b. test implementation
c. test monitoring
d. test object
Test Object
I. Fundamentals of Testing
The purpose for testing
a. test objective
b. test planning
c. test procedure
d. test result
Test Objective
Synonym: test goal
I. Fundamentals of Testing
The activity of establishing or updating a test plan.
a. test objective
b. test planning
c. test procedure
d. test result
Test Planning
I. Fundamentals of Testing
A sequence of test cases in execution order, and any associated actions that may be required to set up the initial preconditions and any wrap up activities post execution.
a. test objective
b. test planning
c. test procedure
d. test result
Test Procedure
I. Fundamentals of Testing
The consequence/outcome of the execution of a test.
a. test objective
b. test planning
c. test procedure
d. test result
Test Result
Synonyms: outcome, test outcome, result
I. Fundamentals of Testing
The process within the software development lifecycle that evaluates teh quality of a component or system and related work products.
a. testing
b. testware
c. validation
d. verification
Testing
I. Fundamentals of Testing
Work products produced during the test process for use in planning, designing, executing, evaluating, and reporting on testing.
a. testing
b. testware
c. validation
d. verification
Testware
(e.g. test basis, testable requirements, user stories, test cases)
I. Fundamentals of Testing
Confirmation by examination that a work product matches a stakeholder’s needs.
a. testing
b. testware
c. validation
d. verification
Validation
Validation - stakeholder’s needs
Verification - requirements
I. Fundamentals of Testing
Confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled.
a. testing
b. testware
c. validation
d. verification
Verification
Validation = stakeholders needs
Verification = requirements
I.I. What is Testing?
This refers to a set of activities to discover defects and evaluate the quality of software artifacts.
Software Testing
I.I. What is Testing?
What are the 9 typical test objectives?
- Evaluating work products such as requirements, user stories, designs, and code
- Triggering failures and finding defects
- Ensuring required coverage of a test object
- Reducing the level of risk of inadequate software quality
- Verifying whether specified requirements have been fulfilled
- Verifying that a test object complies with contractual, legal, and regulatory requirements
- Providing information to stakeholders to allow them to make informed decisions
- Building confidence in the quality of the test object
- Validating whether the test object is complete and works as expected by the stakeholders
I.I. What is Testing?
What is the difference between testing and debugging
- Testing is about triggering failures caused by defects either through dynamic test or static test
- Debugging is concerned with finding causes of this failure (defects), analyzing these causes, and eliminating them. In case of Dynamic testing triggering a failure, because dynamic testing is about execution.
- On the other hand, debugging is only concerned with removing the failure if it is found using Static Testing, because static testing is about reviewing documentation.
I.2. Why is Testing Necessary?
Enumerate some of testing’s contribution to success
- Testing provides a cost-effective means of detecting defects.
- Testing provides a means of directly evaluating the quality of a test object at various stages in the SDLC.
- Testing provides users with indirect representation on the development project
- Testing may also be required to meet contractual or legal requirements, or to comply with regulatory standards.
II. Testing Throughout the Software Development Lifecycle
A test level that focuses on determining whether to accept the system.
a. acceptance testing
b. black-box testing
c. component integration testing
d. component testing
Acceptance Testing
II. Testing Throughout the Software Development Lifecycle
Testing based on an analysis of the specification of the component or system.
It derives tests from documentation external to the test object. Its main objective is to check the system’s behaviour against its specification.
a. acceptance testing
b. black-box testing
c. component integration testing
d. component testing
black-box testing
Synonym: specification-based testing
II. Testing Throughout the Software Development Lifecycle
The integration testing of components. It focuses on testing the interfaces and interactions between components.
a. acceptance testing
b. black-box testing
c. component integration testing
d. component testing
Component integration testing
Synonym: module integration testing, unit integration testing
II. Testing Throughout the Software Development Lifecycle
A test level that focuses on individual hardware of software components. Normally performed by developers in their development environments.
a. acceptance testing
b. black-box testing
c. component integration testing
d. component testing
component testing
Synonyms: module testing, unit testing
II. Testing Throughout the Software Development Lifecycle
A type of change-related testing performed after fixing a defect to confirm that a failure caused by that defect does not reoccur.
a. confirmation testing
b. functional testing
c. integration testing
d. maintenance testing
Confirmation Testing
synonym: re-testing
II. Testing Throughout the Software Development Lifecycle
Testing performed to evaluate if a component or system satisfies functional requirements. It’s main objective is checking the functional completeness, functional correctness, and functional appropriateness.
a. confirmation testing
b. functional testing
c. integration testing
d. maintenance testing
b. functional testing
II. Testing Throughout the Software Development Lifecycle
Testing performed to evaluate that a component or system complies with non-functional requirements. It refers to testing of “how well the system behaves”.
a. non-functional testing
b. regression testing
c. maintenance testing
d. functional testing
Non-functional testing
II. Testing Throughout the Software Development Lifecycle
A test level that focuses on interactions between components or systems. This requires suitable test environments preferably similar to the operational environment.
a. confirmation testing
b. functional testing
c. integration testing
d. maintenance testing
Integration Testing
II. Testing Throughout the Software Development Lifecycle
Testing the changes to an operational system or the impact of a changed environment to an operational system
a. confirmation testing
b. functional testing
c. integration testing
d. maintenance testing
Maintenance testing
II. Testing Throughout the Software Development Lifecycle
A type of change-related testing to detect whether defects have been introduced or uncovered in unchanged areas of the software.
a. regression testing
b. maintenance testing
c. functional testing
d. non-functional testing
Regression testing
II. Testing Throughout the Software Development Lifecycle
A test approach to perform testing and quality assurance activities as early possible in the software development lifecycle
a. shift left
b. system integration testing
c. system testing
d. test level
a. shift left
II. Testing Throughout the Software Development Lifecycle
The integration of systems
a. shift left
b. system integration testing
c. system testing
d. test level
b. system integration testing
II. Testing Throughout the Software Development Lifecycle
A test level that focuses on verifying that a system as a whole meets specified requirements
a. shift left
b. system integration testing
c. system testing
d. test level
c. system testing
II. Testing Throughout the Software Development Lifecycle
A specific instantiation of a test process. These are groups of test activities that are organized and managed together.
a. test level
b. test object
c. test type
d. white-box testing
test level
Synonym: test stage
II. Testing Throughout the Software Development Lifecycle
The work product to be tested
a. test level
b. test object
c. test type
d. white-box testing
test object
test item
II. Testing Throughout the Software Development Lifecycle
A group of test activities based on specific test objectives aimed a specific characteristics of a component or system.
a. test level
b. test object
c. test type
d. white-box testing
test type
II. Testing Throughout the Software Development Lifecycle
Testing based on an analysis of the internal structure of the component or system. It is structure-based and derives tests from the system’s implementation or internal structure (e.g. code, architecture, work-flows, and data flows).
Its main objective is to cover the underlying structure by the tests to the acceptable level.
a. black-box testing
b. white-box testing
a. regression testing
b. maintenance testing
b. white-box testing
Synonyms: clear-box testing, code-based testing, glass-box testing
II. Testing Throughout the Software Development Lifecycle
What are the different Test Levels?
a. Component Testing (Unit Testing) - focuses on testing components in isolation, normally performed by developers.
b. Component Integration Testing (Unit Integration testing) - focuses on testing the interfaces and interactions between components.
c. System Testing - focuses on the overall behavior and capabilities of an entire system or product.
d. System Integration Testing - focuses on testing the interfaces of the system under test and other systems and external services.
e. Acceptance testing - focuses on validation and on demonstrating readiness for deployment.
II. Testing Throughout the Software Development Lifecycle
What are the different Test Types?
a. Functional Testing - evaluates the functions that a component or system should perform.
b. Non-functional Testing - evaluates attributes other than functional characteristics of a component or system.
c. Black-box Testing - specification-based and derives tests from documentation external to the test object.
d. White-box testing - structure-based and derives tests from the system’s implementation or internal structure.
III. Static Testing
A condition that deviates from expectation
a. anomaly
b. dynamic testing
c. formal review
d. informal review
a. anomaly
III. Static Testing
Testing that involves the execution of the test item
a. static testing
b. dynamic testing
c. formal review
d. informal review
Dynamic Testing
III. Static Testing
A review that follows a defined process with a formally documented output.
a. formal review
b. informal review
c. technical review
d. walkthrough
a. formal review
III. Static Testing
A type of review that does not follow a defined process and has no formally documented output
a. formal review
b. informal review
c. technical review
d. walkthrough
b. informal review
III. Static Testing
A type of formal review that uses defined team roles and measurement to identify defects in a work product, and improve the review process and the software development process
a. formal review
b. informal review
c. technical review
d. inspection
d. inspection
III. Static Testing
A type of static testing in which the quality of a work product or process is evaluated by individuals
a. inspection
b. review
c. static analysis
d. static testing
b. review
III. Static Testing
The process of evaluating a component or system without executing it, based on its form, structure, content, or documentation
a. static testing
b. static analysis
c. technical review
d. inspection
b. static analysis
III. Static Testing
Testing that does not involve the execution of a test item
a. dynamic testing
b. dynamic analysis
c. static testing
d. static analysis
c. static testing
III. Static Testing
A formal review by technical experts that examine the quality of a work product and identify discrepancies from specifications and standards
a. formal review
b. informal review
c. technical review
d. inspection
c. technical review
III. Static Testing
A type of review in which an author leads members of the review a work product and the members ask questions and make comments about possible issues
a. formal review
b. walkthrough
c. technical review
d. informal review
b. walkthrough
III. Static Testing
What are the commonly used review types?
a. Informal Review
b. Walkthrough
c. Technical Review
d. Inspection
III. Static Testing
What are the roles and responsibilities in reviews?
a. Manager - decides what is to be reviewed and provides resources, such as staff and time for the review
b. Author - creates and fixes the work product review
c. Moderator - (also known as the facilitator) - ensures the effective running of review meetings, including mediation, time management, and a safe review environment in which everyone can speak freely.
d. Scribe (also known as recorder) - collates anomalies from reveiwers and records review information, such as decisions and new anomalies found during the review meeting
e. Reviewer - performs reviews. A reviewer maybe someone working on the project, a subject matter expert, or any other stakeholder
d. Review Leader - takes overall responsibility for the review such as deciding who will be involved, and organizing when and where the review will take place.
III. Static Testing
This role in reviews decides what is to be reviewed and provides resources, such as staff and time for the review.
a. Manager
b. Author
c. Moderator
d. Scribe
a. Manager
III. Static Testing
This role in reviews creates and fixes the work product under review. In inspections, they cannot act as the review leader or scribe
a. Manager
b. Author
c. Moderator
d. Scribe
b. Author
III. Static Testing
This role in reviews ensures the effective running of review meetings, including mediation, time management, and a safe review environment in which everyone can speak freely. They are also referred to as the facilitators.
a. Manager
b. Author
c. Moderator
d. Scribe
c. Moderator
III. Static Testing
This role collates anomalies from reviewers and records review information, such as decisions and new anomalies found during the review meeting. They are also known as the recorder
a. Manager
b. Author
c. Moderator
d. Scribe
d. Scribe
III. Static Testing
This role performs reviews. They may be someone working on the project, a subject matter expert, or any other stakeholder
a. Reviewer
b. Scribe
c. Manager
d. Moderator
a. Reviewer
III. Static Testing
This role takes overall responsibility for the review such as deciding who will be involved and organizing when and where the review will take place.
a. Reviewer
b. Review leader
c. Scribe
d. Moderator
b. Review leader
III. Static Testing
What are the activities in the review process?
a. Planing
b. Review Initiation
c. Individual Review
d. Communication and analysis
e. Fixing and reporting
III. Static Testing
This activity in the review process is where the scope of the review, which comprises the purpose, the work product to be reviewed, quality characteristics to be evaluated, areas to focus on, exit criteria, supporting information such as standards, effort and the timeframes for the review, shall be defined.
a. Planning
b. Review initiation
c. Individual review
d. Communication and analysis
e. Fixing and reporting
a. Planning
III. Static Testing
The goal in this part of the review process is to make sure that everyone and everything involved is prepared to start the review. This includes making sure that every participant has access to the work product under review, understands their role and responsibilities and receives everything needed to perform the review.
a. Planning
b. Review initiation
c. Individual review
d. Communication and analysis
e. Fixing and reporting
b. Review initiation
III. Static Testing
In this part of the review process, every reviewer performs an individual review to assess the quality of the work product under review, and to identify anomalies, recommendations, and questions by applying one or more review techniques (e.g., checklist-based reviewing, scenario-based reviewing)
a. Planning
b. Review initiation
c. Individual review
d. Communication and analysis
e. Fixing and reporting
c. Individual Review
III. Static Testing
In this part of the review process, anomalies identified during the revew need to be analyzed and discussed. For every anomaly, the decision should be made on its status, ownership and required actions. This is typically done in a review meeting, during which the participants also decide what the quality level of reviewed work product is and what follow-up actions are required. A follow-up review may be required to complete actions.
a. Planning
b. Review initiation
c. Individual review
d. Communication and analysis
e. Fixing and reporting
d. Communication and analysis
III. Static Testing
In this part of the review process, a defect report is created so corrective actions can be followed-up. Once the exit criteria are reached, the work product can be accepted. The review results are reported.
a. Planning
b. Review initiation
c. Individual review
d. Communication and analysis
e. Fixing and reporting
e. Fixing and reporting
IV. Test Analysis and Design
What are the four commonly used black-box test techniques?
a. Equivalence Partitioning
b. Boundary Value Analysis (BVA)
c. Decision Table Testing
d. State Transition Testing
IV. Test Analysis and Design
This test technique is based on an analysis of the specified behavior of the test object, without reference ot its internal structure. Therefore, the test cases are independent of how the software is implemented. Consequently, if the implementation changes, but the required behavior stays the same, then the test cases are still useful.
a. Black-box test techniques
b. White-box test techniques
c. Experience-based test techniques
a. Black-box test techniques (also known as specification-based techniques)
IV. Test Analysis and Design
This test technique is based on an analysis of the test object’s internal structure and processing. As the test cases are dependent on how the software is designed, they can only be created after the design of implementation of the test object.
a. Black-box test techniques
b. White-box test techniques
c. Experience-based test techniques
b. White-box test techniques (also known as structure-based techniques)
